Category Archives: BlueJ

BlueJ 4 brings a bag of new features

Posted on by
4


After concentrating on Greenfoot for some time, we have now worked on and released a significant new version of BlueJ: BlueJ version 4.0.

The most exciting new feature for me is the addition of Stride. (I will say a few more words about that in a moment.) But independent of Stride, there are a number of other bits of new functionality that are worth mentioning. These include the addition of Git support, support for writing and running JavaFX applications, a rewrite of a large part of the user interface in JavaFX, a tabbed editor, a fundamental redesign of error reporting, support for HiDPI displays and numerous smaller improvements.

While we were at it, we have also removed some bits that – for various reasons – do not seem worth supporting anymore. These are support for CVS, JavaME and Applets. A bit more about this below as well.

Let’s go through the main features in a little more detail, and I can tell you what we have done and why we have done it.

Git support

[Git logo]People have asked us for support for Git for quite some time. This is not surprising: Git has become the most popular version control system for some years now, and even though Subversion is often good enough for educational situations with small projects, publicly available, free Subversion repositories have disappeared quickly over the last few years. Simultaneously, free Git repositories – such as GitHub – are flourishing. So we have now moved with the times: We have removed support for CVS (which was always a bit terrible) and added Git support. We still support Subversion, as before.

Git, however, has a somewhat different model of work. We have not fully exploited that yet. As before with Subversion, we support only a subset of its functionality. Version control systems offer help in two distinct areas: One is, well, version control (which allows version rollback, etc), and the other is teamwork (which allows integrating code from multiple developers). While they are often used together, they each also make sense on their own: A single developer might use version control, or a team might use team integration tools without version rollback.

So far, we have always only supported the team work aspects of the source control systems. With Subversion in BlueJ, you can update and commit, but not branch or roll back to prior version. Currently, our Git implementation mirrors this and supports the same functionality.

Git, however, can be used somewhat differently. Since it is a distributed source control systems, it makes much more sense to want to use Git with a local repository, just for backup and version rollback. We are currently investigating whether we modify and extend our Git support to offer something like this as well.

At the moment, BlueJ offers a nice, simple and functional interface for Git – ideal to start learning about source control – just as it did for Subversion. (If you want to try it, some setup and use information is here.)

Support for JavaFX

Javafx_logo_colorJavaFX is the new Java GUI toolkit. AWT has been out for many years, Swing has thoroughly replaced it long ago and has been the GUI toolkit for everything Java for the last 15 years or so. Yet now, Swing itself is on the way out.

JavaFX has much better support for modern GUI design, from styling over visual effects to animations. It has taken a few years, but JavaFX has now become good enough that it is ready to replace Swing for all modern new development work. Oracle has said that they will no longer develop Swing. The future is FX.

Running JavaFX in BlueJ has been almost impossible, since its invocation differs from normal method calls. (Well, there were some tricks one could use if one knew enough of the internal workings, but it was really not straightforward.)

Now, if you write a JavaFX main class (by inheriting from JavaFX’s Application class), you will automatically get a ‘Run JavaFX Application’ option in your class menu. That’s it – use it, and all is well.

But it gets even better: If you have used JavaFX, you will know that it makes use of CSS files for styling. And you can now create and edit CSS files (which are plain text files) straight from within BlueJ!

BlueJ interfaceInterface rewrite

We did not only support JavaFX for BlueJ users, we also started to rewrite BlueJ’s own user interface in JavaFX. There were a number of reasons for it: Firstly, the Stride editor could not have been written without JavaFX. It has a much more modern, dynamic interface than our old Java editor. Secondly, we were receiving an increasing number of bug reports from users with HiDPI displays. Swing does not always cope well with this. And finally, making use of some of FX’s features, such as the ease of creating animations, allowed us to make some aspects of the interface nicer.

All is not well, though. Not the whole interface has been rewritten yet, and some parts are very difficult to rewrite, for technical reasons. Thus, BlueJ currently uses a mix of Swing and JavaFX for its interface – a fact that itself creates some problems. Incorrect display on HiDPI screens, for example, while reduced, is not completely gone.

We are still working on that. JDK 9, when it comes out later this year, will help, and we are still doing what we can with JDK 8 until then.

The new editor, or: Tabs, finally

The BlueJ editor now has tabs! Some users have asked for this for the last 10 years, while others liked the multi-window model. The world has decisively moved to tabs for most applications, though, and this is now the model that most users are familiar and comfortable with.

Having your code in tabs, instead of windows, has, however, one drawback: You cannot show code side-by-side. To retain that option, we have added functionality, available by right-clicking the tab rider, to move any tab to a different window. This way, code still can be displayed side-by-side, for easy comparison.

Improved error reporting

ErrorsFor many years – in fact, since its creation in 1999 – BlueJ has reported one error at a time: When the Compile button was pressed, BlueJ highlighted the first error and stopped for you to fix it.

