Sunday, December 14, 2008

My take-aways from Devoxx 2008

JavaFX is probably not as dead as I thought

After witnessing official announcement from Sun about "JavaFX coming" at JavaOne in 2007, more than year and a half passed and I was anxious that the whole idea is dead.
To my astonishment, Sun seems to have changed its strategy with JavaFX. Now it's not to be just a simple Java-based alternative to Flash/Flex rich internet client applications (as for many months have been stated on JavaFX homesite), but something more: a new rich client for Desktop and Mobile. As I am recently quite heavily involved in rich client development with Java (mostly Swing), this is for me a very important shift.
Swing is often quite difficult to tame. Its controls look quite outdated. Definitely it's visible that the library is about 10 years old and is burdened by a lot of garbage.
Firstly JavaFX brings a lot of visually appealing effects which applied to your UI will make it more modern, but also more usable for your customers (like iPhone does, which is BTW referred to by Sun folks very often).
Secondly JavaFx guys promise that there will be a new library of UI controls available for JavaFX. This library is to be built on top of all the knowledge gathered by last 10 years from Swing developers (and not only) and should avoid most of its disadvantages while providing seriously refurbished look & feel. And this library will be accessible naturally also for Java developers. And it's said that ultimately it should become and new Swing 2.0 or rather an alternative to it.
Great! I am keeping my finger crossed.
Seeing how much energy Sun put into promoting JavaFX at Devoxx (which includes several very interesting presentations), a lot of interest of Devoxx attendess (see the table below about the plans for using JavaFX) and even strong belief in JavaFX from Java Posse guys, I tend to believe that developers forgave Sun its slip in delivering JavaFX and really count on this language.

Java is no longer about just Java, but dozens of languages running on JVM


I was on a few great session (e.g. by Brian Goetz or a folk from Azul Systems) about JVM internals and garbage collection. It's clear how much effort is now put into making from JVM a friendly platform to various languages (also dynamic).

Java SE 7 is LATE

Unfortunately we will probably wait about 2 years more for next major Java release.
And unfortunately there will be there apparently no such wanted language features like properties or closures.
Sun seems to play a role of a perfectionist here. They are obsessed with maintaining backward-compatibility and thus want to avoid putting into language some feature which then would be impossible to remove or change. So they want to analyze and polish everything and then add to the language only ultimately prepared feature. Unfortunately it's very difficult. And unfortunately both closures and properties are not in the shape of having ultimately prepared proposals. And probably they never will, as it's typically impossible to predict all the aspects of a language feature. I bet nobody in 1996 would dream what possibilities Java would offer to developers 10 years later - practically with the same language or JVM constructs which were available for a long time (e.g. web or application frameworks making heavy use of reflections, proxies, aspects, DI containers, dynamic languages). My opinion is: let's not wait forever with a new language feature. Let's add it, try it out for a few years and then only see how to improve it or not. Which leads us to the next conclusion:

Developers are fed up with Java backward compatibility

Java 1.6 is practically 100% compatible with Java 1.0. Which is not used by anybody.
The survey made on the whiteboards at Devoxx make me believe that about 95% of Java programs now use version 1.5 or 1.6, maybe maximum 4-5% uses Java 1.4 and only per mills still depend on the older versions (which anyway are not longer supported by Sun). Backward compatibility is one of the major problems with Java and the reason it gets bloated while retaining a lot of garbage: unused APIs, libraries and bad design (to name only a few: Cloneable, finally, old collection framework). It's time to give it up. And the applause for stopping being too obsessed on backward compatibility at live Java Posse session convinces that I am not the only one who thinks so.
If Java is paralysed and does not evolve, it will soon be challenged by other modern languages (like Scala for statically typed languages or Groovy or JRuby for dynamically typed languages) and it may just lose the market. Although a lot of effort is put on JVM itself which will not be directly affected by such possible shift, even more knowledge and effort invested in Java language itself (just take billions of lines of Java code of existing systems, hundreds of huge and powerful Java IDEs and tools) would be more or less wasted. I think it would be very bad. Sun, please don't let Java die now. It's too early. With proper gardening this language may be successful for at least another decade.

Agile development gets lots of attention

