I met James Gosling last night & more on JWebPane

James Gosling was giving a talk at BT on the future of Java (the evening was very well organised by Philip Milne - thanks for the invite & lovely curry! :) - and James is a thoroughly nice chap & much taller than he looks online :)

In the Q&A I asked, if he had a magic wand and could change anything in the Java ecosystem (platform, language etc) what would it be? His answer was getting WebKit into the Java platform via JWebPane! Awesome - go James! Along with closures in the Java language that would be mine too as I've mentioned before. Apparently work is still progressing on JWebPane - so despite the total silence for nearly a year, it may hopefully one day see the light of day. I just hope Sun releases something soon - it doesn't have to be perfect, then we can fix it in open source as a community.

I do wonder if the JWebPane guys have been a bit too ambitious for the first release (e.g. all the stuff about using Java2D and Swing JTextField widgets within a web kit pane etc). Just having a webkit panel which you can communicate with via Java & interact with the DOM via Java would be rocking! The other stuff I'm less sure on how important that is (e.g. the super tight integration of swing widgets with the DOM widgets - just being able to place swing widgets inside the DOM would be fine).

Incidentally I've been meaning to follow up from my previous post on webkit in the JVM. I got alot of great comments and feedback either privately or on the blog. Some were from Swing folks who didn't wanna touch all this new fangled web stuff with DOM/HTML/CSS/JavaScript. Thats fine - if you wanna stick to pure Swing please be my guest I didn't wanna imply we should remove anything from Swing.

For the others, they all pretty much agreed we need awesome browse integration in the JVM - it would open up a massive amount of potential for rich applications which embrace the web but work around the limitations of browsers (networking & security limitations) and above all the biggest issue with developing on the web - dealing with the zillions of ancient crappy browsers. Instead building rich applications on the JVM using a modern embedded webkit wouldn't have those issues & would make creating web apps way more fun :)

Quite a few folks replied with links to existing projects similar in scope to JWebPane which I should just mention...

• JWebPane which hopefully will see the light of day one day, though its been eerily quiet for nearly a year...
• Qt has a WebKit component in its UI library
  
• SWT has a browser (FireFox) see the changelog and this eclipse con talk
  
• CB4J bundles Chromium WebKit in a Java widget
• Sage browser
  

I love competition; though I'd like to see a standard webkit component in the JVM and some consolitation though in APIs. I wonder if we could have some kinda JWebPane like API to interact with a 'Swing browser component' but let folks try different approaches to implementing that (e.g. using FireFox v WebKit etc)

JSR 299 (Contexts and Dependency Injection for Java) looks pretty good

I remember looking at an early draft of what used to be called the Web Beans JSR and it kinda looked a bit like 'hey lets try standardize Seam'. It didn't strike me as being too relevant or useful to folks typically using Spring/Guice to build their applications.

However I've just had another look at the lastest draft and its now looking pretty good. The rename to Contexts and Dependency Injection for Java certainly helps.

Dependency Injection is such a cross cutting concern throughout the Java ecosystem - its also a very well understood problem space with a small number of popular implementations. We really should have a set of standard annotations for Dependency Injection above the basics in JSR 250 so we really can write framework agnostic code that can work in more than one DI container. So far JSR 299 is the best effort I've seen to try come up with a standard.

Ironcially the annotations used in JSR 299 are almost exactly the same as those used in Guice 2 (@Produces/@Provides, @Named, @BindingAnnotation/@BindingType etc). Also Spring has started adding more and more annotation based dependency injection support of late; so the various approaches are kinda unifying a little.

So with a bit of effort it should be pretty easy to implement the dependency injection parts of JSR 299 in both Guice and Spring; so then we'd have a real, useful, dependency injection standard working across all the main DI frameworks.

I wonder if the Spring & Guice folks will put petty politics aside and really get behind JSR 299 for the good of the Java ecosystem?