This has now changed in three ways: Firstly, all errors are displayed at the same time. Secondly, the errors are marked in the source code with a squiggly red underline (and the error message is displayed near the error when you click on it or the mouse hovers over it), and thirdly, the error checking happens automatically as you type. This way, errors are marked as you make them, for you to come back to at any time of your choosing to fix them.

Stride – A new language

windowThe most substantial new feature in BlueJ 4 is the addition of Stride as a new supported language. Stride was first developed and published as part of Greenfoot, and has been in use there for about a year. It has met with substantial interest since its publication and we received regular requests to include it in BlueJ.

So here it is.

So, what actually is Stride? Stride is a very Java-like language that differs mostly in its frame-based editor. This editor offers new program entry and manipulation interactions that try to get the best out of block-based and text-based editing. Not by displaying the two modes side-by-side, as some other systems do, but at the same time.

I will not talk about it much in this post (but instead introduce it more fully in a future article), but if you are curious, there are some sources where you can have a look: This page briefly describes frame-based editing, and there is a short series of videos demonstrating how to use it. Don’t worry that the videos make use of Greenfoot rather than BlueJ – the language is the same.

The Stride implementation in BlueJ has been significantly improved since publication in Greenfoot. The performance and functionality of the editor is better – progress that will also make it into the next Greenfoot release.

I will write more about Stride in BlueJ later. For now, just note that you can now write in Stride in addition to writing in Java. If you are a teacher, especially at school level, this has the potential to substantially change how you introduce programming.

Spring clean: What’s out

We always try to keep BlueJ small and simple, at least in its appearance, functionality and interface. If we continually add things, this gets very hard. Thus, sometimes things should go out as well.

We have taken the opportunity of this new release to throw out a few things that are getting old and are not much used anymore. These are support for applets, CVS and JavaME. I know that there are still a few people using some of this. Some teachers, for example, use applets as an introductory framework. To those teachers – sorry. But these are dying technologies, and you should move on. JavaFX, for example, provides a much nicer alternative to applets for those who want to start with a graphical framework. CVS – once the most used version control system – has been superseded first by Subversion, and now by Git, and JavaME – well, what is there to say.

Miscellaneous other aspects

A couple of assorted other issues may be worth mentioning:

  • The JDK is now bundled with the BlueJ download on Windows and MacOS. This makes downloading and installing easier (since you don’t need two separate, dependent downloads) and ensures that BlueJ always runs with a Java version that it has been tested on, and we know it works. It will no longer be broken by running with an incompatible JDK.
  • BlueJ 4 does not currently work on the Raspberry Pi. This is because JavaFX is not available on the Pi at the moment. BlueJ 3.1.7 continues to be available in the Raspberry Pi image.

Try it!

So, if this sounds interesting, download BlueJ now and try it out! If you are a teacher, join us in the Blueroom for more discussion about use and pedagogy.

Let me know in the comments what you think of it, what questions you have, and what aspects you would like me to write more about.

Stride – A new programming language for beginners

Posted on by
2

At the Greenfoot headquarters, we – that is: Neil Brown, Amjad Altadmri and myself – have recently worked on creating a new language within the Greenfoot environment: Stride.

The interesting thing about Stride is not so much the language design itself, but its interaction design: editing programs involves different interactions than existing editors.

The goal is that Stride sits halfway between block-based systems (such as Scratch, AppInventor, PencilCode, Alice, etc.) and text-based editors (such as Java or Python), maintaining advantages of both.

I will start a series of posts (text and/or video) here over the next few weeks trying to tell you what Stride is and why you should care. In the meantime, you can get Greenfoot, install it, and have Stride ready to go when the introduction here starts. Stride is built into Greenfoot from version 3 onwards.

Check back soon for the first overview video.

Do you want to work on BlueJ/Greenfoot? We’re hiring!

Posted on by
Reply

The BlueJ/Greenfoot team are quite a small outfit (currently four people), but we are looking to hire two more team members.

The official job advert is here, but there’s a better starting point if you’re interested: Neil, one of our team members, has just written a blog post about these two new positions. Read this first, and then get in touch if you think this might be for you!

BlueJ downloads hit 10 million!

Posted on by
Reply

The total downloads of BlueJ hit 10 million today. We started recording download numbers in 2001. Early on, downloads ran in the low hundreds per month, and we were really excited when they reached first 10,000 in a year, and later topped 100,000.

Currently, BlueJ downloads run at 2.5 million per year, and are still rising. Hitting the total of 10 million was a nice milestone.

 

Java 7 for introductory programming — does it make a difference?

Posted on by
2

The recently released BlueJ 3.0.5 brought full support for Java 7. While it is always good to be up-to-date with the latest versions — what does that actually mean for introductory programming teaching?

