JavaOne 2006 might be only a few months old, but a summer feels a like lot longer than that. What were the trends and are they still hot?
JavaOne conferences seem to come in three different flavours – announcement, middle and final. Several “new” technologies made their finale this year; a graduation year. EJB 3, Java EE 5 etc. were all more or less announced two years ago. Even the examples were in some cases identical to then: mature and perhaps a bit boring. However, EJB3 will play a role in many projects so “mature” is a good sign.
There were also some surprises and rejuvenation, mostly on the open source side even though Sun managed to squeeze in some surprises.
What happened in the Java SE and EE area? Let us check out some trends and
see what we can make of them.
AOP – still stillborn?
Sun has had a very cautious approach to aspect oriented programming. Two years ago on JavaOne, a large, attentive audience tried to understand what Sun had to say on the subject. The answer from the panel on aspects was like something taken from an old police station series on TV:
– Let’s be careful out there!
Well, the “fireside chat” this year with Sun aluminaries and, of course, James Gosling proved to be more of the same.
The EJB 3 gang also had something similar to say during the conference – along the lines of: “why aspects, when interceptors will do the job”. Interceptors could be described as poor man’s aspects using interfaces and proxies to catch calls to methods. Those of you with good memory banks will recall the Spring folks doing the same rhetorical twist a couple of years ago. This was of course before they saw the light and got the AspectJ guy on their payroll. Smart move. My guess is that we will hear Sun speaking more on using aspects instead of interceptors some two years from now. In the mean time, Spring will lead the way on aspects and real life programming.
Scripting
In Java 6 there will be JVM support for hooking in your choice of scripting language through the standard Java Scripting API. The contestants are already many and include such names as JavaScript, Ruby, Groove, BeanShell and a bunch you probably haven’t heard of. The driving force behind this is twofold; first the amount of glue code needed in Java. It is sometimes just too much code for simple stuff or should I say stuff that should be simple. Secondly, the competition in the language area is heating up. Ruby on Rails is a good example of powerful and fast programming for setting up a website. Their 15-minute video does compete with successful TV ads. You know the ones that make you buy something just because it is such a good deal.
My forecast is that we will see a scripting case where the language and solution just makes sense. Which one? Who knows. Unfortunately we might see a lot of bad examples before the right one comes along.
Java 7 – Dolphin
The Mustang (Java 6) might not be on the loose just yet, but I had to check out the next mammal in the Java sequel – Dolphin. Java 7 was apparent in several sessions, but the common denominator was the vagueness. The speakers used phrases like “thinking about”, “might” etc. Still it was interesting and some of the features are needed.
XML in Java
For instance, what about supporting XML in Java more directly where the XML would be a data type?
Current way
String name = “Björn”;
XML xml =
<person>
<name>{ name }</name>
<age>{ 25 }</age>
</person>;
Alternatively the XML could be expressed as, less verbose:
Possible new way
XML xml = #person
#name { name }
#age { 25 };
Less verbose but will it catch on? I find XML so mind numbing that I am ready to try just about anything.
Super Packages
In large projects the notion of packages does not scale. How can we use a library of classes without exposing internal classes best left in the dark? There are several aspects to this problem, from distribution format to lifecycle. JSR 294 addresses the modularity issue even if it includes a certain NIH factor (Not Invented Here). OSGi, for example, already has a similar mechanism. But for now let us just examine how we can handle classes and their visibility, i.e. “super packages”.
Here’s a code snippet on what a definition for a super package would contain.
super package com.sun.myModule {
// Classes visible outside of this super module.
export com.sun.myModule.myStuff.*;
export com.sun.myModule.yourStuff.Interface;
// Not visible outside
com.sun.myModule.myStuff;
com.sun.myModule.yourStuff;
com.sun.SomeOtherModule.theirStuff;
org.someOpenSource.someCoolStuff;
}
As you can see super packages is essentially a package of packages. This way we can only expose classes on a need to know basis. Solving this with current Java syntax is tricky. Some even resort to removing any JavaDoc on the “internal” classes to obscure their usage.
Java Module System
The next big thing is aimed at the JAR file format that, let’s face it, doesn’t scale and has poor dependency enforcement especially when it comes to versioning. What is needed is a system for resolving references between “Java modules” where each module has meta-data about its version and related resources. This is exactly what JSR 277 defines and yes, it sounds very much like shared assemblies in .NET. However, combining super packages with Java modules forms a powerful way of distributing, versioning and managing components. I like.
These three examples on what we might see in the next-next version of Java are likely to change. Nevertheless I found them interesting.
Ajax, Ajax …oh and Ajax
If there ever was a message being touted on the rooftops of Moscone Center in San Francisco, it is Ajax. The intro sessions were packed, standing room only even on the repeat sessions. Ajax is simple at its lowest level – some JavaScript to query the backend and voilà, you’re done. At the face of it, this is deceptively easy. However, once you have done that simple first try, you quickly get into more questions. Where should we put retrieved data on the client? How do we handle lots of Ajax calls?
Will someone mesh up my data?
Performed correctly though, you do get neater web clients and that is actually an attractive notion. The flip side of this, though, is all the hype. Everything from the Colgate inspired salesmen – yes, they were there with their surreal suntan – to the former Sun execs doing the IPO dance. “Next episode: Will they get cash in before the expiry date?”
Ranting aside, Ajax is here and we all better start to learn it because it does matter. And it does put an amicable face on your web site.
Far out Java container
Two years ago the chosen Java compatible container was …a cool BMW. This year it was an autonomous dune buggy named Tommy with software all in Java. It was entered in a challenge to cross a patch of the American desert – without a driver. It looks a bit like Flash Gordon with four tires instead of rockets, built in somebody’s garage. I must say Tommy spurred my interest more than the BMW, but then again you would not look too cool driving it.
Sun to ground control…
NetBeans
It was quite evident that Sun has a new version of NetBeans out and that it does support the latest Java EE version. And, yes, it does look good. And the price tag is quite right – zero. I just wish that it wasn’t being plugged at most every Sun keynote etc. The audience did get the message and we will check it out. Boy, that IDE market is tough!
Java 6
“Java 6 is here” was one part of the message and “compatibility matters” was the other. Sun CEO Jonathan Schwarz has been going the open source route a lot and many applications are being made OS. Even Java itself could be made open some day. The “When” is still open though. Personally, this isn’t such a big deal for me. Sun has been, for the most part, good at stewarding Java. They have also managed to keep the code running, mostly, between versions. Opening it could be a problem, but also very interesting. Making compatibility a part of the arguments makes sense in such a scenario. Let us hope it stays just that – compatible.
“We want your help”
Making your software open source does change your way of thinking. Sun has promoted a lot of its stuff into the OS arena. Good, I say! It is only logical that participation, from you and me, is seen as a great opportunity. Many of the applications going open, Project Glassfish etc, often ended their sessions with a “we need you”. Maybe Sun’s bad economy has a role in this? To me it doesn’t matter. I like it and I am eagerly waiting to see what the future might bring.
Summing up
JavaOne is a lot more than you can cram into an article such as this, but let us not be stopped by that when summing up. EJB 3 has come of age. This was their prom night and things were basically just as they said they would be two years ago. Keep an eye on it. It will play a role in many projects. Spring will deliver aspect oriented programming, not Sun, and it will go from hot to “fun and here”.
Ajax is everywhere and you will use it. You might as well pick up a good book on this subject and start hacking.
Java 6 will deliver lots of goodies. Will we get to use it? Or is your project stuck in Java JDK 1.4.2 unable to upgrade? Let us hope not. Check out scripting! It will change with Java 6. Who can tell which language will affect it big time? Someone will. Check out your local Javaforum to see if you can predict the winner.
Keep coding and may your code be with you.
Originally published in JayView.
Tumblelight 