JavaGetting Started with the Greenfoot Java IDE

Getting Started with the Greenfoot Java IDE

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Programming Notes # Hs00301


Preface

What is Greenfoot?

Greenfoot is a combination of a Java IDE that provides a class browser, compilation, interactive execution, single-step execution, a code editor, etc., on one hand and a framework for creating two-dimensional animations, games, and simulations on the other hand (see Greenfoot Home in Resources). Greenfoot is also available free of charge.

Relatively painless, fun, and engaging

Greenfoot provides a painless, fun, and engaging entry point for novice programmers but also supports the full power of the Java programming language for more advanced programmers.

A harmonic wave simulator
Click here to open a page containing a harmonic wave simulator in a separate browser window (or in a separate tab on your browser). Click the Run button at the bottom and move the blue bead to activate the wave motion. Move the Amplitude, Frequency, and Damping sliders to change the physics of the simulation. Flip the switch on the upper left to switch between manual operation and an oscillator. (Note that your browser must support Java 1.5 or later for this applet to run properly.)

Fun and engaging

Greenfoot is fun and engaging because Greenfoot makes it relatively easy for novice programmers to create 2D games, animations, and simulations.

Powerful

Greenfoot is powerful because it allows for the use of the same Java code that an advanced Java programmer would use in a major Java project. Included in that power is the ability to do any or all of the following:

  • Execute the scenario (project) inside the IDE, either in single-step mode or run mode.
  • Export the scenario as a Java applet in a JAR file with an accompanying HTML file.
  • Export the scenario as an application in an executable JAR file.
  • Publish the scenario on the Greenfoot web site for review and comment by others.

Terminology – scenario or project

As a matter of clarification, most of the Greenfoot documentation uses the word scenario to describe what might be referred to as a project in other programming environments and IDEs. For purposes of this tutorial, the two terms are interchangeable.

Viewing tip

I recommend that you open another copy of this document in a separate browser window and use the following links to easily find and view the figures and listings while you are reading about them.

Figures

  • Figure 1. Visual manifestation of the Greenfoot IDE.
  • Figure 2. Context menu for the World class.
  • Figure 3. Dialog for specifying name and image for new class.
  • Figure 4. Context menu for the MyWorld class.
  • Figure 5. The source code editor.
  • Figure 6. Context menu for the Actor class.
  • Figure 7. Result of selecting the new MyActor() option.
  • Figure 8. Lots of spiders.
  • Figure 9. The Greenfoot IDE in Run mode.
  • Figure 10. The context menu for a MyActor object.
  • Figure 11. Method inheritance information for a MyActor object.
  • Figure 12. An Object Inspector window.
  • Figure 13. Export dialog.

Listings

  • Listing 1. Class definition code for the class named MyWorld.
  • Listing 2. Class definition code for the class named MyActor.

Supplementary material

I recommend that you also study the other lessons in my extensive collection of online programming tutorials. You will find a consolidated index at www.DickBaldwin.com.

A simple Greenfoot scenario

I’m going to begin by giving you a look at a very simple Greenfoot scenario. The visual manifestation of the Greenfoot IDE, version 1,4,1 is shown in Figure 1.

Figure 1. Visual manifestation of the Greenfoot IDE.

The stage and the actors

This is an animation scenario involving a stage and an actor. The blue rectangle on the left in Figure 1 is the stage upon which the actors perform. (In this scenario, there is only one actor, which is represented by an image of a spider. Note, however, that there could be many actors in a more complicated scenario.)

Classes and objects
If you are a beginner in OOP, you may not yet know about classes and objects. If so, you will simply need to bear with me at this point. I want to make certain that I am using proper terminology throughout, even when I haven’t yet explained that terminology.

Classes and objects

This stage is the visual manifestation of an object created from the class named MyWorld shown in the class diagram on the right in Figure 1. The spider is the visual manifestation of an object created from the class named MyActor shown in the class diagram on the right.

A quick explanation of classes and objects

I have much more to say about classes and objects in other lessons on my website (see Dick Baldwin’s Programming Tutorials in Resources). For now, suffice it to say that a class is analogous to a set of blueprints or plans from which something can be constructed. An object is the thing that is constructed from those blueprints.

Overall behavior

A little later, I will show you the Java code that produces the behavior that I am about to describe. This scenario is designed to animate the spider and cause it to move diagonally down and to the right across the stage toward the lower right corner.

At the bottom of Figure 1, you see a button labeled Act and another button labeled Run. Each time the button labeled Act is clicked, the spider will move one step to the right and one step down. (I will explain what I mean by one step later.) If the button labeled Run is clicked, the spider will move in incremental steps toward the lower right corner. The effect of clicking the Run button is the same as if someone were to repeatedly click the Act button. When the spider reaches the lower right boundary of the stage, it will stop.

The Reset button and the speed slider

You can also see a button labeled Reset in Figure 1. This button does what most buttons labeled reset do. It resets the program.

