|
|
|
Sponsored Link •
|
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:
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:
And all of that is in additon to a great suite of tools for testing, refactoring, and debugging server-side apps and client apps.
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.
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.
Previous articles in this series:
Resources mentioned in this article:
Have an opinion? Readers have already posted 3 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Eric Armstrong adds a new entry to his weblog, subscribe to his RSS feed.
 | Eric Armstrong has been programming and writing professionally since before there were personal computers. His production experience includes artificial intelligence (AI) programs, system libraries, real-time programs, and business applications in a variety of languages. He works as a writer and software consultant in the San Francisco Bay Area. He wrote The JBuilder2 Bible and authored the Java/XML programming tutorial available at http://java.sun.com. Eric is also involved in efforts to design knowledge-based collaboration systems. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit