Skip navigation

Today is 07-07-07, "lucky sevens" day, considered fortuitous for weddings and gambling. But for me, it was not a lucky day. I read the Java (TM) SE 6 Update Release Notes and was overcome with number melancholy.

Here is Dürer's famous engraving “Melancholia”.


On the upper right corner, you see the world's most famous magic square:


The rows, columns, and diagonals, all add up to the same value. What could be more pleasing, more regular? Yet the saturnine fellow is not happy.

I am not happy when I read this:

Changes in 1.6.0_02

The full internal version number for this update release is 1.6.0_02-b05 (where "b" means "build"). The external version number is 6u05.

What signal does this send to the outside world? I think the signal is “Java is stupid.”

Let's not dwell on the internal numbering. That's an annoyance that consumers hopefully never see. (It would be nice to have a system property that enables us to report the “external version number” to the consumer without parsing thejava.version string.)

First off, I fervently hope that the correct external version number is actually 6u2 and not 6u05. I think that was just a typo in the release notes. If not, someone take me away right now...

But that's not my main gripe. Can we get rid of the crazy “u” notation and the “update” term? These are not terms that consumer will readily understand. Whenever my students go to download a Java JDK or JRE and see “update”, they think it is like a Windows service pack and hunt for the base version.

Why not call these versions 6.01 and 6.02? That's something a consumer understands.

I am so glad we finally got rid of the Java 2 version 1.x.0 nonsense. Could we now go all the way to normal, boring, meaningful version numbers? Please.

When Eclipse Europa was released on June 29 (together with the iPhone and the GPL 3 license), I wanted to know if it did anything about one of my many pet peeves: tool support for writing JSF apps. In this blog, I will compare Eclipse 3.3 and NetBeans 6.0 milestone 10 to see how they do on the world's most mundane JavaServer Faces application: the login example from Core JSF.


Installing NetBeans was a breeze. You have the choice between Basic, Standard, and Full. I downloaded Standard and ran the installer. It installed NetBeans and GlassFish, and I was all set to start a new JSF project.

Installing Eclipse is easy if you know what to do: Grab the "Eclipse IDE for Java EE Developers". (I first downloaded the "Eclipse IDE for Java Developers", hoping I could select the JSF add-on, and have the plugin manager resolve the dependencies. I never even found the JSF addons in the morass of plugins, most of which had names that made no sense to me.)

After installing Eclipse, I hooked it up with GlassFish, following these simple directions.

Unfortunately, you are still not quite ready to use JSF. You have to carefully follow the instructions in the excellent blog byJeroen van Wilgenburg and set up JSF libraries. Jeroen uses myfaces; for GlassFish you need to include javaee.jar andjsf-impl.jar.


Maybe the GlassFish plugin could take care of that?

You will also need to change the Eclipse startup configuration to give it more memory, as described here. Otherwise, you will get frequent crashes such as this one:


Adding a JSF Page

This should not be rocket science, right? Right-click on the "pages" node in the project and select "Add JSF page".

Unfortunately, it is not so easy. In Eclipse, you add a JSP page:


Then you get a wizard whose second page looks like this:


According to the online help, you are now supposed to make a JSP page and add the taglib or namespace declarations. WTP? Does Eclipse hate JSF programmers? Why not include a template "New JSF file"? Fortunately, it is an easy matter to make such a template.

With NetBeans, you get a seemingly useful "Visual Web JSF Page". Unfortunately, as you'll see later, that choice is problematic. Instead, choose JSP.


Now you get this dialog:


Again, there is no option for a JSF file, and there isn't any apparent mechanism to provide a template. You have to make a JSP file and then paste in the taglib or namespace declarations. NetBeans really hates JSF programmers.

EL Autocompletion

Defining a managed bean worked in both IDEs. Annoyance in NetBeans: I can't set the EL name for the bean in the dialog. Annoyance in Eclipse: When I change the name of the bean class, it doesn't automatically update faces-config. Both IDEs can autocomplete the bean name and its properties as you would expect.

In Eclipse, I can use the faces-config editor to add a resource bundle, and I get autocompletion. NetBeans doesn't seem to have any support for resource bundles. When I manually add the resource bundle into faces-config.xml, NetBeans still won't autocomplete. NetBeans really needs to fix that before the final release.


Navigation Rules

Both Eclipse and NetBeans have serviceable visual editors for adding navigation rules. Here is the Eclipse editor. Note the cheat sheet on the right. Without that, I would not have been able to work the editor since right-clicking on the arrow brings up a completely useless context menu.


Visual Page Editing

It took me a while to discover this feature in Eclipse. You need to right-click on the JSF page in the explorer pane and then select "Web Page Editor".


You get a serviceable editor that lets you drag components into a h:panelGrid or h:dataTable.


I could not see how to visually edit an existing JSF page in NetBeans. You can start a new "Visual JSF Page", but that is an entirely different animal. You essentially get the editor from Java Studio Creator. If you like Creator, then this is a good thing. You now have a way of linking your Creator pages to your Java backend code in a single environment.

But I don't like Creator, for two reasons.

  • The widget set seems fairly nice but it is not standard. I'd like to learn one standard widget set. Can you imagine how much worse the lot of the Swing programmer would be if they had to learn a different component set for each project?
  • I am forced into a specific programming model, with a backing bean per page and the use of binding. This may feel comfortable to Visual Basic programmers, but to me it is not in the spirit of JSF. I prefer to share a bean among related pages, and I prefer to use the value attribute to link form values to beans.

I fussed with the code, ripping out the Creator code and adding plain JSF code. That just confused the design mode. At least in this milestone, it seems as if the visual page editor in NetBeans is limited to Creator pages.

I didn't try adding a third-party component to the palette. There just isn't enough oomph in the JSF standard to support that.


Both Eclipse and NetBeans are supporting the basics, in particular autocompletion of JSF tags and EL expressions. For the purpose of JSF development, neither IDE seemed particularly slick to me; procedures for achieving common tasks seemed haphazard, unflexible, or unintuitive. At this point, I prefer Eclipse, but not by a huge margin. To gain parity, NetBeans needs to support resource bundles, make a wizard for adding genuine JSF (and not just JSP) pages, and rig its visual editor to handle non-Creator pages.

???Soapbox: In 2001 (!), JSF was envisioned as "Swing for the Web", a standard framework for delivering high quality web applications. I remember asking Amy Fowler at the 2002 Java One whether it will include professionally designed components similar to those in Swing, and she said "of course". Unfortunately, in 2007, we still don't have a standard set of widgets that is needed in practice, such as tabs, breadcrumbs, header/footer, menus, etc. etc. We also have no standard way of plugging third-party component sets into visual tools. JSR 314 promises JSF 2.0 by April 2008, with a huge laundry list of desirable features. A standard widget set is not among them.