BlueJ – The Interactive Java Environment

Mailing Lists

Read or subscribe to:

1. Introduction

Java is quickly becoming very popular, both for application development and for teaching, and many programming environments exist. This raises the question:

Why yet another programming environment?

The short answer is: because none of the existing environments is suitable for teaching.

In particular, we want an environment that is really object-oriented. An environment that emphasises classes and objects as its basic units of interaction, so that students are naturally led into a way of thinking in terms of classes and objects.

Secondly, we want an environment that is sophisticated, but at the same time easy to use, so that students can start using it straight away without the need for long introduction. We do not want to teach about the environment itself.

Thirdly, we want an environment that supports interaction and experimentation.

Fourthly, we want an environment that uses visualisation to display class structure. After all, half of the time in a teaching context we talk about class structure. Structuring the problem is one of the most important aspects of object-oriented programming. Yet many teachers find that students have difficulty thinking in terms of classes and objects. This is not surprising if all they ever see on the screen are lines of code or interface buttons and menus!

2. The problems with existing environments

Several aspects in existing environments cause a long list of problems in teaching. One or more of these problems is present in every other environment.

1. The environment is not really object-oriented.
   An environment for an object-oriented language does not make an object-oriented environment. The environment itself should reflect the paradigm of the language. In particular, the abstractions students work with should be classes and objects. In most existing environments, students deal with files instead. They are forced to think about the operating system's file system and directory structure. Setting up projects can be a nightmare. All this creates overhead that hinders teaching and distracts from the important issues. Objects as interaction entities are not supported in any other Java environment. Yet they are one of the most fundamental abstraction concepts.
    
