Top Personal Insights of JavaOne?
Instead, let's record a few things that haven't been recorded elsewhere yet, on the things that touched you or worried you or stood out at you while you were walking around the JavaOne Pavillion, for example. Inevitably, these will be illustrative of your own personal preferences and proclivities, but that's kind of the point. This way we can see a lot of insights in one place, from a cross section of communities represented at JavaOne. Here we're looking for the unique underbelly of the JavaOne experience, if you will. For starters, here's mine:
- OSGi is everywhere. Really. Everywhere. The biggest recent signs of this are, of course, Sun's GlassFish now being there too and the SpringSource Application Platform going a whole step further, exposing it to those who use it. In fact, I'd not need to think long to nominate SpringSource for being the most innovative group out there. Their message "forget those WAR deployment units, just use OSGi bundles instead", is both risky and just plain cool. That combination equals "innovative", in my book at least. However, now that GlassFish is on OSGi, while simultaneously supporting other modular systems, when will other Sun products move in the same direction? Maybe the question isn't so much "when", but "how": there could be several different ways in which other products could support it (tooling for generating OSGi bundles might be a simple example). Since the promise of OSGi is, among other things, extendability, one question to ask is: if NetBeans IDE does not (at least) produce OSGi bundles, what IDE will need to be used to extend GlassFish?
- There is a need for IDEs to be able to share common code in better ways. I attended a BOF where two developers bravely demonstrated how they implemented a single tool in each of the major IDEs. The tool they created was a PDF viewer. They showed how they created their plugin (i.e., three plugins, one for IntelliJ, one for NetBeans IDE, one for Eclipse) and, in the process, showed the major differences between the development process for doing so for each IDE. They touched on some API-level stuff as well, but mostly focused on the different approaches taken by each of the IDEs, for if the audience wanted to do something similar. One would think that OSGi should make it possible for the business layer and the external libraries to be shared amongst all three IDEs. Of course, the integration layer would be a different story altogether, since each IDE comes with its own APIs. (And Eclipse uses SWT, while IntelliJ and NetBeans IDE are on Swing.) However, a LOT of time (in creation, debugging, and maintenance) might be saved if the common elements could simply be reused, instead of requiring the developer to adhere to a different deployment format for each IDE. I doubt, however, that this usecase is something that any IDE wants to optimize for, especially given that each has so many other pressing issues to contend with. Still, adopting OSGi as a common basis might provide a small step in the right direction.
- There is a better understanding of the value of desktop Java frameworks than ever before. At the very least, these were more present at JavaOne than ever before. On Thursday, I did a very high level technical session on this with Kai Toedter from Siemens, as well as a BOF later in the evening, Fabrizio Giudici presented his blueMarine Photo Workflow application on the NetBeans Platform, while two presenters from Boeing talked about their NetBeans Platform based Boeing Shared Platform. After some of these, I met developers who use the NetBeans Platform in contexts I had never heard of before. Did you know NASA is using the NetBeans Platform? Have you heard of the "open source justice suite" that's apparently being developed at the University of Southern Mississippi? In Australia the NetBeans Platform's Visual Library API is being used as a cornerstone of a teaching platform that will be rolled out across the country. I'm sure there are many such surprising stories around the Eclipse RCP too. This makes me wonder: whether JSR-296 succeeds or not, the already-existing frameworks provide sufficient solid grounding for desktop applications, apparent from their continually rising adoption.
- Snake charmers are wonderful. "Snake charmers" is the term that semantic web guru Henry Story told me he uses to refer to those marketing guys in the pavillion who try to sell you their product while not knowing much about it in the first place, while trying to voodoo you into showing an interest anyway. They entice you with their (as it turns out) malfunctioning gift (in my case, a USB Skype phone device thingy), in exchange for which you are meant to sit and listen to their blather. (On the up side, even though their Skype phone thingy doesn't work, you still have a brand new USB cable.) When will companies learn that most people walking round the pavillion are technical people, i.e., people who don't accept BS? However, the complete meaninglessness of some of the sales talks sometimes approached the level of "art" (at least, very close to "White Painting [Three Panel]", by Robert Rauschenberg, which I saw in the Museum of Modern Art down the road from the Moscone Center the day before JavaOne started). In any case, I think those snake charmers are priceless. The confidence of their demeanour, combined with the bemusement of the random techie they happened to be talking to, was wonderful to behold.
That's it. Those were some of mine. How about yours?