Java 7 brought a considerable list of new features to the Java system. Most of them deal with fairly advanced or specialised topics, and will have no influence on introductory teaching with Java. Some, however, will become visible even close to the beginning of programming. Here, I give a short overview of what’s new, and what you — as a teacher of introductory programming — should be aware of.

Java 7 – What’s new

Most of the new features in Java 7 are under the hood or in specialised libraries. These are very unlikely to affect an introductory programming course.

Improvements to the internals of the JDK include changes to the VM to support dynamically typed languages and improvements to the class loader architecture. On the library side, there are new frameworks for concurrency, cryptography and new versions of JDBC and Unicode. All these will not be relevant for most introductory courses.

The two areas that are relevant are “Project Coin”, the code name given to a project defining several small language enhancements, and NIO.2, a new library for I/O. We’ll discuss these in more detail in a moment.

Equally important, what’s not included in this release includes support for closures (known as “Project Lambda”). This would have been the most significant change to Java since the introduction of generics in Java 5 or, arguably, since the original definition of the Java language in 1995. Project Lambda has, however, been deferred to JDK 8 in what’s known as Plan B. JDK 8 is currently scheduled for release in late 2012.

So, which of the new Java 7 features are actually relevant for our intro programming course?

NIO.2

The I/O classes in Java have been improved several times over the years. The release of JDK 1.4 in 2002 brought some significant improvements in the somewhat short-sightedly named NIO library. The naming is rather less than ideal, since it stands for “New I/O”, and the passing of time dictates that everything new will eventually get old.

Which brings us to Java 7 and the New New I/O. So what will this be called now — NNIO? Well, the designers settled on NIO.2.

NIO.2 brings a number of new classes and interface, some with very useful methods. If you are doing any programming that accesses the file system, it’s worth familiarising yourself with these. Particularly interesting are the Files and Paths classes, and the Path interface, which you can find in the java.nio.file package.

All other relevant new features are part of Project Coin. They are diamond notation, strings-in-switch and improved exception handling.

Project Coin

Diamond notation

Generic type details on the right hand side of an assignment can now be inferred. For example, where in Java 6 we had to write

   HashSet<String, Monster> monsters = new HashSet<String, Monster>();

to declare a HashSet variable and initialise it with a fresh HashSet object, in Java 7 we can write

   HashSet<String, Monster> monsters = new HashSet<>();

In other words: We do not have to repeat the generic types of the HashSet on the right hand side, and can instead just write <>. (This syntax is the reason that this construct is known as the “diamond notation”). The effect of this is exactly as the Java 6 version above. It is a purely syntactic shortcut. The compiler will fill in the generic types by copying them from the variable declaration on the left, and all behaves just as before. Of course, the old notation is still allowed.

Strings in switch statements

The variable used in switch statements can now be of type String. For example

   switch (command) {
       case "go":
          goForward();
          break;
       case "help":
          showHelp();
          break;
       default:
          unknownCommand();
          break;
   }

Before Java 7, strings could not be used in switch statements.

Improved exception handling 1: multi-catch

It is now possible to catch multiple exceptions in a single exception handler. For example:

   try {
      file = new File("readme.txt");
      process(file);
   }
   catch (FileNotFoundException | UnsupportedEncodingException ex) {
      ...
   }

As you can see in this example, the catch clause can list multiple types of exception in its header, separated with an OR symbol, to catch any of these types of exception.

Improved exception handling 2: try-with-resources

The second new feature relating to exceptions is called try-with-resources. It solves a hard problem: It was previously surprisingly hard to correctly guarantee that resources (such as files or network connections) were correctly closed in the case of an exception.

The new construct solves this. Look at this example:

   try (FileWriter writer = new FileWriter(filename)) {
      ...
   }
   catch (IOException e) {
      ...
   }

Before Java 7, the standard way to close a resource (a FileWriter in this example) would have been in a finally block, which followed the catch block. In Java 7, the FileWriter is opened in round brackets following the try keyword, marking it as a resource to be auto-closed. Once the try/catch block is completed, the resource will automatically be closed by the Java runtime system.

For classes to be used with the auto-close mechanism, they must implement the new AutoCloseable interface. All the relevant classes in the Java library have been retrofitted to implement this interface.

That already sums up the relevant Java 7 changes. As we can see — not much to worry about here. (This will be different next year, when JDK 8 will bring us closures. I expect we will have to have a lively discussion then about how to treat these in a first-year course. But we can leave that for a while.)

To find out more about the new constructs in Java 7, see this summary. The next version of the Object First book (5th edition, to be released in late October) includes discussion of these new features.


Note: This post was first published in the Blueroom.

BlueJ 3.0 – What’s new

Posted on by
18

We’ve been working on it for the last eight months, and now it’s finally here: BlueJ 3.0.