Although Devoxx is a technical conference for computer geeks (or nerds ;)), there were (contrary to JavaOne) many talks related to software development process. There was even a separate track called "Methodology".
AFAIK all talks in this category were more or less connected with agile development. Anything else nowadays (say a session about waterfall process) makes people laugh. I heard that even Ivar Jacobson (the father of bureaucracy in software process one could say) himself seems to change his mind (very good!) and now tries to preach on common sense approach to software engineering (and I heard that his talk was really good).
A little bit surprisingly, all these talks gathered a lot of audience (including our talk on code review). So geeks seemingly like to have a broader view on the computer science. That's good. Unfortunately some sessions were just disappointing (e.g. I did not like the way Dave Nicolette presented his observations. Such talks just looked like unprepared and many people got quickly bored).
I was carefully observing what people say about their agile practices. Although everybody seems to embrace "agile", relatively few people admit to practice pair programming. Also still few people do code reviews or collectively own the source code. In several presentations I saw significant flaws with applied unit testing strategy (which was not "unit" as a matter of fact). So, although the word is spread, there is still much work to do in order to really convert to agile.

Atlassian - respect of the community

Although I am working on software projects for Atlassian and thus I am somewhat biased, I could not resist to write about it.
Devoxx was the place where I realized how respected Atlassian is in Java community.

At almost every session I saw lots of people accessing JIRA or Confluence from their laptops or receiving their mails with familiar looking [JIRA] header.
Many speakers (unaffiliated) mentioned Atlassian products during their talks as example of awesome and productive tools.
After our talks revealing that we work on Atlassian tools, people were coming to chat and congratulate us.
Finally, during Thursday's live Java Posse session at Devoxx, Atlassian got a real applause from hundreds of geeks.
And it did not happen to Sun. It did not happen to companies like JBoss, Oracle or even Jetbrains or SpringSource.
People really seem to admire Atlassian. It it not due to free beer. Other companies also served it :)
It is not due to bullshit marketing, but rather because of being just cool and awesome. A huge thing. Very difficult to achieve.
I must admit I felt good then.

OSGi - a new sexy trend

OSGi seems to be everywhere or at least affect all bigger platforms. Spring now has it. Java 7 is more or less going in the same direction.
We will see what it will really bring to Java community. For time being it bears two connotation for me:
- the way to deal with jar hell (do you remember infamous DLL hell on Windows?)
- the way to decompose your system into independent and reusable subsystems (or components)

Spring gets heavier and heavier while Java EE with EJB strikes back

The history likes to loop. In the past the biggest advantage of Spring vs. traditional EJB-based stacks was simplicity (or lightweightness) and testability.
Now as Springs gets bigger and bigger (fortunately still provided in independent packages) and EJB 3.x builds on lessons taught by Spring, we may realize that the roles actually are changing.
EJB is claimed to be simple and lightweight, while Spring ... yeah, it depends on how far you go.
It's like in XML say 8 years ago. We started from simple XML, then people start abusing it with things like transformations (de facto programming languages), complicated schemas, descriptors, poms (I got you Maven!), xml protocols, firewalls, security, WS-* standards. Several years had to pass, in order to people could realize it and now back simplicity and conscience takes the lead. Everybody seems to hate now XML descriptors or XML configuration files (including Spring configuration). Everybody now loves simple (?) and terse annotations. I wonder when we witness just another shift. Probably when in a Java class definition you will have more lines with annotations that with the code itself - the case we are getting quite close with say EJB 3.1 :). But this is how human civilization works.
The lesson for me: it's important to know when to start, but it's equally as important to know when to stop.
BTW: everybody now uses Spring now or claims so.

Quickies competing with hunger

I presented with Marek a quickie on Atlassian IDE Connector. I think that with current Devoxx schedule and organization, quickies (at least the first slot every day) are unfortunately mistake.
Just imagine all these people who after c.a. 3 hours of listening to various sessions hurry downstairs to line up in a long queue (often for more than quarter) for lunch.
Then your quickie must compete with hunger. And your quickie will always lose. The outcome: even very intersting quickies presented in the first slot (at the very beginning of lunch break) gathered only a few dozens of participantes. The second slot was typically much better. So maybe both slots should be postponed by ca. 10 minutes next year (to have real 20 minutes break to let people grap their food and come back to the room if they are interested).

Conlusion

I think that generally Devoxx 2008 was a good conference (of course - we were talking there ;)).
There were wonderful sessions (as usually from stars like Josh Bloch or Brian Goetz or unexpectedly coming from less famous people like Simon Ritter - the session about self-made multitouch screen and Java and JavaFX programs around it) and very good sessions (e.g. from Richard Bair on JavaFX or two blokes - Jonas Jacobi and John Fallows from Kaazing on web sockets).