There is also a speed slider on the bottom of the IDE but it doesn’t show in Figure 1. This slider is used to increase or decrease the animation speed. (The slider doesn’t show in Figure 1 because I had to manually reduce the width of the IDE to make it fit into this narrow publication format.)

The classes named World and Actor

The classes named World and Actor are part of the Greenfoot IDE and are always there when you create a new scenario. Their purpose is to make it easy to write animation, game, and simulation scenarios in addition to more general-purpose Java programs. A custom API is also included with the IDE to support that purpose.

To define the class named MyWorld so that I could construct an object from that class to represent the stage, I extended (or inherited from) the class named World. The arrow that points from MyWorld up to World in the class diagram on the right side of Figure 1 indicates that MyWorld extends World. Similarly, to define the class named MyActor so that I could construct an object from that class, I extended the class named Actor.

What does it mean to extend or inherit from another class?

For the benefit of beginners, let’s consider a hypothetical analogy. (Experienced Java programmers can skip this section.) Assume that you go to an architect to purchase a set of plans to build a new house. Assume also that the architect has in her files, a general set of plans named World that describes features of all the houses in the development where your house is going to be built. She makes a copy of those plans and that copy becomes a part of the plans for your new house.

Assume that she draws additional plans that refer to everything in theWorld plans and supplements that information with information that is peculiar to your house, such as the types of appliances, the types of bathroom fixtures, the floor coverings, etc. She names the second set of plans MyWorld, and they also become part of the plans for your new house. In effect, the second set of plans has extended the original set of plans and the overall plans for your house include both World and MyWorld.

The architect delivers the two sets of plans to you and you deliver them to the construction contractor who uses them to build your new house. Your new house will have characteristics that are common to all of the houses in the development and will also have characteristics that are peculiar to your individual house.

A fairly good analogy

This is a fairly good analogy to the concept of classes, inheritance, and objects in Java. The two sets of construction plans are analogous to the two classes shown by the two upper boxes in the class diagram in Figure 1. The completed house is analogous to an object that is constructed from those two classes (the stage in this case). The Java code constructs an object from the plans (class) named MyWorld, and the characteristics defined the plans (class) named World are included in the object through inheritance.

The Java code that constructs the object is analogous to the construction contractor that constructs your new house.

You could also say that the two sets of construction plans are analogous to the two classes shown by the two boxes in the lower right in Figure 1, and that the completed house is analogous to the object that is constructed from those two classes (represented by the spider image).

The class definition code

Listing 1 shows the class definition code for the class named MyWorld.

Listing 1. Class definition code for the class named MyWorld.

import greenfoot.*;

/**
The purpose of this class is simply to illustrate a
couple of basic things about Greenfoot.
*/
public class MyWorld extends World
{
    public MyWorld()//constructor
    {
        // Create a new world
        super(20, 20, 10);
    }//end constructor
}//end MyWorld class

You don’t need to worry too much about the details of the code shown in Listing 1 at this time. However, there are a couple of things that are worthy of note.

 
Color
Even though Java code is never actually colored, I added color to the code in Listing 1 to make it easier to discuss.

The class named MyWorld extends World

Note first the code shown in blue in Listing 1. This code stipulates that the new class named MyWorld extends (inherits from) the class named World. That satisfies the inheritance relationship shown by the top two classes in Figure 1.

Terminology
Objects are constructed from classes.

The constructor

The code shown in red is called a constructor. This code is analogous to the construction contractor that built your new house in the earlier discussion. The purpose of this code is to cause the object to come into existence and to occupy memory.

The stage

You can write general-purpose Java programs using Greenfoot that pretty much ignore most of what you see in Figure 1. However, if you want to use Greenfoot to create a 2D animation, game, or simulation, the easiest thing to do is to take advantage of the structure for the stage and the actors that already exist in the IDE.

If you don’t need a stage…
If you are writing a general-purpose Java program that doesn’t need a stage, just set the super parameters to (1,1,1).

The stage in a Greenfoot scenario is always a rectangular grid of square cells. The statement in Listing 1 that begins with the word super specifies that the dimensions of the stage for this scenario are 20 cells by 20 cells. The first number is the width of the stage in cells and the second number is the height of the stage in cells. The third number specifies that each cell is a square that is ten pixels on each side.

The spider jerks along

If you write and run this scenario, you will see that the spider moves along rather jerkily, with each step taken by the spider being from the center of the current cell to the center of the next cell along the diagonal path. We could make the spider move much more smoothly by increasing the number of cells and making each cell smaller. However, this would also cause the spider to appear to move more slowly because it would have to take more steps to move the same physical distance on the stage.

Class definition code for the class named MyActor

The code that defines the class named MyActor is shown in Listing 2.

Listing 2. Class definition code for the class named MyActor.

import greenfoot.*;
/**
The purpose of this class is simply to illustrate a
couple of basic things about Greenfoot.
*/
public class MyActor extends Actor
{
    public void act() 
    {
        setLocation(getX()+1,getY()+1);
    }//end method act  
}//end class MyActor

Color added

