BlueJ features – where do we draw the line?

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.

4 thoughts on “BlueJ features – where do we draw the line?

  1. You are right to keep it simple. But there are two menus missing that even my beginners desperately miss:

    1. The Windows menu
    If you work with more than one project the window you need is mostly hidden by others. So you need a Windows menu in BlueJ. Under MacOS X I use Exposé in BlueJ more often than in all other applications (as a sum!). But under Windows…

    2. The Methods menu
    In the editor the pupils often scroll and scroll to search a method. A Method menu where you can select the first line of each method would be VERY helpful.

    Greetings from Germany,

    Horst

  2. Hi all,

    of course it’s my opinion, but after here I’ll list my thought’s about BlueJ and would like to know what others are thinking about them:

    – Applications and libraries with many files and many
    lines of codes are mostly projects with more than
    one developer. Shared development is not really a
    topic for this IDE, is it?
    – It doesn’t make sense to extend BlueJ being
    like eclipse, right (so you could use eclipse) !?
    – Much more powerful than additional tools are
    features for the editing of the source. As an
    example you should have a look a some editor like
    vim or emacs. The main idea is simplify many task
    (coming again and again) while editing:
    – auto completion of words still present somewhere
    in the source; now: “com” and you
    could get “completion”.
    – Highlight your search.
    – automatic comments for methods with parameters.
    – …….many many more……

    conclusion(s):
    – If BlueJ isn’t enough to your needs you could
    choose something like eclipse as an
    alternative!?!?
    – Extending existing components to be more powerful
    instead of implementing new components!!!
    Much better having each component at 99% perfect
    instead of having 100 components at 50% perfect!
    – Concentrating on the editor it’s the main
    environment of an developer.
    – Never, …, never break the KISS principle!
    (Keep It Simple Software)
    – Some projects I would prefer developing with
    BlueJ and some with Eclipse. I think you can’t
    change this also NOT every langauge is suitable
    for every problem.

    BlueJ people have done good work aand they should
    continue this…

    best regards,
    Thomas

  3. Quite right to keep the line at the first year of programming, but some institutes do more in the first year than others. When the focus is on Objects First, Object modelling and simplicity BlueJ should keep the lead in keeping features from creeping towards professional IDE’s.
    Since the UML-like BlueJ window is what student see so many times, they get familiar with looking at software with a class-model view from the start. It is a pity though that relations in this model are allways of the ‘uses’ kind ( – – -> ) while associations and multiplicity are one of the first things a student learns along with the class concept.
    So it would be nice if the model window could be tweaked just a bit more so that students don’t need to use wordart, paint, or visio to make it a bit better model. It also makes it more realistic: you need to keep model and code in sync manually (just as you need to remove uses arrows now when code is changed).
    BlueJ is not just a simple Eclipse/netbeans: it acts as a (very!) simple Poseidon/Visual Paradigm too.

  4. I have to say that I love BlueJ. I am a Professor and a doctoral student and I use it all the time for both my students and my studies. It gives the students many visual features not available in Eclipse or any other IDE.

    I agree with the approach of limiting it to first year classes, but the features are so powerful that many others will use the IDE. So let me through my support to drag and drop editing, which is available in most every produce e.g. Word. Students are used to the feature and really miss it.

    On a personal note, I would like to see a full implementation of class diagrams. If we incorporated the addin for class diagrams in the main window as a switch, I think the result would be a very valuable teaching aid.

    Thank you for a great book and great IDE.

    Don