Unfortunately there were also quite poor talks due to either poor speakers (it really matters who and how presents), poor topics or just too simple content. Comparing to JavaOne 2007, I would say that sessions at Devoxx on average were less demanding - seemed to be targeted often for beginners. Maybe I got something wrong, but I had expected Devoxx to be a conference for intermediate to advanced developers.
The biggest technical problem of the conference itself was the lack of microphones at Q&A sessions. Something really cheap and simple to amend next year I hope.
Considering that Devoxx is really cheep (we can forgive then things like crappy food or nothing to eat on Friday) and anyway everyone can learn a lot there, I conclude that this is the conference I would like to go one more time next year.

So see you hopefully in 2009.

10 comments:

  1. Cool post - thanks for the debriefing.

    I have one comment though and I'd like to disagree with you regarding Java backward compatibility. You said that 95% of people use Java 5 or 6. Maybe, but they use JDK 6 or 7 and still are using old Java constructs like Vector or Hashtable. If you remove such things you will destroy "backward" compatibility even with programs written entirely for Java 6 platform.
    Note that everything that is in Java 6 (i.e. constructs from Java 1.1, 1.2, 1.3, 1.4, 4 and 6) belongs to Java 6 platform. If you want to remove something that was added in Java 1.1 you're still breaking the backward compatibility with the newest Java applications.

    It's a tricky subject.

    ReplyDelete
  2. For several years I haven't seen or maintained any new Java application or library which would use Vector, Hashtable or stuff like that which is for many years considered to be "deprecated".
    So yes, if your Java is 10 years old and has not evolved meanwhile getting rid of old stuff, you have problem although you claim you use JDK 1.6 (actually you run on JDK 1.6).
    I still claim that nowadays it's relatively small problem and those libraries/systems which are really alive would quite easily run on JDK without 1.0 or 1.1 garbage.

    Still, modularization being added to Java in 1.7 is something which should make it easier.

    ReplyDelete
  3. Wojtek I clearly understand what you're saying and I would gladly support you (I haven't been using these classes since Java 1.3) but again this is an ideal World. It's not an argument that you haven't seen someone using these classes for a long time. You are just one of millions of Java developers and you've developed several out of millions of software projects. Believe me I've seen some serious crap in production that is said to be Java 5 compliant while it uses 1.1 stuff. Some of the software written like this probably manages your money in your bank :)

    But you're also right that it has to be done somehow - maybe in a brutal way (like Microsoft does), maybe somehow more politely. I don't know.

    ReplyDelete
  4. That's the point - using the "modularization" Sun prepares possibility to cut off bugwards compatibility for those who want, still providing legacy APIs for the rest.

    ReplyDelete
  5. "To my astonishment, Sun seems to have changed its strategy with JavaFX. Now it's not to be just a simple Java-based alternative to Flash/Flex rich internet client applications (as for many months have been stated on JavaFX homesite), but something more: a new rich client for Desktop and Mobile."

    This is not a changed strategy: it was like that from the beginning, a competitor to Flex/Air, I don't know why people didn't understand it immediately and started spreading a lot of misinformed things around the blogsphere...

    ReplyDelete
  6. @Fabrizio:

    Take a look at http://javafx.com/:
    "Rich Internet Experiences for all screens of your life"

    or http://javafx.com/about/.
    The headline is "Internet". No "desktop" word is mentioned there.
    I was there at JavaOne 2007 watching the first public announcement of JavaFX and believe me the message I (and not only I) got was: it's for web applications. Nobody was talking at that time about desktop apps and more specifically about a new UI library for Java desktop developers.
    Also at Devoxx08 many people look surprised by apparent shift to desktops.

    ReplyDelete
  7. Internet != webpages
    The internet is a lot bigger than just the web and webbased applications. JavaFX is a new platform meant for building Rich Internet Applications
    Since pretty much all applications have something to do with the Internet these days, whether or not they are built using HTML or are running in a browser, this means that JavaFX is really a new platform meant for Rich Applications.

    JavaFX lets you build apps that run in the webbrowser, on the desktop, and on mobile devices. In all cases the applications can access internet resources, be deployed through the internet, and have a rich interface. In the case of applets you can even drag the program out of the webbrowser, turning a browser based app *into* a desktop app.

    ReplyDelete
  8. This comment has been removed by a blog administrator.

    ReplyDelete
  9. FYI - 'Pokerguys' decided to spam us. Not good. Comment deleted

    ReplyDelete
  10. Hey, they decided we have enough audience we are spam worthy.
    Sweeet.

    ReplyDelete