Posts Tagged ‘JavaOne’

JavaOne 2006 – almost in hindsight

October 1, 2006

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.


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 =
      <name>{ name }</name>
      <age>{ 25 }</age>

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

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…


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.

Personligt: JavaOne 2004

August 4, 2004

Från varje stor och viktig konferens så måste det finnas en objektiv och heltäckande rapport – det här är inte den artikeln. Istället får ni mina personliga iakttagelser kryddat med diverse spekulationer och tyckanden.

Med denna varning ur vägen och utan eftertanke, låt oss dyka in i Javavärldens största konferens för programmerare – JavaOne 2004.


En av de viktigaste drivkrafterna på sistone hos Sun är EoD, Ease of Development. Denna idé om att det måste vara lättare att jobba med Java har fått starkt fotfäste. Tack Microsoft! Tack för Dotnet och för att ni tvingade Sun att konkurrera på nya villkor.
Ta till exempel Sun Java Studio Creator (SJSC) 1.0 som presenterades under dagarna. Det är en vanlig utvecklingsmiljö förklädd till Visual Basic. Detta låter kanske inte så häftigt, men faktum är att både gränssnitt och den genererade lösningen ser bra ut – till och med om man tar hänsyn till demons glittriga yta. Listan med förkortningar, JSP, JSTL, JSF, etcetera är precis så vanlig Java som man kunde hoppas på. Sun kan mycket väl lyckas med att attrahera f.d. VB-programmerare, och kanske även gamla härdade javaiter, som vill köra J2EE med krockkudde.

Tänk er att kunna skapa en prototyp i SJSC för att sedan rycka ut olika lager och ersätta det med något mer industriellt. Jag håller tummarna för att Sun gör det rätta. Lite rita-dra-ochtesta-kod skulle inte skada för en gångs skull.

Mer EoD – EJB 3

Men det finns andra mer långtgående effekter av EoD. Ta metadata, dvs. att man kan berätta saker om koden. Man skulle enkelt kunna ange att en metod är ”remote” och vips så genereras de filer som behövs för att skapa en web service. Bästa exemplet är nog EJB 3.0 som hade en del riktigt enkla powerpoint-slajds – de var helt enkelt tomma. Det lilla som fanns kvar var uttryckt som metadata i koden. Applåderna lät inte vänta på sig.

Jag får erkänna att jag aldrig tyckt om EJB och framförallt inte CMP. När jag talat om bristerna har jag ibland känt mig ganska gnällig. Expertgruppen för EJB har gjort en rejäl sväng och skapat en bra mycket mer elegant lösning. Tänk er enkla Java-bönor med metadata (typ Hibernate med XDoclet) så får ni en rätt bra bild. En så pass ny kurs innebär att gamla sanningar utsätts för hårda prövningar. Vad sägs om följande citat från konferensen ”You shouldn’t have to be a rocket scientist to be an EJB-developer” eller ”the Data Transfer Object [DTO] anti pattern”? Det sista innebär inte mindre än en dogms död för vad god EJB-programmering har inneburit.

Något oväntat kanske, så hamnade de nu i samma säng som JDO – Java Data Objects – en av Suns andra persistenslösningar. Diskussionerna både bakom och framför ridån var intensiv under dagarna. Resultatet har tack och lov inte väntat på sig. De två expertgrupperna har precis kommit ut med ett öppet brev där man lovar att arbeta ut en gemensam lösning. Det lär ta tid, men det är definitivt ett steg i rätt riktning. Jag får erkänna att jag antagligen inte kan gnälla länge till.

Det finns långt fler exempel och gemensamt för dessa nyheter är EoD. Vi kommer att få se mer av denna katalysator.

SOA, nu med XL hajpfaktor

