Geertjan is a DZone Zone Leader and has posted 464 posts at DZone. You can read more from them at their website. View Full User Profile

Top Personal Insights of JavaOne?

05.12.2008
| 4822 views |
  • submit to reddit
Flipping through the pages and pages of notes you may have taken at JavaOne, which ones would you not want to forget? In this case, focus on the personal and the arcane, rather than the official high-level stuff. For example, it's not hard to extrapolate a half baked opinion about JavaFX, or to toe your party line in relation to the scripting language debate (did the "scripting bowl" and similar comparisons really bring us any further, other than that it was interesting to watch?), or to speculate on SpringSource, or Sun, or both. But all that's already been done in various blogs and fora.

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?

AttachmentSize
pavilion_scene1.jpg43.26 KB
Published at DZone with permission of its author, Geertjan Wielenga.

Comments

Ian Skerrett replied on Mon, 2008/05/12 - 4:03pm

Geertjan,

It was fun to meet you in person at the Eclipse party. 

I agree it was surprising and great to see the interest in OSGi.  They year at the Eclipse booth we had a lot more people asking us about OSGi and Equinox.  I just had to respond to this question:

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?

One potential answer is Eclipse.   Glassfish is already running as OSGi bundles inside of Eclipse.

 

Ian 

Toni Epple replied on Tue, 2008/05/13 - 11:49am

Hi Geertjan: there's a resource in the wiki about what is needed to run NetBeans on OSGi. Maybe someone from the community could adopt this project, since sun employees "are not going to stop" us :-)?

James Sugrue replied on Thu, 2008/05/15 - 4:51am

What I got out of JavaONE:

  • OSGi gains momentum in the Java community
  • SpringSource is really taking off
  • If what goes into JavaFX mixes well with the core platform, we've got a bright future

 

Michael Hüttermann replied on Mon, 2008/05/26 - 6:40am

Geertjan,

I do not think that OSGi is the golden hammer for all challenges .. and I do not agree that OSGi is everywhere ..  From a Sun point of view the Glassfish topic is worthy of mention for sure .. but .. especially your IDE/business logic scenario .. why not simply use Java for reusable code?! Concerning OSGi I'm still asking myself what happens with JSR 277? If you talk about languages and different IDEs .. I would more focus on JSR 292 and additionally unify all those proprietary IDE vendor approaches (like Schliemann, GLF, ......).

 

Cheers!

Michael 

Geertjan Wielenga replied on Mon, 2008/05/26 - 7:04am

@Ian: Great to meet you too. Sorry for the delayed response, was hoping more people would respond first. Hope to meet you again somehow!

@Toni: That would be cool. I'm sure there'll be some kind of OSGi interaction at some point.

@ James: I agree.

@Michael: Yes, of course, use Java for reusable code. But how do you share it between different applications, e.g., between Eclipse and NetBeans? You need some kind of distribution format that is understood by both, as well as by IntelliJ. That would seem to be OSGi bundles. If my plugin for NetBeans contains business logic and external libraries that I could use in my IntelliJ or Eclipse plugin, it would be very cool if there was a shared distribution mechanism like that.  

Michael Hüttermann replied on Mon, 2008/05/26 - 7:44am in response to: Geertjan Wielenga

jar ? 

 

[quote=geertjan]

@Michael: Yes, of course, use Java for reusable code. But how do you share it between different applications, e.g., between Eclipse and NetBeans? You need some kind of distribution format that is understood by both, as well as by IntelliJ. That would seem to be OSGi bundles. If my plugin for NetBeans contains business logic and external libraries that I could use in my IntelliJ or Eclipse plugin, it would be very cool if there was a shared distribution mechanism like that.

[/quote]

Geertjan Wielenga replied on Mon, 2008/05/26 - 9:22am

With NetBeans, you need more than a JAR. You need an NBM, which wraps the JAR, plus some metadata. With Eclipse, you also need more than a JAR. You need an OSGi bundle, which wraps the JAR, plus some metadata. With each product, there's something you need to wrap the JAR, plus some vendor-specific metadata. Hence, since OSGi is the most commonly used distribution unit, why not use OSGi in all cases?

Michael Hüttermann replied on Mon, 2008/05/26 - 9:48am in response to: Geertjan Wielenga

maybe we speak about something totally different ;-)

OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs? If I work in a project where developers are using different IDEs .. the most commonly used distribution unit is .. a jar respectively the source code itself. 

[quote=geertjan]With NetBeans, you need more than a JAR. You need an NBM, which wraps the JAR, plus some metadata. With Eclipse, you also need more than a JAR. You need an OSGi bundle, which wraps the JAR, plus some metadata. With each product, there's something you need to wrap the JAR, plus some vendor-specific metadata. Hence, since OSGi is the most commonly used distribution unit, why not use OSGi in all cases?[/quote]

Geertjan Wielenga replied on Mon, 2008/05/26 - 9:56am in response to: Michael Hüttermann

[quote=michaelhuettermann]

OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?

[/quote]

Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too? 

Eric Bresie replied on Wed, 2008/06/04 - 4:13pm

Regarding common IDE API, what about existing JSRs like JSR 198: A Standard Extension API for Integrated Development Environments or JSR 273: Design-Time API for JavaBeansTM JBDT.  These are IDE specific and not application level, but still at least the development similarities might be a useful joining opportunity.

James Ervin replied on Wed, 2008/06/11 - 11:39pm in response to: Geertjan Wielenga

I need to fix my reader's feed settings, I know I am late responding to this one. 

Using bundles in Eclipse's case is a natural, all post 3.0 Eclipse plugins are bundles, so a model or business logic component deployed as an OSGi bundle would just work.  

I suppose your question should be, when will IntelliJ and Netbeans get with the program?  Eclipse has since like 2002 I believe.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.