Summary
This article is my end-of-show wrap up, with notes on a variety of announcements and things. It compares Groovy to BeanShell, describes great new announcements like AJAX and Hibernate, and takes a look at a radically new concept that was a major theme of the show--EASE OF USE enhancements coming up in J2EE, NetBeans, and Java Studio Creator.
Advertisement
It was a great show, with some exciting new technologies to cover including
Groovy, JackPot, and the NetBeans Colloboration APIs. The final day had some
good stuff, but at the end of the day I still had my socks on (translation:
no earth-shattering revelations occurred), so I decided it was time to write
my traditional "wrap up" article.
A funny thing happened on the way to writing that article, though. So many ideas were spinning around in my head that it took a week to capture them all. Those thoughts will appear in an upcoming series of articles. But now, at last, here is my wrap-up article for JavaOne 2005. It covers:
BeanShell vs. Groovy--Which Script Engine is Right for You? #
As I wrote in It's
a Groovy Day!, Groovy is one sexy scripting engine. But BeanShell
has been around for quite awhile. In fact, it pioneered the whold concept of
scripting engines for the JVM. Here then, are some reasons why you might want
to choose BeanShell:
"Pure" Java syntax. Groovy has added it's own
syntax, using square brackets to create lists for example, and adding ==~
as a pattern-matching operator for Strings. Since BeanShell restricts itself
to existing Java syntax, it never has to worry about a future incompatibility
with the Java language
Smaller footprint. Beanshell is tiny--a minute fraction
of Groovy's size. If you need a scripting engine in a cellphone, this is
the one to use.
Faster. In addition to beeing smaller, BeanShell doesn't
build classes. Groovy has a runtime dependency on ASM, a tool that builds
byte codes for classes dynamically. After building a class, Groovy runs
it. BeanShell skips all that and interprets your scripts directly.
Dynamic. BeanShell creates a small stub that the JVM thinks
is a class it's executing. That creates the interesting capability to hack
a BeanShell script while it's running as part of a servlet, so you don't
have recycle the servlet to test your changes.
Available today. It's there now. It runs. No waiting.
Here, on the other hand, is the short list of reasons why you might prefer
to use Groovy as your scripting engine:
It's sexy. Things like pattern-matching operators really
float my boat. I find that stuff a great selling point. I want my language
to make it easy to do the things I do frequently.
It's powerful. The ability to apply closures
(unnamed blocks of code) to whole collections using commnads like Collection.each,
Table.eachRow, and File.eachLine let you get a lot done
in a few lines of code.
It's cool. It's sexy. And it's powerful. What's not to
like?.
It's compilable. It's already building classes, so all
it has to do is save the classes so you can run them directly or use them
in your application.
It solves "point of pain" use cases for developers. The
ability to add functionality to ANT scripts and replace XSLT for XML processing
are just two of the many areas in which the language has been explicitly
designed to solve problems for developers.
I never got to see this, but from the sound of things, it's going to make web
applications virtually indistinguishable from their desktop cousins. The Asynchronous
Javascript and XML (AJAX) engine enables client buffering of data and manipulations
that let you smoothly pan across a map, for example, instead of jumping from
screen to screen. Apparently, the image buffering goes on in the background,
so it's transparent to the user (depending on network traffic, I'm guessing).
Fromt the sound of things, Ajax is going to usher in an era of truly distributed
computing, where the application you're running over the web is indistinguishable
from one running on the desktop, without requiring a monstrous connection speed.
It could also let a web-based email client load messages in the background and
let the user scroll through them, instead of paging through 25 at a time..
Hibernate was getting a lot of buzz at the show. I never got a chance to look
at it, but I'm told it's a lot easier to use than JDBC. Apparently, it uses
reflection to persist your objects to a relational database in an intelligent,
query-able way (rather than saving them as Binary Large Objects (BLOBs), for
example.
I saw this tagline on a slide at the convention: "NetBeans 4.1 is not
your father's NetBeans". From where I'm sitting, that looks like the truth.
There are plenty of new features on the way in NetBeans,
including:
A better layout manager
An interactive GUI designer
ANT-based builds
Support for remote collaboration, as described in Share
the News!
Restart your application "on the fly", to speed up the test-run-debug
cycle.
Refactoring that includes EJBs as well as server code.
"Logical" project view, to hide files that provide the "plumbing"
Code folding, to hide event-listeners and other such wiring, so you can
focus on application logic
Drag and drop external resources, like an EJB, database, or JMS messenger.
Wrappers are automatically constructed so you don't have to.
And all of that is in additon to a great suite of tools for testing, refactoring,
and debugging server-side apps and client apps.
Java Studio Creator--To Simplify Web Development #
Due out later this year, Java Studio Creator is an IDE based on NetBeans that
makes it really easy to build a web application. Here are some of its
features:
The GUI design tool operates graphically. You can drag components from
the default library, and you can drag a line between a label and a field,
for example.When you set the "required" property on the field,
the label automatically gets an asterisk, and the system ensures that a
value is filled in before the form is accepted--so you write less code to
check for errors and spend your time processing data.
You can define "virtual forms" for master/detail relationships,
so you process those parts of the form that have actually changed.
The look and feel of JSF components can be changed all at one time by dropping
in a jar file that defines the "Theme"--or create your own.
You can import component libraries provided by other vendors, and target
the application for a variety of web servers.
New application models simplify the process of building an application
and keep the wiring hidden away, out of sight.
One of the new application types, portlets, lets you export a
WAR that can be deployed on a portal server.
J2EE Ease of Use--A Phrase You Never Thought You'd Hear #
The next version of the J2EE specification is explicity target at--get this--ease
of use. A lot of effort is going into tools to take the pain out of J2EE
development, as well. The combined result of these efforts may well be something
like a reasonable development environment.
This is coming from a J2SE guy, you understand. I've looked at J2EE before,
but the wiring was pretty darn complex. XML descriptor files had to describe
things in other XML descriptor files that matched the source code.
It was difficult to get everything to work properly for a simple web application--much
less a full-blown business application with EJBs and all the rest. So I pretty
well stayed on the J2SE side of things, where I could make a bit more sense
of things. But that could change. Rapidly.
Some of things that are coming include:
Annotations. Use of annotations in your source code to
describe components, instead of external XML descriptor files. That's easier
to maintain, and the number of descriptor files drops from 9 to 2--so innstead
of writing 792 lines of XML, you're writing 26.
EJBs as POJOs. EJBs become Plain Old Java Objects (POJOs)
so you can extend them
NetBeans improvements. As mentioned earlier, NetBeans
is making it a lot easier to develop web applications.
Java Studio Creator. A way to take the pain out of web
development.
GlassFish. Sun's Application Server 9 for J2EE and basic
web apps, which will be open sourced. (App Server 8 made humungous strides
in the ease-of-use department, compared to App Server 7. It will be interesting
to see what things are like in App Server 9.)
As part of Sun's commitment to making life easier for developers, they recruited
Paul Anderson of the Anderson Software Group (http://www.asgteach.com)
to teach people how to use Java Studio Creator. The presentation and lab exercises
were smooth and well-paced. They displayed the polish of a professional educator.
Of course, all the polish in the world wouldn't have made much difference if
Creator were difficult to use. So it was the right combination of product and
presentation. In other words, J2EE is growing up. It's becoming less about technology,
and more about getting things done.
The guiding principle in all this appears to be "things just work".
Things are getting simpler, and the tools are taking over the complicated wiring
and keeping the plumbing hidden behind the walls. You do less, and the container
does more--so you can focus your attention on the problem you're trying to solve
instead of spending your time on implementation details.
Hibernate is a Java/SQL ORM (Object Relational Mapping) tool. I use Hibernate. In my opinion, Hibernate is not hopelessly broken proprietary junk. It has the same goals as TopLink and many other tools. These have been out for over 10 years. It is at best, a better mouse trap, not a revolution. So far it seems that ORM is, in general, a costly problem to solve, and all the ORM tools I have used reflect that.
Sorry to hear you couldn't come by to see the AJAX stuff.
We had a booth and were showing General Interface along with an announcement that anyone can get their hands on a free eval preview version before it gets to the general public.
Also InfoWorld's Jon Udell has a video of it in action. See this, more and sign up for the Accelerator Program at:
HttpXMLRequest() (the single built-in function that makes AJAX possible) can only send/receive XML. It can't upload or download binary data (such as images). However, it can, just by modifying the page, get the browser to download and show the images.
So, for the maps to work, it must add an <IMG> or equivalent element pointing to a (possibly dynamically generated) image on the server. The browser caches the image and displays it.
I imagine some combination of a small browser cache and moving a long enough distance on the map could cause the browser to replace old cached image data with new data. This would mean when you moved back it would redownload. I imagine the browser makers fixed any bugs with traveling back to images that were forced out of the cache back in the 90's.
I imagine designers may have to dodge a couple weak points of browsers to get this to work well. But the majority of the heavy lifting (threading, caching, displaying, scrolling) is done by the browser, which can load multiple images at once and cleverly caches images. The server has some of the work too, but it can work pretty statelessly, I imagine.
Previous Topic
