Skip to main content

JSF Support in Eclipse Europa and NetBeans 6.0m10

Posted by cayhorstmann on July 3, 2007 at 11:41 AM PDT

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

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 href="">these
simple directions.

Unfortunately, you are still not quite ready to use JSF. You have to
carefully follow the instructions in the excellent blog by href="">Jeroen van Wilgenburg
and set up JSF libraries. Jeroen uses myfaces; for GlassFish you need to
include javaee.jar and jsf-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 href="">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

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


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


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 href="">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

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.

??? style="float: left; margin-right: 1em;" />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.