Once again, I added color to make the code easier to discuss. Beginning with the code shown in blue, the class named MyActor extends the class named Actor satisfying the inheritance relationship given by the two corresponding classes shown in Figure 1.

The method named act

The code shown in red is the definition of a method named act. This method is executed once each time the Act button at the bottom of Figure 1 is clicked. Also, as mentioned earlier, his method is executed repeatedly when the Run button in Figure 1 is clicked.

The purpose of this method is to cause the spider to move diagonally across the stage, moving down and to the right. The stage is represented by a Cartesian coordinate system with the origin at the upper left corner. The x-axis is the horizontal axis and the y axis is the vertical axis. The positive x-direction is to the right. Contrary to what you might expect, the positive y-direction is down the screen instead of up.

Each cell width constitutes one unit on the respective axes with the cell in the upper-left corner having a coordinate value of 0,0.There are 20 cells across and 20 cells down.herefore, the coordinate value of the cell at the upper-right corner is 19,0. The coordinate value of the cell at the bottom left corner is 0,19, and the coordinate value of the cell at the bottom right corner is 19,19.

Make the spider move

The code in the act method in Listing 2 causes the spider to move one cell to the right and one cell down each time the method is executed. This is accomplished by calling the setLocation method to cause the spider’s new location to be one cell to the right and one cell down from the current cell. This, in turn is accomplished by getting the x and y coordinate values of the current cell, adding one to each of those values, and using those two sums to define the new location.

Convenience features

This IDE provides several convenience features that make it easy for novice programmers to get something interesting up and running quickly without having to know a lot about Java programming. As mentioned earlier, it is also possible for more advanced Java programmers to use the IDE to write Java applications or applets that exercise the full power of Java, completely ignoring most of the convenience features of the IDE if they choose to do so. Thus, Greenfoot provides a little something for everybody. In this lesson, I will concentrate on the use of the convenience features.

Right-click on the World class

If you right-click on the World class, the context menu shown in Figure 2 will appear.

Figure 2. Context menu for the World class.

This context menu provides three options:

  • Open editor
  • Inspect
  • New subclass…
What is a subclass?
In Java, a class that extends or inherits from another class is often referred to as a subclass of the original class. Note however that class is a keyword while subclass is simply jargon. Therefore, I will refer to every class simply as a class even if it extends another class.

The New subclass option

When you start developing a new scenario, only the World class and the Actor class are pre-defined. It is up to you to extend the World class into a new class that represents your particular world and it is up to you to extend the Actor class into one or more new classes that represent the actors in your scenario.

Creating classes with program code
If you know how to do so, you can also define new classes by writing the Java code to define the classes while ignoring the New subclass option in the context menu of Figure 2. If you create classes outside Greenfoot, and store them in the scenario directory, they will be detected and shown in the class diagram (see Figure 2) when the scenario is opened.

You create a new class to represent your world by selecting the New subclass option in the context menu in Figure 2. When you do, the dialog shown in Figure 3 will appear.

 

 

 

 

Figure 3. Dialog for specifying name and image for new class.

What does this dialog want from you?

The dialog shown in Figure 2 is asking you to specify a name for your new class and to select an image that will represent your new class as the background image on the stage.You type the name in the text field at the top of Figure 2. Then click on one of the many images that are shown and click the Ok button to select the image.

If you want to import and use an image file that is not part of the Greenfoot distribution, you can click the button labeled Browse for more images to find and select a different image file.

If you want the new world to have a plain white background, you can simply enter the name for the class and click the Ok button.

What do the blue stripes mean?

When you click the Ok button, the dialog will be dismissed and the new class will appear as a subclass of the World class as shown in Figure 1. At that point in time, the box that represents the new class will contain light blue diagonal stripes similar to those shown in the MyActor class in Figure 2. The stripes mean that the class needs to be compiled before it can be used. You can compile the class by clicking the button labeled Compile all at the bottom of Figure 2. (You can also compile the class from within the editor that I will discuss shortly.)

The Inspect option

You can open a class inspector on the World class by selecting the Inspect option in Figure 2. Many different classes and objects can be inspected in Greenfoot in order to obtain more information about the class or the object. I am going to defer a discussion of inspection until later while discussing an object of a more interesting class.

The Open editor option

Selecting the Open editor option in Figure 2 will open the source code of the World class definition in a text editor allowing you to view the definition of the class. However, the World and Actor classes are read-only and cannot be modified. I will defer a discussion of the editor until later while discussing the class named MyWorld.

Context menu for the MyWorld class

If you right-click on the MyWorld class, the context menu shown in Figure 4 will appear.

Figure 4. Context menu for the MyWorld class.

The Open editor option

Probably the first option that you will use from this context menu is the Open editor option so I will begin the discussion with that option. Selection of this option will cause the text editor shown in Figure 5 to appear on the screen. (Note that it was necessary for me to reduce the size of the image to force it to fit into this narrow publication format. As a result, some of the text in Figure 5 isn’t very legible.)

Figure 5. The source code editor.

