Over a million developers have joined DZone.

Devoxx Day 2: University Day 2

DZone's Guide to

Devoxx Day 2: University Day 2

· Java Zone ·
Free Resource

Get the Edge with a Professional Java IDE. 30-day free trial.

Day 1 of Devoxx 2009 was inevitably followed by Day 2, today. Mostly, I spent the day preparing for my "Tools in Action" talk with Anton Epple, about his project (available on Kenai) that makes the Lookup class (which is, basically, a beefed up JDK 6 ServiceLoader class) available as an OSGI service registry. Everything worked out well in the end and we were both happy when our talk was over. And now actual enjoyment of Devoxx can begin!

Some of the sessions I attended today, together with some interesting things discovered:

  • The SOA talk by Nicolai Josuttis was pretty good for being so clear. A very practical story, laying out all the basic concepts of what SOA is. He focused strongly on loose coupling as being one of the principles of SOA, which he defined as: "An architectural paradigm for distributed processes over heterogeneous systems that may be under control of different owners". The other two key concepts he discussed were 'services' and 'high interoperability'. The only question I had at some point was: "Shouldn't we already know all these things already?" I'm also not necessarily convinced that SOA isn't dead. Quotable quote from this session: "Any solution to a problem is a new problem."

    By the way, the small image in the top right corner of this article is of a slide from the above presentation. It shows a meteor (representing the economy) hitting a dinosaur (representing SOA), under the heading: "Economy killed the SOAsaurus?" Funny.

  • An interesting thing I learned at the Vaadin booth is that the visual designer they're integrating into Eclipse is itself a Vaadin application. The application is served into Eclipse by an embedded Jetty server and displayed in the Eclipse embedded browser. Below you see an image of an early version of the visual designer, running as a standalone application, (thanks Henri Sara in Finland for helping me get the standalone application running, via Skype conversations with him in Finland today!).

    I'm planning to experiment with embedding the visual designer into NetBeans IDE, which would be a good thing to try since the Vaadin team wants to separate the IDE-specific code from the generic code that can be shared by all IDEs, hence making sure this also works in NetBeans IDE will be a good test case for them.

    Vaadin deserves to be supported, if for no other reason than that the Vaadin team has the best swag at any (and every) conference: a free book describing in detail how Vaadin works (via GWT), including a complete reference guide to all the classes making up the Vaadin framework. Now that's great work!

  • In the evening, I attended 3 BOFs: on Java EE 6, Spring RCP, and the OSGi Felix container. The first was a general chat between a large group of speakers, during which time I ended up with a new understanding of "profiles" in Java EE 6. Basically, my new insight is that the concept of portability is enhanced by means of profiles. Now, you can align your development platform with your deployment platform by creating a deployment bundle that complies to a specific profile (e.g., web profile), which you can then deploy to a server that complies to that same profile. Before, you never knew what was in a WAR file and how it related to the server it was deployed to. Now, since you're targeting a specific profile, e.g., the web profile, you'll know what's in it. And now servers, such as Tomcat, need a web profile implementation, which is what Caucho is already doing for Resin.

    Another new insight for me was the realization that the web profile is basically an example profile. The idea is that anyone can create a JSR for their own profile, using the web profile as a template, which can consist of a combination of technologies complying with the Java EE 6 spec.

  • Then the Spring RCP BOF. It was great to be at a BOF on Spring RCP, since I've supported this project in various ways (e.g., a NetBeans plugin for Spring RCP development, an interview with the project lead, and a 5-part tutorial starting here). I especially like the FormBuilder (where a Boolean is automatically rendered as a Swing checkbox, for example, without you needing to specify anything at all). Their docking framework integration is also unbeatable, while the ease of integration with a Srping backend must be really cool too. A Maven archetype for Spring RCP exists, which was used in the demo to code in IntelliJ (which seems to have very nice Spring integration, including refactoring between Java and Spring config files).

    The summary of what Spring RCP is: "Swing + Spring". Which is good news if you like Spring (and, hence, you also like XML, since Spring 2.5 annotations don't cover all scenarios yet, unfortunately). Nevertheless, it's really cool for what it is, introducing many smaller frameworks helpful in standardizing Swing development within an organization. I really think SpringSource should start taking Spring RCP seriously. Come on, SpringSource: "If you build it they (i.e., your customers) will come!"

  • The OSGi session on Felix was extremely interesting. Two things very worth exploring: Apache ACE and Apache Karaf. You can use Apache ACE to manage deployment to clients, while deployment can be done remotely (not only for OSGi). With Karaf, an OSGi container on top of other OSGi containers, you have access to high-level services, such as hot deployment. Something else is that you can group bundles and their configurations, described in an XML feature file, the URL of which can be used to install the registered bundles.

Finally, of course, throughout the day, I met people I hadn't seen in months/years, etc, which is one of the cool things about conferences of this kind!


Get the Java IDE that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA. Download the free trial.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}