Creating client-side Java applications just got a whole lot easier.
This year, Monday was "day zero" of the JavaOne event.
The CommunityOne agenda included tracks on NetBeans,
Linux & Solaris, OpenJDK/Mobile, Web 2.0, GlassFish
(open server), and OpenSolaris.
I sat in on the NetBeans sessions, with a side order
of JRuby and Rails. I picked up a lot about creating
web apps with Rails. I'll cover that in a future post.
But I've got to tell you, it was pretty darn impressive
how much easier it has become to write a good client-side
app in Java. NetBeans 6 isn't quite at the point where you
can just press a button and have the whole application
written for you, but it's getting remarkably close.
In Monday's NetBeans session, a database application
with menus, dialogs, pictures, and an online map
was created in 4 minutes. Total amount of code written
for the project: one line. It took advantage of a
terrific mapping component available from Sun Labs, but
the really cool part was the way everything was put
The demonstration featured several client-building
capabilities that have been developed in tandem.
Working together, developers working on Swing,
NetBeans, and the GUI framework have put
together a series of capabilities that spell
c-o-n-v-e-n-i-e-n-c-e for client-side developers.
With the Matisse GUI builder that is part of NetBeans 6,
you can drag and drop components into your application.
Built on the GroupLayout manager, the components then
auto-snap to one of several predefined distances,
and you can align easily the baselines of label text and
text in a field. You can also select a group of components
and enclose them in a container, or "duplicate" the group,
which automatically resizes the window to make room.
Duplication also preserves the alignment of the components,
which is handy when you're building a table of components.
Other notable features included the ability to drag a
component from another project without having to add it
the palette first, category headers in the palette to make
it easier to find things, the ability to sort the palette,
plus support for interface localization and choosing the
look and feel you want. (The only GUI-building feature that
wasn't demonstrated was window-resizing. That's a
process that can consume a lot of time--especially
with a layout manager that's as tricky to use manually as
Matisse. Fortunately, auto-resizing is a feature that's
said to be on the table for upcoming development.)
Next to GUI layout and resizing, wiring (connecting
things together) is the most time consuming of the mechanical
tasks in the GUI-building process. NetBeans 6 adds a
binding tool that lets you point to things and say,
"when that GUI element changes, poke the model over
here, and when that value changes, update this,
that, and the other gizmo". Enabling that capabability
are the Binding class and the BindingGroup class.
When you're doing it manually, you add a pair of entries
to the Binding class, or add sets of pairs to a BindingGroup,
and then invoke bind(). To get the behavior you want, you
choose one of the three synchronization strategies that
Binding objects implement: read once from the source
object, continuous updates (one-way), or full synchronization
(two-way). In addition to data converters, you can also
specify validators for the full synchronization option,
as depicted in the component-binding diagram:
NetBeans 6 also adds dialogs for defining Actions,
so you can say what is supposed to happen when a user
clicks a button, selects a menu item, or issues
a particular combination of keystrokes--and only
say it once. In the code, actions take advantage of
a new annotation: @Action. Instead of creating an
Action class and wiring up the event handling, you
just add the annotation. Deep under the
covers, all of the infrastructure is taken care
of for you.
Building the interface is only part of the process, of course.
You've still got to get the bugs out of the app, maximize
performance, and make sure you don't have any memory leaks.
(They're still possible, even with Java's automated
garbage collector. One good way to get a memory leak is to
create static variables. Long after the object has gone away,
the class definition still has those static pointers hanging
around, referencing objects that probably should have been
To improve those aspects of application building, NetBeans
has added or improved several key features:
NetBeans 6 adds expression stepping, so you're not limited
to debugging a line at a time. You can step over parts of
a line to get to the expression you need to step into. There
is also an Instances view that lets you see all instances
of a particular class and identify all objects that hold a
reference to a particular instance. (There is no
back-in-time debugging, as yet. But as useful as that
capability occasionally is, I've noticed that it also
complicates the debugging interface quite a bit. So it
seems wise to me that back-in-time debugging is a lower
priority than some of the other features the team has
Profiling is now part of the base release, so you get it
without having to add additional packages to NetBeans 6.
The profiling demonstration showed dynamic graphs and
pie charts with drill-down capabilities, in addition to
the standard list display. The profiling capabilities
also include integration with jmeter scripts (to create
a load for a web application, for example).
The combination of profiling, the instance view, and
a jmeter script makes it pretty easy to identify
the source of a memory leak. With the application running
under load, you watch the number of instances for each
object type grow. After a while, they tend to reach a
steady state, where X number of objects of a given type
are sufficient to handle the incoming requests, and the
instance count bounces up and down around that number. But
when you have a memory leak, the instance count for the offending
object will soon sort to the top of the list, and will just
keep growing and growing, never diminishing.
Once you know which objects are avoiding garbage
collection, you can go to the instances view to see who's holding
on to the pointers that reference them. From there, you
can go straight to the code to find out what changes to make.
After you've built an application, got it running right, and
got it running it fast, you still need to deliver it to your
users--as well as any updates that happen to be needed from
time to time.
The NetBeans demo featured a quick point-and-shoot process
to enable Java Web Start for the application, but it was
so quick I missed the details! But I'm sure it will come up
again in one of Tuesday's sessions: "Easy Deployment is
Can't wait for that one. Stay tuned.
Note: I caught the session, and I'll be blogging on
it later. The good news: The JRE will be a heck of a lot
easier to install, you'll be able to invoke the
installation operations programmatically, and JRE updates
will patch the existing version instead of adding
another copy. (Yay!) The bad news: Although the JRE
will be way easier to install, you're still on your own when
it comes to installing your application. (Java Web Start
could be the ideal vehicle for that, but it's security
sandbox is too limiting, especially since user-granted
permissions aren't sticky--they have to be re-granted
every time the user starts the app.)
Yeah. It's pretty amazing stuff. The app was pretty much a one-table update, and of course the really interesting database works comes from joins and table relationships, but it was still a great demonstration of getting the mechanics out of your way, so you can focus on the problem.
And you're right. It sure would look great on a resume--even if you don't know what you're doing. :_)
> Yeah. It's pretty amazing stuff. The app was pretty much a > one-table update, and of course the really interesting > database works comes from joins and table relationships, > but it was still a great demonstration of getting the > mechanics out of your way, so you can focus on the > problem.
I suspect now the problem is figuring out how to extend the magic to custom views, non-trivial mappings, joins, and relationships.