Det verkar finnas en naturlag som alla konferenser måste följa – minst ett ämne måste trissas upp. Flosklerna ska flöda och en exakt förklaring saknas. I år vågar jag mig på att utnämna SOA till huvudkandidat. Service Oriented Architecture var på många föreläsares läppar och tanken på en sorts gemensam arkitektur är lockande. Jag kunde dock inte förstå exakt vad det är som skiljer SOA från web services, möjligtvis är den senare ett specialfall av SOA. Nåja, gräv ner fötterna i jordmyllan och var beredd på att höra mer om detta begrepp. Det finns många intressanta tankar, men också en hel del floskler som vi hört förr. Det lär ta tid, men chansen är att det kommer på en server nära dig.

Klienter, feta som mobila

Vi har fått leva i flera år med anorektiska klienter (läs: webbläsare med uselt gränssnitt som bara en mamma kan älska;-) men det verkar förändras nu. Det är inte längre självklart att en klient måste vara tillgänglig överallt på bekostnad av användargränssnitt, funktionalitet etc. Under konferensen fanns det flera exempel på varierade klienter – det var allt från att löften om att kunna generera feta klienter ”i nästa version” till skräddarsydda mobila varianter.
Står dina användare fortfarande ut med tunna skal som blinkar och fladdrar? Jag gissar att de närmaste åren kommer fler av oss att rycka fram de gamla böckerna om gui och Swing för att vi glömt vad vi redan kommer ihåg.


PR-avdelningen på Sun har slagit till igen. Förra gången detta hände fick de för sig att använda både 1.2 och 2 som nummer för samma release – den första var JDK och den senare det mer övergripande och luddiga Java 2 Standard Edition. Nu räknar vi upp hela härligheten till Java 5.0 eller var det JDK:n? Och vad var det nu J2SE skulle heta…
Vi tar det igen; 1.5 är det interna numret, 5.0 är det externa. Och tvåan i J2SE blir då det utomjordiska numret?

Far out

Första kandidaten i denna klass är Nasa och deras Rover – Marslandaren. Både den och program runt omkring använder sig av Java. Det var roligt att höra om deras lösning med robotarmar och allt som fanns på deras bilder. När de fick frågan om vilken databas de använt för att spara all bilddata, så spred sig ett förtjust fniss bland åhörarna – MySQL. Man behöver tydligen inte så mycket mer om man bara ska till Mars.

Den andra kandidaten är Groovy som är ett nytt språk från veteraner som James Strachan (Geronimo, jelly, dom4j, maven, Jakarta commons etc.). De hade lagt märke till att mycket kodande går åt till att limma ihop olika komponenter. Varför inte uppfinna ett nytt språk som gör detta och mycket annat lättare? Född var Groovy. Några absolut minimala exempel:

str = ”testing”
// Notera inget semicolon!

c = str[-1]
// c är nu lika med ’g’

s1 = str[3..1]
// s1 är nu lika med ”tse”

// v är nu lika med 2

I listan ”1,2,3” så letar vi efter den första posten som uppfyller villkoret vi skickat med (”it” är en sorts standardparameter). Vi kan alltså skicka med kod som ska exekveras!
Man behöver många fler exempel för att förstå hur häftigt det är, så jag ska inte ens försöka göra det rättvisa här. Groovy fick dock det att klia i mina programmerarfingrar.

Siffror och visioner

När Suns ledning talade var det många siffror. Det var antalet Java X, antalet miljoner dollar, antalet… ja, ni förstår. Allt var förvisso intressant och visionen var också ”Everything and everyone connected to the Internet”. Och jag fick onekligen en känsla att Java är med överallt. Scott McNealy uttryckte det mer subtilt när Sun fick en utmärkelse för sin marknadsledande Java Card och dess dominans:
We prefer ’interesting market share’.

Var fanns då den rena råa visionen, passionen? Mestadels hittade jag den i de olika grupperna, allt från expertgrupper inom Sun till, och kanske framförallt, olika kommuniteter (”communities”). Här fanns de galna idéerna, de lovande framtida teknologierna och de intressanta verktygen. Det gör säkerligen inte våra liv lättare på kort sikt, men jösses vad roligt jag kommer att ha det!

Originally published in JayView.