The CommunityOne conference this year was on Monday, May 5, 2008, the day before JavaOne "proper". It's easy to think of CommunityOne as a "pre-JavaOne", or "JavaOne, Day 0" because, like JavaOne, it's sponsored by Sun Microsystems, it's at the same venue, and it is logistically managed as sort-of an extension of JavaOne (your JavaOne conference pass is used, but with an optional one-day add-on for CommunityOne). So why the distinct conference name and date? Aren't CommunityOne and JavaOne the same kind of conference sponsored by the same company?
Well, yes and no. They're "the same, but different". Both are developer conferences, but CommunityOne is geared toward allowing us to meet the actual open-source developers who are working on the latest upcoming releases of our favorite open-source software projects. CommunityOne's tagline is "Come in and learn a while" -- the sessions are presented by experts representing a wide range of open source projects; from chip design to operating systems to web servers and databases to scripting languages and tools. Not that JavaOne excludes coverage of open-source projects, but CommunityOne has a distinctly different look and feel. The sessions often replace slickness with in-depth hard-core "techie"ness -- in some cases, you're essentially getting a detailed project update from the actual person writing the code to implement the new feature you're waiting for.
Sample session 1: Building Ajax Applications
This session involved three developers taking turns showing us as many cool, rapid-fire demos as they could fit into the alloted time. They demonstrated how the latest IDEs, with the help of integrated Ajax libraries, can be used to quickly assemble useful Ajax applications. The IDE used in the presentation was NetBeans IDE 6.1 with several Ajax libraries installed, including the following:
- several others.
After the presentation, I chatted with other attendees, one of which told me, "if you think that was cool, you should see IntelliJ". That brings up another aspect of these conferences: your fellow attendees. So much great information and opinion (and debate) can be obtained from fellow attendees. You may be attending one session (which you felt was very cool), which then leads unexpectedly to discovering a whole new range of similar tools, frameworks, architectures, scripting languages, etc., you may not origianlly have been aware of.
Sample session 2: Transparent OSGi Integration with JBoss Microcontainer
I expected this session to be an introduction to some new feature of JBoss, since I've never heard of OSGi before. Instead, it turned out to be an extremely detailed, technical explanation of what exactly was being done to implement the new JBoss 5 classloader. I was a bit puzzled... Why so detailed? Why all this talk of the classloader?
It turns out, the reason for the level of detail is that the presenter, Ales Justin is the lead developer for this new feature of the JBoss Microcontainer in AS 5. Stated another way, he's the main guy actually writing the code to implement OSGi into JBoss 5. After some online research I figured out that the reason for all the talk about the classloader is because OSGi is all about runtime discovery of applicaiton resources (see next paragraph). Man, talk about getting close to the technology -- this is even better than reading an email post or a blog on the project. You can discuss, face-to-face with the lead developer, in great detail, how the new classloader is being implemented and why it needed to be implemented that way. You may even offer him a suggestion on how to solve a specific problem, or point out potential issues with the implementation being used before the feature is even completed.
What is OSGi?
OSGi stands for "Open Service Gateway Initiative". The OSGi Alliance was founded in 1999 by a number of vendors including Ericsson, IBM, Oracle and Sun Microsystems; the alliance manages and develops the OSGi specification.
What got my attention was on online news article in Feb, 2008, that IBM, BEA and JBoss adopting OSGi. According the article, that this specification is a component model that defines component packaging, life-cycle management and service registration for Java environments. Applications or components (coming in the form of bundles for deployment) can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot. This seems like a powerful capability for any high-uptime scenario, e.g., in a grid of servers.
OSGi has been used in large desktop applications, most notably the Eclipse IDE, and a recently formed OSGi Enterprise Expert Group is looking to extend the OSGi specification to support the needs of Enterprise Java vendors and developers.
This explains why so many GlassFish V3 and JBoss 5 presentations mention OSGi as an imortant new feature. I feel this is something worth looking into, at least, just to understand what it can do for you to make your deployments easier on the enterprise server, especially when deploying to multiple vendors' Java EE servers.
For me, the unexpected discovery is a good example of why I value conferences -- you arrive expecting to get new information on your favorite topics and leave with information in areas you didn't expect, and new favorite topics. All of this comes from chatting with fellow attendees, or by accidentally attending a presentation because you misunderstood what it was supposed to be about (as I did). It really gives you a leg up on new technolgy. You can't get that as much through reading articles. You can only get a feel for what's going on inthe industry by attending conferences and talking to fellow developers, especially those who know more than you and who are willing to share their opinions with you -- something in ample supply at a conference like CommunityOne.
Additionally (and more to the point of this story), CommunityOne gives developers a chance to talk directly to those who understand the technology best, face-to-face, without the potential risk of information being "lost in translation" by having to read about it third-person. It also adds another dimension to the open-source model by providing "open" access to the project developers, adding the unique feel of open participation to the development process as opposed to simply being told by a corporate representative "this is what we're doing -- we really hope you like it, but there's not a whole lot we can do about it in the short term if you don't". As was stated, CommunityOne has a whole different feel from JavaOne. It's for those who seek a more intimate connection with their favorite open-source projects.