Putting some meat on the skeleton

Skeleton code for a new class is automatically created whenever you create a new class using the New subclass option shown in Figure 4. The first time you select the Open editor option in the context menu for the new class, the skeleton code will appear in the editor. The image shown in Figure 5 was captured after I modified the skeleton code to produce the source code shown in Listing 1.

The editor is a fairly standard source-code editor with a few features designed specifically for use with Greenfoot. I’m not going to bore you with all of the operational details of the editor because I doubt that you need those details. You can probably figure out most of what you need to know on your own with a little experimentation.

Source code versus documentation

There is one aspect of the editor that is different from the norm and worth mentioning. Whenever you create a scenario in Greenfoot, standard Java documentation is automatically generated for all of the classes in the scenario. I explain the format of that documentation a separate document titled The Importance of Sun’s Java Documentation (see Resources).

You will notice that there is a pull-down list in the upper right corner of Figure 5. That list contains the following two options:

  • Source Code
  • Documentation

When Source Code is selected, the window serves as a source code editor for the class. When Documentation is selected, the window serves as a non-editable display window for the standard documentation of the class being edited.

Compiling the source code

Any time you modify the source code for a class, you must compile the new source code before you can use the modified class. You can compile the modified source code in at least three ways:

  • Click the Compile button shown in Figure 5.
  • Pull down the Tools menu in Figure 5 and select Compile.
  • Click the Compile all button in Figure 1.

Whenever a class needs to be compiled, it will appear with diagonal lines as shown by the MyActor class in Figure 2.

The new MyWorld() option

Getting back to the context menu in Figure 4, the new MyWorld() option is used to create a new object from the class named MyWorld. However, whenever you modify the code and then compile the class, a new object for the modified class is automatically created. Therefore, you probably won’t need to use this option very often, if at all.

The New subclass option

There may be situations where you would want to define a new class that extends or inherits from the class named MyWorld in Figure 4. If so, you can do that by selecting New subclass in Figure 4, providing a name for the new class, selecting an image for the new class, etc.

The Set image… and Remove options

If you decide to change the image for the class after it has been created, the Set image… option can be used for that purpose.

As the name implies, the Remove option can be used to delete a class from the scenario if you decide that you don’t need it after all.

Context menu for the Actor class

Right-clicking the Actor class produces the context menu shown in Figure 6.

Figure 6. Context menu for the Actor class.

This should look familiar

By now, you should have a pretty good idea of the purpose of each of the options in the context menu. As is the case with the World class, you can open the Actor class and view the class definition in the editor. However, as I mentioned earlier, the Actor and World classes are read-only and cannot be modified.

I selected the New subclass option to create the class named MyActor shown in Figure 1. When you select that option, the dialog shown in Figure 3 will appear. As with the MyWorld class discussed earlier, you use this dialog to specify a name for the new class and to select an image that will represent objects of the new class on the stage. If you don’t select an image, the default image, which is a small green footprint, will be used.

The context menu for the MyActor class

If you right click on the MyActor class, a context menu similar to the one shown in Figure 4 will appear. The only difference will be that the first option will be titled new MyActor() instead of new MyWorld().

The purpose of each option in this context menu is the same as the purpose of each corresponding option that I explained earlier in conjunction with the class named MyWorld. There is one major difference, however. Whereas you will rarely need to create new objects of the class named MyWorld, you may need to create objects of the MyActor class. Creating objects of the MyActor class can be accomplished in at least three ways:

  1. Select the new MyActor() option from the context menu for the class.
  2. Left-click the MyActor class once, hold down the Shift key and left-click the location on the stage where you want the object to appear.
  3. Write standard Java code to create a new object of the class and add it to your new world.  (One way to do this by calling the addObject method in the constructor for your new world.)

Selecting the new MyActor() option from the context menu

The result of selecting the new MyActor() option is shown in Figure 7. However, Figure 7 doesn’t show the mouse pointer, which is a critical part of the picture. (Just pretend that you can see the mouse pointer pointing to the spider immediately to the left of the box for the class named MyActor.)

Figure 7. Result of selecting the new MyActor() option.

A new object is created

When you select new MyActor() from the context menu for the MyActor class, a new object of the class is created and the image that represents the object is attached to the mouse pointer. You can drag the image and drop it in the desired location on the stage. Initially the red circle with the diagonal line shown in Figure 7 will appear on top of the image indicating that you can’t drop the object in that location. This symbol will disappear once you drag the image into the stage area, indicating that it is okay to drop the object anywhere in the stage area.

Left-click the MyActor class once, hold down the Shift key, etc.

There is no way for me to produce a single image illustrating the methodology indicated by option 2 in the above list. You will simply have to try it for yourself to get the feel of it. However, the result of using this procedure to create a large number of objects of the MyActor class (very quickly) and place them in various locations on the stage is shown in Figure 8.

Figure 8. Lots of spiders.

All the spiders behave the same