Version 3.0 of BlueJ includes the most significant set of updates to BlueJ functionality since version 2.0 was released in 2004. (Yes – 2004! That was when we had no Google maps, no Facebook, no Twitter. It’s really that long ago…)

It might be good to summarise the most important of them.

The one thing that many people will notice first is an interface update:

The BlueJ 3.0 main window

The BlueJ 3.0 main window

The interface had a slight update and polish. Nothing too significant – we aimed at providing a slightly more modern appearance while still retaining the instantly recognisable “BlueJ look”. As part of the interface update, object inspectors have also changed in looks:

An object inspector

An object inspector

The inspector now looks like a magnified version of an object on the object bench. This emphasises that this is just another view of the same thing (just with additional detail provided).

The functionality of the object inspector is unchanged: fields can still be inspected further, static fields can be displayed, and so on.

The main changes in BlueJ 3.0, however, are not its looks. Our main effort has gone into improving the editor.

The BlueJ editor has always been fairly simple. 10 years ago, when it was originally written, it was simple and mainstream. Today, it was just embarrassingly simple.

Davin McCall, one of our senior developers on the BlueJ team, has implemented a new parser for BlueJ that forms the basis for much of the new editor functionality that you can see in 3.0, and also for some future features that will appear over the next few months. The most interesting of the new editor features are:

  • Scope highlighting,
  • the navigation view, and
  • code completion.

Let’s briefly look at them.

Scope highlighting

We have added background colouring to the editor to highlight scopes:

The new BlueJ 3.0 editor

The highlight makes it easier to see when brackets are missing or mismatched, and thus makes some errors more obvious. It hopefully helps students understand the concept of nested scopes.

The Navigation View

The Navigation View

The Navigation View

To the right of the editor is the “Navigation View”.

The navigation view shows a miniature version of the full class text, and highlights the currently selected viewport.

It is usable like a scroll bar: The view can be dragged, clicked, moved with a mouse wheel, etc. This gives a better overview over a source file for easier navigation.

When the mouse hovers over the navigation view, tool tips show relevant method names – this makes jumping to specific methods quicker than before.

The idea for the navigation view is taken from the “Fluid Source Code Editor” by Michael Desmond, which I saw presented at the PPIG workshop by Chris Exton.

Code completion

One of the most contentious non-features of BlueJ was, and always has been, code completion.

Almost from the very beginning, when BlueJ 1.0 was released in 1999, people have asked for code completion. Other people have been tearing their hair out in horror at the mere mention of the possibility of code completion ever being added to BlueJ. The discussions at the First Vatican Council were just a chat over coffee in comparison.

In the past, we have sided with the contra faction. (Okay, I admit: we have pretty much led the contra faction.)

But, as Konrad Adenauer, the first German post-war chancellor, said: “Was kümmert mich mein Geschwätz von gestern”.

Fact is: we have always aimed at providing tools that can be taken for granted in all reasonably modern development environments. 10 years ago, this included compilers and debuggers, but not code completion.

Code completion, back then, was still a “cool feature” that only a few high end environments provided. We did not want to create reliance on a feature that might be absent later in other environments, which meant that students could not look up documentation competently.

This has now clearly changed. Code completion is now a standard feature in mainstream environments, and the arguments against using it have grown weaker than my grandmother’s bed time cup of tea.

So, in short: code completion is finally here.

Code completion

In the BlueJ editor: code completion

In contrast to other environments, the code completion pane does not pop up automatically, but has to be activated explicitly (Ctrl-Space, by default). This means that the code completion function will not pop up unexpectedly and frighten beginners into spilling their Dr Pepper over their keyboards.

And wait, there’s more…

There is more good stuff to find in the latest BlueJ release. If you are interested, have a look at the BlueJ change log or — better still — download it and give it a run around the block.

You might like it.

(Images in this post are produced by the author and are hereby placed in the public domain.)

BlueJ is 10

Posted on by
3

I’m late, I admit it.

A day late, to be exact. Yesterday (23 August 2009) was BlueJ’s 10th birthday.

BlueJ-cake-small

As BlueJ’s version history shows, BlueJ 1.0 was released on 23 August 1999. It was born in Australia – in Melbourne, to be more exact. The project went through various changes, ending up spread across the world, with one half of the team still in Melbourne, and the other in Canterbury in the UK.

It’s not to be taken for granted that a university project survives that long, so I am really grateful to all members of the team – past and current – and to the extremely supportive user community for sticking with it for so long.

Happy Birthday BlueJ!

A License for BlueJ?

Posted on by

Beer
BlueJ has always been distributed under a “free-for-any-use/free-for-non-commercial-distribution” license. We never bothered to come up with more detailed rules. Generally, I don’t like having to deal with licensing much.

But today, I came across a license that was new to me: The Beer License. Now, there is an interesting idea!

Continue reading →