In a comment to an earlier entry on this page – “What’s happening with BlueJ?” – Peter Loborg mentioned a couple of features he misses in BlueJ: the ability to display the full UML details of a class in the diagram, and better support for packages.
This touches on a general point: what features should BlueJ support?
Most people agree that one of BlueJ’s main strengths is its small size (as seen by the user) and simple interface. At the same time, most people want us to include their favourite feature…
A few thoughts about feature inclusion in general and the UML feature in particular.
Regarding the expansion of class attributes in the diagram: I must admit that this is a fairly regular request. I think it was probably requested for the first time before we even released BlueJ…
I have always resisted this so far. I agree that it would be useful in some situations, but it’s a question of focus. Both areas mentioned in Peter’s suggestions (extended diagram and packages) become relevant a little later in a progamming course, not right at the beginning.
When we designed BlueJ, we made a concious trade-off: we aim to support only the first year of programming, and discard everything that we do not want to cover in this first year.
In return, we can make the environment simpler, and make the tools that we do include better.
It is very, very tempting over time to water down this principle. There is, of course, a grey area where not everyone argees what should be included in the first year course. If we’re not very careful, we might include something from this grey area, and then something else, and then something else. And before you can say “feature creep” you’re back at the large pile of tools you find in other IDEs.
Of course, many of the suggested extensions are very interesting, and good ideas are behind them. It is in combination, when we look at all of them, that the advantage turns into a problem.
As a solution to this dilemma we have created the BlueJ extension API. (Work on that started in about 2000, and it was released, I think in 2001 or 2002.)
Using this API, individual users can, in principle, extend BlueJ to suit their needs without us having to bloat the core.
The core of BlueJ (the standard installation) is still aimed at the intersection (not the union) of the concepts that people want to cover in a first year course.
(Okay, that’s not quite true, but good enough as a guiding principle. The reason that it is not entirely true are things such as unit testing support. Unit testing was not done by a majority of courses at the time we added it, but we thought it is such an outstanding idea that we wanted to support it.)
Now back to your request for a more complete representation of the class in the diagram.
The good news is that there is indeed an extension that does this: the “UML Extension” by Ian Utting. You can get it on the BlueJ site in the Extensions section.
This extension adds an item to each class’s menu (Display UML) that allows you to temporarily display the full UML notation of that class (including public/protected fields and methods). Just drop that extension into your lib/extensions folder, and off you go.
Regarding the second part of your request – better support for packages – this falls under the same argument. While I often wanted to have this for myself as well, I think this is just it: I want it for myself, not for my students.
Maybe when your projects get serious enough (or large enough) that you feel that you want a sophisticated package structure, it’s time to change your IDE. (The NetBeans/BlueJ edition, by the way, can open your BlueJ projects, and it can automatically convert the project structure into NetBeans’ preferred structure, with separate folders for source and class files, and packages. Of course, that’s not BlueJ then…)
Overall, the truth just is: we were tempted many times to add cool stuff to BlueJ. Sometimes they are user suggestions, sometimes they are things one of the programmers on our team wants to do. Often, we get these ideas because we’d like to use them ourselves. And it’s great fun to implement a really cool feature.
But at the end, BlueJ is designed for beginning students, and not for more experienced programmers, like many of you and me. And I have said no to many good ideas, often with a sense of regret. But I believe that is necessary to save the character of BlueJ as a whole.