Because all of the spiders shown in Figure 8 were created from the same class, and the behavior of all objects created from that class is defined by the class definition shown in Listing 2, clicking the Run button in the bottom of Figure 8 causes all of the spiders to move in parallel diagonal paths down and to the right until they reach the boundary of the stage. Once they reach the boundary, they move along that boundary until they all bunch up on top of one another in the bottom right corner as shown in Figure 9.

Figure 9. The Greenfoot IDE in Run mode.

The Run button is now a Pause button

However, my purpose in showing you Figure 9 was not to show you the spiders bunched up in the bottom right corner. Rather, my purpose was to show you what happens to the Run button in Figure 1 when you click it. As you can see in Figure 9, the Run button has turned into a Pause button. Once you click theRun button, the scenario will continue to run until one of the following occurs:

  • You click the Pause button.
  • The scenario is terminated by program code (not covered in this tutorial).
  • You click the X-button in the upper right corner of Figure 9.
  • A few other possibilities such as turning of the power to the computer.

You can drag and drop the spiders

When you click the Pause button, the scenario will stop running and the button will revert to a Run button. Note, however, that the spiders won’t return to their original locations as shown in Figure 8 because there is no code in the program to cause them to do so. However, you can grab each spider with the mouse pointer and drag it to any location you choose on the stage when the scenario is not in the Run mode. You can’t drag the spiders around when the scenario is in the Run mode because the location of each spider is being controlled by the repeated execution of the setLocation method shown in Listing 2.

The context menu for a MyActor object

Right-clicking one of the spiders will produce the context menu shown in Figure 10.

Figure 10. The context menu for a MyActor object.

Second-level information

If you point to one of the top two options in the context menu in Figure 10, information regarding the methods inherited into the object will be presented as shown in Figure 11.

Figure 11. Method inheritance information for a MyActor object.

If you are just learning how to program in Java, you probably won’t understand it even if I try to explain the information shown in Figure 11. You will learn about those things in due time. If you are further along in your understanding of Java programming, you probably don’t need an explanation anyway so I won’t provide one.

Only one method in the class definition

The context menu for an object shows all of the methods that are defined in the class from which the object was created. The class named MyActor defined only one method, and that is the method named act as shown in Listing 2. Therefore, the only method shown in the context menu in Figure 10 is the method named act.

One interesting feature of the context menu is that you can click on a method name in the context menu and that method will be executed one time. This makes it possible to individually execute new methods that you write and compile so that you can confirm proper behavior of each method independently of the other methods in the class definition. However, this isn’t too useful with theact method because exactly the same thing happens each time you click theAct button at the bottom of Figure 1. Therefore, this scenario isn’t very useful for demonstrating the usefulness of this capability.

Selecting the inspect option

Selecting the inspect option from the context menu for an object will cause an Object Inspector window similar to the one shown in Figure 12 to open.

Figure 12. An Object Inspector window.

Some information is intuitively obvious and some is not

Some of the information in Figure 12, such as the current location of the object in x and y coordinate values and the rotation of the object is intuitively obvious. Some is not so obvious. For example, if you double-click on the top box containing a crooked arrow, a second object inspector window will open containing information about the parent (container) object of the current object. In this case, the container is the object that was created from the class named MyWorld, which I have been referring to as the stage.

If you double-click on the bottom box containing a crooked arrow, another object inspector window will open containing information about the spider image that represents the object on the stage. That object inspector also contains some arrows, which can be double-clicked. The bottom line is that the Inspect option on an object’s context menu makes it possible for you obtain information about the object itself, and also to obtain information about other objects to which that object is linked.

Object linkages

The object created from the MyActor class is linked to the object created from the MyWorld class because it is physically contained in that object on the stage. It is linked to an object that was originally created from a file containing an image of a spider because that image is being used to visually represent the object on the stage. That image object, by the way, was created from a class named GreenfootImage, which is one of the relatively hidden parts of the Greenfoot IDE that mainly does its work behind the scenes and out of sight.

The context menu for the stage

Right clicking the label myWorld at the top of Figure 1 causes a context menu to pop up for the object that was created from the class named MyWorld. There is nothing on that menu that I haven’t already discussed, so there is no point in me discussing that context menu further.

Scenario Information

Clicking the button labeled Scenario Information at the top right of Figure 1 opens a text editor on a file named README.TXT. This file is contained in the folder that contains the scenario files. The text that is contained in the file when it opens encourages the developer to describe the scenario for the benefit of users who may later need that information.

The target audience

According to recent correspondence with Michael Kölling,

“Today, we are using Greenfoot with high school kids (age 14 and up), and at college and university level. I’d claim that as the target audience. We needed to get a bit of experience with actual classroom situations to see where the lower bound in the age group is, and 14 works well (as does anything older), and I wouldn’t recommend it much below that age.”

Having taught computer programming at the community college level for about fifteen years and having taught Java OOP since 1997, I am of the opinion that the target audience for Greenfoot clearly includes students at the college level.

Also having taught Java OOP to many old-school procedural programmers who are still struggling with the transition from procedural to object-oriented programming, both at the college and in onsite company-sponsored training programs, I believe that the target audience also includes old-school procedural programmers.