2. The environment is under- or overkill.
   Many teachers do not use an integrated environment (usually because of problems with finding a suitable one). In that case, students work from a command line (using Sun's JDK) and spend considerable time becoming familiar with Unix or DOS instead of learning about programming. In this case, valuable opportunities are lost for better teaching and learning through the use of better tools. Other environments are developed for more professional users and present an absolutely overwhelming set of interface components and functionality. Students are lost in these environments, and the effect can be as bad as having no integrated environment at all. Other environments are really modifications of non-object-oriented (procedural) environments and offer the wrong set of tools and abstractions. All of those, too minimalist tools, too complicated tools or the wrong tools, cause considerable problems.
    
3. The environment focuses on user interfaces.
   Many environments using graphics use the graphics for the wrong tasks. In particular, many environments concentrate on building graphical user interfaces (GUIs). Building GUIs from the start conveys a very distorted picture of programming and object-orientation. Students spend their time dragging buttons rather than thinking about building an application.
   
   At the same time a much more beneficial use of graphics is neglected: display of class structure. Object-oriented program structure can be represented graphically in a way that makes it easier to understand. Few existing environments make good use of this.
    
4. The environment is expensive.
   Cost is still a big problem with some environments. One effect of this is the problem for students to work at home - acquiring a license for home use can be expensive.

3. The BlueJ solutions

BlueJ addresses all of these problems:

1. BlueJ is object-oriented.
   In BlueJ students interact with classes and objects. They can manipulate class structure graphically and textually. Objects can be created and methods of any object can be called interactively.
    
2. BlueJ has been designed for teaching.
   BlueJ offers a unique mix of sophisticated support for visualisation and interaction and a simple and intuitive interface.
    
3. BlueJ visualises class structure and objects.
   In BlueJ, class structure can be seen and manipulated on screen, and objects can be interactively created and operations called.
    
4. BlueJ is free.
   The environment is available free of charge.

4. Problems with Java (and BlueJ's answers)

Java is a reasonably clean language, but by no means free of problems for introductory teaching. For teachers, it is important to know those problems and to have a way to deal with them. Two of the problems most often reported in the literature (for example in [1] and [4]) are:

• problems with the main function
• problems with text I/O

The main function: The main function has to be written with the signature

public static void main (String[] args)

This causes several problems. Firstly, several concepts are used here which cannot be explained at this stage (static functions, arrays, void return types). So teachers have to use some hand-waiving ("just believe me and write it like this") and students feel frustrated. Secondly, this has nothing to do with object-orientation! The main function does not logically belong to any object. Thus, students start of with seeing an exception rather than a good example of object-orientation.

I/O: Text I/O, especially input, is not simple and causes regular problems. In addition, it forces students to deal with exceptions at a very early stage.

BlueJ solves both of these problems!

Because objects can be created interactively, and methods can be called interactively, there is no need for a main function. Students can write classes and call their methods without a need to have a main. And because parameters can be passed to interactive method calls and results are displayed, there is no immediate need for I/O. Students can write and test very sophisticated code without the need for any I/O operations!

5. Real object-oriented teaching

Many Java text books claim to use an "objects first" approach. We very much agree with this idea. In reality, most of the books then go on to explain some low level instructions first and get to objects and classes in chapter four. The reason is an intrinsic problem with Java: if you explain classes first, then you still need a way to execute the class's operations to see a result. And to do this you have to write some driver code. To write this code, you need to know some Java instructions.

In BlueJ, no driver code is needed. Operations can be invoked interactively, so teachers are free to use a real objects-first approach for the first time. Students can be given a class of which they can create objects. They can use those objects. Then they can open them and read, modify or add operations. This is really "objects first" with the introduction of lower level constructs after methods (as a means to implement those methods).

6. Our experiences

We have previously worked on a system named Blue [2,3]. Blue is a programming language and an integrated environment. BlueJ is an almost identical environment as that used in the Blue system, with Java as the supported language. Experiences with Blue have shown the environment to be extremely successful in getting students to work independently very quickly. It has proven very helpful in conveying important object concepts, and students mastered working with object-orientation and with the environment in very short time. Some aspects of the Blue environment which apply equaly to BlueJ are described in [5] and [6].

BlueJ is now used internationally at many universities (see the list of users, if you are interested). The feedback is overwhelmingly positive. We have used BlueJ ourselves in our own teaching since the start of 1999, with about 300 students per year. For us, BlueJ has kept all its promises.

7. Summary

BlueJ offers:

• a project manager, a compiler, an editor, a debugger, a virtual machine
• full tool integration (compilation from within the editor, compiler error message display in the editor, setting breakpoints in the editor, etc.)
• abstraction from operating system
• class structure visualisation
• direct object interaction
• simplicity, easy-to-use interface

References:

[1]  David Clark, Cara MacNish and Gordon F. Royle, Java as a teaching language ­ opportunities, pitfalls and solutions, in Proceedings of the Third Autralasian Conference on Computer Science Education, ACM, Brisbane, Australia, July 1998.

[2]  Michael Kölling and John Rosenberg, Blue - A Language for Teaching Object-Oriented Programming, in Proceedings of 27th SIGCSE Technical Symposium on Computer Science Education, ACM, Philadelphia, Pennsylvania, 190-194, March 1996.

[3]  Michael Kölling and John Rosenberg, An Object-Oriented Program Development Environment for the First Programming Course, in Proceedings of 27th SIGCSE Technical Symposium on Computer Science Education, ACM, Philadelphia, Pennsylvania, 83-87, March 1996.

[4]  Robert K. Allen, Kevin Bluff and Annette B. Oppenheim, Jumping Into Java: Object-Oriented Software Development for the Masses, in Proceedings of the Third Autralasian Conference on Computer Science Education, ACM, Brisbane, Australia, 165-172, July 1998.

[5]  John Rosenberg and Michael Kölling, I/O Considered Harmful (At least for the first few weeks), in Proceedings of the Second Australasian Conference on Computer Science Education, ACM, Melbourne, 216-223, July 1997.

[6]  John Rosenberg and Michael Kölling, Testing Object-Oriented Programs: Making it Simple, in Proceedings of 28th SIGCSE Technical Symposium on Computer Science Education, ACM, San Jose, Calif., 77-81, February 1997.