NetBeans 4.0 beta is out!

I’ve already been blogging about NetBeans and its versions to come. Have a look at the first Beta of NetBeans 4.0 for yourself right here:

… and let’s just track when Eclipse catches up with Tiger support.


Pierre vs. Antoine

CoubertinPierre de Coubertin, the inventor of the Modern Olympics said The important thing in life is not to triumph but to compete” which is the often used quote in France “L’essentiel est de participer”. Although this is probably his most known quote, he must have meant something else! While the French don’t share the binary winner/looser paradigm, this is
a looser’s quote! While you may end up having this though after you
loose, image having this as your global state of mind. Quotes have too
much power and this one gives people reasons to hide. But as everyone
else I fall for quotes, so here’s a better one, close to Coubertin’s, but
better (IMHO) – “The notion of looking on at life has always been
hateful to me. What am I if I am not a
participant? In order to be, I must participate”
Antoine de Saint-Exupery.

Generics: First steps, first questions

when generics lead to generics...
So, moving along in my summer homework, I finally took some time to start playing (not just reading) with Generics.

Option 0 (Default):

        List<String> list = new LinkedList<String>();    // default (no issue here)
        for (Object element : list) {
            System.out.println (element.toString());

Option 1:

        // this code compiles (with lint warnings) and runs without type-safety
        List list = new LinkedList<String>();   // valid but what's the point?
        list.add(new Float(10));
        for (Object element : list) {
            System.out.println (element.toString());

Option 2:

        // code does not compile due to 3rd line
        // if you take it out, behaves like Option 0.
        List<String> list = new LinkedList();   // valid syntax
        list.add(new Float(10));   // compile error - cannot find
symbol : method add(java.lang.Float)

        for (Object element : list) {
            System.out.println (element.toString());

Option 3:

        // does not compile, types need to be the same. Inheritance doesn't work here.
        // but Abstract types are allowed (replacing Float with Number fixes the error).

        List<Number> list = new LinkedList<Float>();   // "Incompatible types" compile error
        list.add("ABC");    // compile error - cannot find
symbol : method add(java.lang.String)

        list.add(new Float(10));
        for (Object element : list) {
            System.out.println (element.toString());

Option 1 is strange, I’m not sure what it means and why it’s allowed. Compatibility with previous versions probably.

Sounds like Option 2 is nice because it does the same as Default, only
it doesn’t require you to type in twice the generic type. The only
advantage to Option 0 may be that it’s more readable.

Option 3 simply shows abstract types are allowed.

Update: On a similar note, check out this post


subversionLately I’ve been helping on the translation (from English to French) of the Subversion book from O’Reilly (a new generation Version Control System).
Actually, it’s the Open Source project official documentation and the
book is free at This is an interesting concept for O’Reilly. I wonder if  the translated
version will be free online as well. I think the times are tough for
book editors (may blog on this sometime after also reading this).

Subversion is meant to be a successor to CVS. It’s available at
So far the experience has been fun because quite different from my day
job but it is also hard for me to comment on the technical merits of
Subversion. The main difference with CVS is that directories are
first-class citizen, not just files. Most of the Subversion
improvements over CVS are based on this. I haven’t been thru this part
in great details, but the Client/Server support requiring Apache’s APR
(Apache Portable Runtime) seems a little overkill to me… Although
there are several Java clients (1, 2, 3, 4), I still wish Subversion was more Java-friendly (with, say better ANT integration).

Here are a few thoughts and questions I came

How many Content Management portals actually use a version
control system under the hood (like CVS or Subversion)? On a similar
note, since versioning is cheap with Subversion (no content
duplication), would it make sense to use it for some sort of history of
a website?

Obviously I’ve been wondering why it wasn’t written in Java (maybe not
a technical decision given the OS interaction needed by the tool isn’t
beyond Java’s capabilities). Also, if Mono existed when Subversion developments started, would it have
been used?

How many Open Source projects actually use Subversion today? At least one at Apache. I guess this book doesn’t really cover OSS development best
practices (how is it better than CVS for OSS?).

Have OpenOffice (for document versioning) & N1 Grid SPS (Application Provisioning, former CenterRun) considered using it?

I’m not through this book, but so far I believe not every Open Source project has such good documentation.
Also nice to see an Open Source project be well accepted in Microsoft land.

Summer homework (NetBeans & Tiger)

NetBeans 4.0
Blogs are usually a good place for reviewing new stuff. The issue for
Sun employees is that it’s tough to review non-Sun products because you
can be accused of biased criticism. But it’s also hard to review
home-grown products for the exact opposite reasons.

So I settled on things I had to do (sort of my summer homework): NetBeans 4.0 (the post-Eclipse release), Tiger (JDK 5.0) new language features, and the O’Reilly “Java 1.5 Tiger” book. So this is really meant  to be a review of this combination and this is only the first post.

I’ve had Tiger installed for a while but mostly played with its experimental monitoring tools (sort of the successor to jvmstat) as well as with the new Ocean/Synth look-n-feel.
After picking up the latest netBeans 4.0 Q-Build (I did try using
NetBeans 3.6 and managed to do quite a bit, but 4.0 has proven to be so
much better), I went on to download the book’s companion source code
which comes with an ANT build file to compile and build the book
examples. NetBeans 4.0 smoothly created a project based on this archive
and custom ANT script. The project system is now fully built on ANT
which makes its targets (build, compile, clean, …) available outside
the IDE, allowing nightly builds and easier sharing with other

The other good surprise was the IDE look-n-feel
(tiger’s new Ocean/Synth lnf certainly helps) and the window manager
enhancements (some things remind me of Creator), it’s really neat. See these snapshots (click to enlarge) :

nb_snapshot nb_snapshot

Back to the project I just created. ANT being so integrated in the
tool, I first had the feeling that it was the only way to go even for
running a simple file, which I though was overkill. This prooved to be
wrong, you can use a “Run File” or “Debug File” menu. There’s also the
clean notions of a platform (set of libraries) and a project properties
(a compiler, an interpreter, a debugger, etc.). A platform and
project settings are now first class citizens and not buried in the
tool’s options. For those using NetBeans today, note there’s no more
“mounting” to do. Those that were used to it will probably miss the
feature, not everyone else ;-).

Having created this new project, I was all set and ready to
develop/run/debug my Tiger examples. No extra step needed to use the
appropriate compiler and options to recognize the new syntax, to
provide code completion, etc. You can use NetBeans 3.6 to develop with Tiger,
but this is where I found using the latest version was so helpfull.

Chapter 1 was a pretty soft introduction to Tiger new language
features, I’m off the Chapter 2 (Generics!). More here as I move along.

So far so good, very good.

Tiger not “compatible”?

What does compatible mean?

I just read this article claiming people are afraid compatibility will be broken with Tiger (JDK 5.0).

My experience so far is that existing applications run just fine with Tiger (just did another validation today with an ISV who’s last Java certification was on 1.3.1 and everything just worked fine). As a matter of fact, Tiger’s #1 objective is to provide quality (read Compatibility, Compatibility, Compatibility). I really think it’s delivering the promise so far. The whole point here is that you can benefit from the implementation improvements (performance, tuning, management tools, etc…) by moving to a new version without having to adopt all the new features of a newer JVM and without breaking your
development. I have to admit that not all parts of Java were created equal when it comes to upward compatibility and your mileage may vary.

Of course, using Tiger’s new language features will require a 5.0 runtime, but this is the same as for Reflection, RMI, or EventModel in 1.1, JFC/Swing or Collections in 1.2, JNDI in 1.3, Assertions, regular expressions or NIO in 1.4, etc….
Also the article confuses MSVM (which was never really Java) migration with the adoption of the upcoming 5.0 platform. These are really separate problems :
moving away from MSVM often requires rewrites (use the Java Upgrade Tool to assess), moving to Tiger just shouldn’t (never say never).

There are too many good things in Tiger to ignore it.