Reflection on JavaOne 2005, Page 3
Again, apparently following creator queues, NetBeans has data-binding capabilities. These allow you to drag and drop fields and data elements from a number of sources (including database tables, beans, and EJBs) into a GUI, and a suitable component will be created and bound to that data element.
J2EE and the out of box experience
Netbeans, starting with 4.1, has been about the "Out of the Box Experience." The idea being that the inclusion of good J2EE EJB support and high quality GUI builder mean that simply installing the software gives you more scope for being productive than a number of competing IDEs. With many of the alternatives out there (certainly most of the free ones), it is necessary to find plugins to develop EJBs and even GUIs in some cases. This is not a huge problem, and it is an exercise I have been through a couple of times, but the ability to do so much after a quick install is very seductive, and folks who are coming from a Visual Studio world and just expect this kind of support to be there will find a lot to like in NetBeans.
To try out NetBeans, you have two options; either go for the safe and stable 4.1 version from http://www.netbeans.org/community/releases/41/index.html or download one of the developer releases of 4.2 from http://www.netbeans.info/downloads/download.php?a=n&p=1 and then you can enable the new Matisse GUI builder by following the instructions at http://www.netbeans.org/kb/articles/matisse.html.
Following the current commendable trend to make life easier for developers, there was a lot of information about and interest in EJB 3.0, the upcoming major revision of EJBs (one of the most powerful but currently most complex aspects of J2EE). The new version will use new features of the Java 5 language (mainly annotations) to simplify the creation of EJBs. It will no longer be necessary to write Deployment Descriptors, and the distinction between Home and Remote interfaces also has been removed (at least as far as the EJB creator is concerned).
EJB 3.0 will maintain backwards compatibility with EJB 2.1 (and yes, you can still write Deployment Descriptors if you want to). The upshot is that EJB 3.0 will be a much more accessible standard, without losing any of the power of EJBs. Persistence has also been overhauled, with the result that it looks a lot like Hibernate but using annotations.
I won't go much further into this subject right now because it really could be a separate article or stream of articles. Suffice to say that this is, in my opinion, another important move in the right direction. For more information on what the new EJB 3.0 specification means, have a look at http://java.sun.com/products/ejb/.
One of the announcements that I surprised myself by being interested in was that the new Blu-Ray standard for the next generation of DVD players would include an enhanced form of the J2ME platform. It got me thinking about some of the possibilities as a Java Developer.
Blu-Ray is one of two competing standards for the next generation of DVD players, the other being HD-DVD. Currently, Blu-Ray seems to have the upper hand and the inclusion of a full programming platform is extremely interesting. While the processors will (at least at first) not be powerful enough to do anything like First Person Shooters, the possibility of games naturally occurs to me. Also, Java code can execute and interact on screen even while a movie is playing (unlike current DVDs, where a separate menu screen is usually required for user interaction). While I can sit here and punch out a few ideas about how a J2ME environment could be used in a DVD player, the truth is that the most exciting possibilities will probably occur to others. Embed this kind of flexibility into anything, and someone somewhere will always blindside you with something very clever and useful. 50 gigabytes of storage is a lot to be able to play with in an application.
GPS Binding from J2ME
Unlike the Blu-Ray announcement, which was something that I had not really considered before, this announcement pleased me because this is something I have wanted for a long time.
For the last few years, most new cell phones have been built with a GPS receiver inside them. It is usually only activated for 911 calls so that emergency services have another option to locate you in case of trouble.
As a GPS enthusiast, I have often wanted to have a way to access this in other ways in my phone. I do have a handheld GPS, but the data on such a device is always limited either by what is made available by the GPS manufacturer, or what you can fit in the limited memory.
Now, a GPS in a phone has a lot more potential. Imagine using WAP to contact Google maps, send along your current location from the GPS built into the phone, and find the nearest coffee house, EB games, or anything else your heart desires. Google already works to keep these points of interest up to date. Furthermore, imagine downloading a small J2ME app that then would be capable of providing you with real-time driving or walking guidance to your chosen destination, all from your phone. I personally can't wait until I can get a hold of one of these new devices, and when they get out in sufficient quantities to interest the Googles and Yahoos to provide these kind of services.
Scripting Language Enhancements to the JVM
Another welcome announcement (at least for me) was the enhancement of future versions of the JVM to allow scripting languages to do more in the VM.
One of the oft-touted advantages of .NET is that the CLR is language agnostic, while the JVM is not. Neither of these statements is entirely true.
Although different language syntaxes can be run in the CLR, they end up looking quite similar at the end of the day because the libraries used are identical. This is not a bad thing; it is just a little misleading.
The JVM actually can do exactly the same, which surprises a lot of people and is not well known. As you can see at http://www.robert-tolksdorf.de/vmlanguages.html, there are a very large number of "languages" that can run on top of the JVM. Again, you end up with many of them having the same "flavor" as one another due to them all using the same class libraries.
In the past, I have used two main alternative languages on top of the JVM, those being Jython and Groovy. It is no accident that both of these are what are known as "Scripting" languages. In practice, Java is a pretty good compromise between a simple language and a reasonably efficient one. Although many other languages can run on the JVM, unless they really bring something else to the party, I will use Java because I know it.
The reason Jython and Groovy are both interesting is that they each have some serious strengths in areas where Java is a little weaker. For example, Jython (like Python upon which it is based) is extremely strong at text parsing and manipulation. There is no need for MessageFormat classes, string tokenizers, and so forth. Instead, you can very quickly manipulate strings in Jython. It also has a more compact introspection model than Java, even in the Jython form.
Groovy, on the other hand, is so ridiculously good at SQL and XML handling that it is not an exaggeration to say that something like a translator from SQL to XML will be well under one tenth the size of the equivalent Java code to accomplish the same.
There are two prices you pay right now when using scripting languages on top of the JVM. The main one is speed, and the other is that there are limitations imposed by the JVM that somewhat limit some of the more dynamic possibilities in a scripting language. For example, anyone who has used Python (or C Python, as the C-based version is sometimes called) and Jython will know that some of the more advanced introspection operations are not possible in Jython.
The announcement of JVM enhancements with scripting languages in mind will hopefully address both of these issues to some extent. Although scripting languages will always be slower than a more efficient part-compiled language, some of the inefficiencies right now come from working around limitations in the JVM. Furthermore, hopefully some of the more advanced scripting features will also be possible.
This enhanced scripting support is slated to be included in the Java SE 6 (Mustang) release.
Sun has introduced a new range of low cost, high performance workstations called the Ultra-20s and based on the excellent AMD opteron architecture. While this is not, strictly speaking, Java news, Java is of course a first class citizen on this platform, and I cannot imagine a better price/performance point for developing (and maybe even running) Java applications. The workstations have the interesting ability to run 64-bit Windows, Linux, and Solaris well on the same hardware.
Potentially even more interesting is the purchase options. You can either buy the box outright starting at $895, or you can go the service purchase route and get it for free. Basically, somewhat like a cell phone, you can buy a Sun services subscription for three years at $30 per month and get the box for free. I am interested in how well that plan does. Full Java development tools and enterprise environment is included (see, it does have something to do with Java after all). http://www.sun.com/desktop/workstation/ultra20/.
Finally, this is another one of those off-the-wall interests that I picked up while at JavaOne. The Sun SPOT (Small Programmable Object Technology see descriptions at http://sig9.com/node/244 and http://research.sun.com/spotlight/SunSPOTSJune30.pdf) is a wireless sensor that has wireless networking capability built into it.
The Sun SPOT is capable of creating a mesh network on the fly, and runs a small Java-based VM called the "Squawk VM." This is another one of those things that I can think of several interesting ideas up front (for example, if put in sufficient numbers of cars along with a GPS, it could be used to provide anonymous data about traffic holdups, and enable drivers to route around the problem without making it worse), but again the most interesting ideas will probably come from getting these sensors out there and seeing what killer applications people think up.
As well as the above, there were a large number of vendors in the Pavilion showing off their wares. I was pleasantly surprised to learn that Google's Gmail and Blogger tools are written in J2EE for the server sideI suppose it's obvious but even as a regular user of gmail I had never given it any thoughtwhich is probably the best recommendation I could give Java EE (it just works, why worry about it).
The overall feeling that I came away with from JavaOne 2005 is the pace and diversity of Java development. From Blu-Ray to mobile phones, huge enterprise systems to Sun SPOTs, Java is just about everywhere (yeahI know this is the slogan, but think about itit's actually true).
This is a great time to be a Java Developer.
About the Author
Dick Wall is a Lead Systems Engineer for NewEnergy Associates, A Siemens Company based in Atlanta, GA that provides energy IT and consulting solutions for decision support and energy operations. He can be reached for comment on this and other matters at email@example.com.