Greenfoot makes learning fun

My great granddaughter often repeats a saying that she learned in Montessori kindergarten, “Fun is learning and learning is fun.” Even at my somewhat advanced age, I couldn’t agree more.

Greenfoot makes learning to program with Java not only practical but fun as well. Let’s face it, regardless of our age, most of us do a better job on those tasks that we enjoy than we do on those tasks that we don’t enjoy. So the question is, which activity would most students find more enjoyable?

  • Writing a Java program that causes an image of a spider to chase an image of a fly around the screen, or
  • Writing a text-based Java program that computes and displays an amortization table for a 30-year mortgage at an interest rate of 6.25 percent.

The same understanding of fundamentals is required

Both Java programs would require an understanding of the same fundamental programming concepts. The difference is that writing programs that provide sensory feedback (such as spiders chasing flies) can be fun while writing programs to compute amortization tables can be extremely boring. At least that is the case for most of the students that I have met during my fifteen years of teaching.

Thanks to Greenfoot, we as Java instructors now have the opportunity to conduct programming instruction that is not only solid from an educational and technical viewpoint, but is also fun and engaging for the students. (Even most old-school procedural programmers would probably rather spend time writing interesting OO programs than writing boring OO programs.)

This kind of help is needed

Without some help of the kind provided by Greenfoot, beginning programmers are not capable of writing a program that causes an image of a spider to chase an image of a fly around the screen, or much else in the way of interesting programs for that matter. (Believe it or not, most students don’t get too excited by if statements and while loops.)

Being able to start from scratch and write programs with exciting graphics requires knowledge of some fairly advanced Java programming concepts. Beginning programming students simply do not possess that knowledge and those students are usually relegated to writing boring programs of the amortization-table variety.

The Xbox generation

Computer science enrollments are down in most high schools, colleges, and universities in the U.S. There are many reasons for this. In my opinion, one of the most important reasons is that most existing computer science curricula fail to satisfy the needs of the Xbox generation for something more stimulating than amortization tables.

The challenge

Computer programs of the amortization-table variety are clearly necessary in our economy. However, they should not be necessary in an introductory programming course in a high school, college, or university. Our challenge, as computer science instructors in the U.S., is to keep students involved, interested, and engaged long enough for them to realize that computer programming and computer science are interesting professions even if it may occasionally be necessary to write a program involving amortization tables or to satisfy other similarly boring objectives.

It has been shown in various studies at Carnegie Mellon University and elsewhere that making it possible for students to produce interesting results early in an introductory programming course tends to reduce the dropout rate. This should apply regardless of whether we are talking about high school students, community college students, computer-programming students in curricula other than hard-core computer science at the university level, first-year students with computer science aspirations at the university level, and even old-school procedural programmers struggling with the transition into OOP.

Boredom is a killer of ambition

With the advent of the web, there are many opportunities both inside and outside of hard-core computer science that require participants to understand and to be proficient in modern object-oriented programming using Java, C#, C++, or other similar programming languages. Boredom is a killer of ambition and the reality is that a large percentage of computer programming instruction in the U.S. is extremely boring for the first couple of semesters. Perhaps with products like Greenfoot, we can rectify that situation and rekindle interest in computer science among students in the U.S.

Speaking of the web

Once a Greenfoot scenario is completed and tested, Greenfoot makes it veryeasy to:

  1. Export the scenario as a stand-alone Java application suitable for execution on just about any computer that has Java version 1.5 or later installed (without a requirement for the Greenfoot IDE to exist on that computer).
  2. Export the scenario as an applet for publishing in a web page on your favorite web server.
  3. Publish the scenario on a public Greenfoot website for execution and comments by others.

Writing dual-purpose programs is not easy

Writing a Java program so that it can be used either as an application or an applet isn’t rocket science. However, writing such dual-purpose programs is well beyond the capabilities of most beginning programming students. However, Greenfoot makes it easy to do just that.

Many students maintain their own web sites and might like to show off their early programming creations by posting them as applets on their web sites. The ability to do this should be a positive motivating factor for many of those students.

Those same students, as well as many other students, might like to share their early programming creations with friends and family (particularly those with slow or no Internet access) as stand-alone Java applications. Greenfoot makes that easy also. The same Greenfoot program can be exported in both forms.

Greenfoot, Scratch, Alice, and BlueJ

While some tools are more advanced than others, there are currently at least four programming paradigms that occupy roughly
the same space in terms of programming education:

  1. Greenfoot
  2. Scratch
  3. Alice
  4. BlueJ

I am very familiar with the first three. I know very little about BlueJ so I won’t comment on it at this time. (There are probably others that I don’t know about as well.)

 
Nerd
A computer expert by aptitude and not mere training. Usually male, under the age of 35 and socially inept; a person whose tremendous skill with operating or designing computer hardware or software is exceeded only by his, rarely her, passionate love of the technology.

Social networking for nerds

The folks involved in the Scratch project at MIT have proven the positive effect of providing a capability for students to share their programming creations on a public website for review and comment by their peers. By providing this capability, they are attracting and keeping students engaged, involved, and learning about computer programming completely outside of formal schoolwork. (This capability of Scratch is similar to item 3 in the above list.)

The Scratch website, on which students share programs written in Scratch, has become a form of social networking for thousands of young scratchers (as they like to refer to themselves) from around the world. I like to think of the Scratch website, in a positive sense, as social networking for nerds. (By the way, I recognize that I am something of a nerd myself, so I don’t consider nerd to be a derogatory term.)

Scratch is not a serious programming language

However, even though the Scratch website is incredibly popular among younger students, Scratch is not a serious programming language in the sense that Java, C++, and C# are serious programming languages. Scratch is seriously lacking insofar as support for important fundamental programming concepts is concerned. Of the ten to fifteen fundamental programming concepts that most computer science professors agree to be extremely important, Scratch only supports three or four.

The main emphasis in Scratch is on multimedia capabilities

Once you get beyond variables, if-else statements, loops, and operators (which Scratch does support in a limited sense), Scratch is primarily a toy language that makes it easy for students to do wild and wonderful things with a wide array of multimedia capabilities. (However, I believe that the multimedia capabilities are one of the factors that make Scratch so popular among younger students.)

Developed in Squeak

Scratch was developed using a programming language named Squeak, but the underlying language is completely hidden from the Scratch programmer. Although I know nothing about Squeak, I don’t believe that it is widely used in either academia or industry. Apparently, however, it was well suited for the development of Scratch.

Unconventional loop structures

While Scratch does support loop structures, the loop structures in Scratch are unconventional, at least from the viewpoint of someone whose primary programming experience for the past twenty years or so derives from a tradition rooted in C including C++, Java, and C#. I don’t know if the unconventional loop structures in Scratch are a latent manifestation of Squeak and/or Smalltalk, (which I also know nothing about), or if they were designed that way for some other reason. In my opinion, it would have been better from an educational viewpoint for Scratch to use a more conventional C-style loop structure based on the keywords while, for, and possibly do while.

Scratch is a dead-end IDE

The bottom line is that Scratch simply wasn’t designed to teach students how to do serious programming. While it may be educational with respect to the effective use of multimedia capability, (and it is very successful in giving young students constructive outlets for their creative energies), insofar as computer science education is concerned, Scratch is a dead-end IDE. Scratch is clearly not suitable for major programming projects. Further, there is no evidence that the folks in the Scratch program at MIT are working on a smooth migration path for students from Scratch to any serious programming language.

What about Alice?

The latest released version of Alice is version 2.0. (Version 2.2 has been released in beta as of this writing.) Alice 3.0 is on the drawing board.  I will divide this discussion between Alice 2.0 and Alice 3.0. (Alice 2.2 doesn’t appear to be significantly different from 2.0 insofar as this discussion is concerned, so I will skip it altogether.)

Alice 2.0 is also fun and engaging

Alice 2.0 is a 3D programming language, which is also a lot of fun. However, it is more difficult to use than Scratch and may not be as much fun as Scratch. (Alice provides much less in the way of multimedia functionality than Scratch.) Alice 2.0 is much more powerful and more conventional than Scratch, but is still somewhat unconventional nonetheless.

Alice supports most fundamental programming concepts

Alice supports almost all of the fundamental programming concepts that I referred to earlier. I personally consider Alice 2.0 to be suitable for use in a first programming course for community-college students who don’t have a strong programming background from high school. However, almost all of my colleagues in the computer science department in the college where I teach disagree with me on this.

A drag and drop programming interface

Both Alice 2.0 and Scratch use a drag and drop programming interface.Scratch programmers are totally insulated from anything resembling source code. Alice 2.0 students are required to create source code using the drag and drop interface, but they are not required to memorize syntax. My colleagues seem to uniformly agree that this is a major failing of Alice. Many Alice students simply don’t learn syntax because they are not forced to do so. According to my colleagues, this places them at a disadvantage when they enroll in the next programming course in the computer science curriculum.

Alice 2.0 is also not a serious programming language

To compound matters, Alice 2.0 is also not a serious programming language. By this, I mean that no one is going to use Alice 2.0 for any serious programming projects. Even though Alice 2.0 was developed using Java, the underlying language is completely hidden in Alice 2.0. The bottom line is that Alice 2.0 is strictly for teaching.

A difficult transition is required

Alice 2.0 students must transition to a serious programming language such as Java, C#, or C++ if they are going to continue their computer programming education beyond the first semester. There is no smooth migration path from either Scratch or Alice 2.0 to a serious programming language. According to my colleagues, this is a major drawback of Alice 2.0. (I doubt that they would even be willing to discuss Scratch.) They believe that many students who successfully complete an introductory programming course using Alice 2.0 are still not prepared to make the transition into the next programming course in the computer science curriculum.

Alice 3.0 will be a serious programming language – Java

The folks at Carnegie Mellon University (CMU) are currently hard at work to solve most of the problems that I described above including a smooth migration path to a serious programming language. That solution will come in the form of Alice 3.0.

Alice 3.0 will make it relatively easy to develop 3D games and animations just like Alice 2.0, and will also provide a drag and drop programming interface. However, and this is extremely important, Alice 3.0 will also expose the full power of Java.

The programming interface will be optional

The programming interface that is used with Alice 3.0, whether it is drag and drop or text editor, will be optional. Students will be able to program in either or both ways. As I understand it, the Alice 3.0 interface will sit atop Eclipse, which is already a very popular professional Java IDE.

Java version 1.5 or later is required

Also note that in order to view Greenfoot applets from the Greenfoot Gallery, to view them locally in your browser, or to view them from any other website, your browser must be compatible with Java 1.5 or later.

Firefox compatibility

When I first became involved with Greenfoot, I discovered that my Firefox browser had not updated itself beyond Java 1.4 even though it had gone through numerous update cycles and everything else on my computer was running Java 1.6. (Firefox seemed to be really fond of Java 1.4.) In the end, I had to go to the Control Panel and remove an old Java 1.4 JRE that was still on my computer to force Firefox to update itself to use Java 1.6.

Run the program

I invite you to go to Greenfoot Home (see Resources) where you can download and install Greenfoot. As of this writing, Greenfoot version 1.4.1 is the latest release.; I’m told, however, that version 1.4.5 will be released very soon, perhaps before this tutorial is actually published.

Also if you need to do so, go to Sun, download and install the latest version of Java (see Resources). Remember, Greenfoot requires Java 1.5 or later, and as of this writing Java 1.6 is available from Sun. According to recent correspondence with Michael Kölling,

“If, at installation time, Greenfoot finds only one Java version on the system (JDK install, not JRE), it will just use it. (Must be Java 5 or up.) If it finds more than one Java version, it asks the user at installation time which one to use. This can be changed later.”

Once you computer is ready, use the code in Listing 1 and Listing 2, along with the written instructions in this tutorial to create and execute the simple scenario that I described earlier. Experiment with the code, making changes, and observing the results of your changes. Make certain that you can explain why your changes behave as they do.

Summary

My purpose in publishing this tutorial is to make the case that the Greenfoot IDE is quite possibly the best IDE available at this time for teaching a beginning course in computer programming. Because Greenfoot exposes the full power of Java, it may also prove useful in a second-semester programming course that concentrates on object-oriented programming. I am considering the incorporation of Greenfoot in a variety of ways into the second-semester Java/OOP course that I routinely teach each semester.

No major scenarios in this lesson

Most of the tutorial lessons that I publish contain at least one fairly substantial sample program. However, that is not the case for this tutorial. My main purpose in publishing this tutorial was simply to introduce you to Greenfoot in terms of its capabilities and its operation. I will publish other lessons in the future that will show you how to put Greenfoot to work in more significant ways.

Resources

Historical information about Greenfoot

The first prototype of Greenfoot was developed by Poul Henriksen as part of his Master Thesis at The Maersk Mc-Kinney Moller Institute for Production Technology, University of Southern Denmark, 2004. Greenfoot 1.0 was released on May 31, 2006.

The current release of Greenfoot is version 1.4.1. The About Greenfoot page within the IDE indicates that the current Greenfoot team consists of Poul Henriksen, Michael Kölling, Davin McCall, Bruce Quig, and John Rosenberg.

A page on the Greenfoot website states that Greenfoot is a project at the University of Kent at Canterbury (UK) and Deakin University, Melbourne (Australia), funded by Sun Microsystems. Poul Henriksen and Michael Kölling were at the University of Southern Denmark when Greenfoot started. Both are now at the University of Kent. Some team members are at Deakin University.

Greenfoot won a Dukes Choice Award for 2007. The announcement was made at Sun’s prestigious JavaOne conference in California. James Gosling, the inventor of Java, presented the award.


Copyright

Copyright 2008, Richard G. Baldwin.  Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.

About the author

Richard Baldwin is a college professor (at Austin Community College in Austin, TX) and private consultant whose primary focus is a combination of Java, C#, and XML. In addition to the many platform and/or language independent benefits of Java and C# applications, he believes that a combination of Java, C#, and XML will become the primary driving force in the delivery of structured information on the Web.

Richard has participated in numerous consulting projects and he frequently provides onsite training at the high-tech companies located in and around Austin, Texas. He is the author of Baldwin’s ProgrammingTutorials, which have gained a worldwide following among experienced and aspiring programmers. He has also published articles in JavaPro magazine.

In addition to his programming expertise, Richard has many years of practical experience in Digital Signal Processing (DSP). His first job after he earned his Bachelor’s degree was doing DSP in the Seismic Research Department of Texas Instruments. (TI is still a world leader in DSP.) In the following years, he applied his programming and DSP expertise to other interesting areas including sonar and underwater acoustics.

Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.

Baldwin@DickBaldwin.com

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories