Update: using Time Machine on a network drive with Snow Leopard or Leopard

I now have much simpler instructions thanks to Jon who commented on my previous blog post. Forget all those icky complex command lines! Here's the simple way...

• download the CreateBackupVolume application from Jon's excellent backmyfruitup project
• run it - tell it how big to make the sparse bundle thingy
• a sparse bundle file then gets created on your desktop (the name of the file starts with your machine name)
  
• mount your network drive if its not already
  
• drag the sparse bundle onto your network drive (you can delete the local one)
  
• set TimeMachine to use your network drive
• wait :)

I've repeated the above now on 3 different macs including one old G4 and it worked like a charm each time. It seemed kinda faster than my previous Time Capsule too :)

Many thanks Jon! Using Time Machine with a network drive just got loads simpler!

Update: these instructions should work on any Mac with Time Machine, so it works just fine on Leopard too

Using a network drive with Time Machine on Snow Leopard

I bought one of these after my TimeMachine died and figured it'd just work with Time Machine. After some messing about it still didn't work & I was left scratching my head so I started to look for backup software alternatives.

Then @dancres pointed me at these awesome instructions on how to do it. The only trick is the sparse band size needs to be changed on Snow Leopard as mentioned here.

So the only change from the above instructions is the big meaty command I used to create the sparse bundle was this (my changes in bold)...

HN=`hostname | cut -f1 -d.`;MA=`ifconfig en0 | grep ether | sed "s|:||g" | cut -f2 -d' '`;hdiutil create -size 350g -tgtimagekey sparse-band-size=262144 -fs HFS+J -volname "TM_$HN" $HN\_$MA.sparsebundle

Then rsync it to your network drive as per the instructions above and it just works - yay!

rsync -avE mymachinename_12345.sparsebundle /Volumes/Whatever

(in the above you use the real generated sparse bundle name, and the real name of your network drive volume :)

Fuse Community days in NY & SF next week - come hear about ActiveMQ, Camel and ServiceMix

Next week we're hosting two Fuse Community day events in the states

• Tuesday 8th December - New York at the Hyatt Hotel in New York City
• Thursday 10th December - San Francisco at the Hyatt Hotel in Burlingame

If you're in the area pop by and say hello - you'll need to register on the above links.

We'll have a bunch of presentations on various popular open source Apache projects like ActiveMQ, Camel and ServiceMix. Schedule in the links above. See you there if you can make it!

Here's a flavour of what to expect, the devoxx talk I did recently.

a groovy scala example

So my last post caused a bit of a stir (though some excellent comments!). Sorry about that! :) I think a few folks got the wrong end of the stick thinking my post was some kinda put down of dynamically typed languages. I still like Groovy/Ruby/JavaScript etc. I tried to focus the blog post purely on folks who were hacking statically typed code in javac; that Scala was a natural long term replacement which is a much better, powerful & more elegant statically typed language. If you've already stopped using javac and using Groovy/Ruby/JavaScript/Clojure/whatever then the post wasn't really meant for you as you don't need a javac replacement as you've already stopped using javac :)

Charles Nutter explains what I was trying to say way more elegantly

Scala, it must be stated, is the current heir apparent to the Java throne. No other language on the JVM seems as capable of being a "replacement for Java" as Scala, and the momentum behind Scala is now unquestionable

Anyway the reason for this post was to show how Scala is very Groovy based a nice example posted to the comments by James Iry. Here's the Scala code first

val (minors, adults) = people partition (_.age < 18 )

I'm sure most of you will agree its pretty clean, concise code and easy to read. It partitions a collection of people into two collections of minor and adults based on age.

Guillaume LaForge posted the Groovy equivalent

def (minors, adults) = people.split { it.age < 18 }

Notice how apart from some pretty minor surface syntax differences they are kinda identical to read. Mostly Groovy forces the dot between people and the split method (I think thats still true?) and uses 'it' for the default parameter name in a closure block rather than the Scala equivalent of _ if no name is specified. (Scala the _ is the wildcard symbol in various parts of the language as * is an operator on lots of objects like numbers).

So Scala and Groovy code can look about the same; nice concise, easy to read - describing the intention of the developer, rather than lots of noisy lines of code, or maybe ugly anonymous inner class noise using non-standard helper libraries to try simulate having nice core language support for working with very common data structures in a powerful expressive way.

There's a ton of Java libraries out there trying to tack on the ability to work with common collections & data structures in the modern Scala/Groovy/Ruby/Python/C#/VB way (dare I use the monad word here?) - I even helped create one many years ago. FWIW if you're stuck on Javac, do take a look at google collections which is really good.

My main criticism of these approaches in Java is they are non-standard (there's a ton of them out there - which to use?) and they are separate to the objects you want to work with. You can't just use a List, Set, Array or Map directly - you have to remember the separate class in a separate package you need to import so you can just do simple basic operations on data structures concisely. This kinda stuff is so basic, it should be a core feature of the programming language you use IMHO.

So both the Scala and Groovy examples above are a big improvement IMHO over their Java equivalents. I just wanted to demonstrate one of the additional benefits the Scala version has. While the code looks about the same, the Scala one creates immutable variables (which are great for concurrency) but the main difference is that the values are all statically typed. That means the compiler / IDE / documentation tool knows the exact types of the variables (minors, adults, people). Big deal I hear some of you say.

Well here's a handy example of why that is useful. Imagine you exposed this line of code as an API folks could invoke. Here's a PersonThingy object which defines a method minorsAndAdults as follows

def minorsAndAdults() = people partition (_.age < 18)

Now notice how the generated API documentation describes the return type of minorsAndAdults() as being (List(Person),List(Person)). i.e. you know its gonna return a 2 value tuple with a list of people for both values. This is very handy when you want to expose your code to other people; you don't have to write documentation (which gets out of date fast) describing what it is you return, the compiler can do all this for you. Plus when folks try to invoke your method their compiler & IDE will type check their code as they type it to ensure its used correctly (e.g. in case the user forgot to extract the first value from the tuple etc).

This also works nicely when using map. For example here is a little example which defines two methods greetings and lengths using the same value and a map method call but just using different expressions in the function passed

def greetings = names map ("Hello " + _)

def lengths = names map (_.size)

which return List[String] and List[Int] respectively.

So while dynamically typed languages and Scala can look as equally as concise; being statically typed can save you yet more typing explaining stuff the compiler/IDE/documentation generator already knows - and it avoids documentation going stale after refactoring - for example to change the data structure.

One closing observation. A common put down (usually from folks who've never read a good Scala book or really tried using Scala in earnest) is "oh its too complex". Yet the code you frequently write when working with objects, collections and data structures often looks very similar to the Ruby/Groovy/JavaScript/Python equivalents - yet folks rarely use the complexity word with those languages.

I wonder if part of the problem is, Scala & its community tends to describe Scala code and what the language is in terms of various (slightly academic) programming language concepts so that you can understand how the language works internally so advanced users can see how you can bend it to do what you need in a more concise & expressive way. For example back to James Iry's example

val (minors, adults) = people partition (_.age < 18)

That one example uses a tuple, pattern matching, a lambda, and partial function application. Describing how the language works tends to make it sound more complex (especially if you use the monad word) than just saying 'here's how to partion a collection'. If you were to take the similar Groovy/Ruby/Python code and tried to explain how the language actually implemented that line of code it would sound about as complex (often with meta object programming in there somewhere).

Scala is frequently described as a unification of functional programming and OO programming language concepts. A common push back from OO folks is, "I don't like functional programming, I just wanna do OO". Yet those same OO folks seem to really like closures, lambdas, for/list comprehensions and so forth. For example VB has lambdas, C# them too and has list comprehensions. Folks tend to really like them - whether they are developers using VB, C#, Ruby, Python, Groovy, JavaScript etc.

i.e. it seems most of us all really like an OO language with functional language features; we just don't like to think of ourselves as functional language developers :) Microsoft BTW is doing really well at turning C# and VB into OO and functional languages - but just avoiding using the 'f' word to avoid scaring folks off. I wonder if the Scala community should use the 'f' word a little less? :)

Scala as the long term replacement for java/javac?

Don't get me wrong - I've written tons of Java over the last decade or so & think its been a great evolutionary step from C++ and Smalltalk (lots of other languages have helped too like JavaScript, Ruby, Groovy, Python etc). However I've long wanted a long term replacement to javac. I even created a language to scratch this itch.

Java is a surprisingly complex language (the spec is 600 pages and does anyone really grok generics in Java?), with its autoboxing (and lovely NPE's hiding in there), primitive types, icky arrays which are not collections & general lack of polymorphism across strings/text/buffers/collections/arrays along with extremely verbose syntax for working with any kind of data structure & bean properties and still no closures (even in JDK7) which leads to tons of icky try/catch/finally crapola unless you use frameworks with new custom APIs & yet more complexity. Java even has type inference, it just refuses to use it to let us save any typing/reading.

This issue becomes even more pressing with there being no Java7 (which is even more relevant after Snorcle - I wonder if javac is gonna be replaced with jdkc? :). So I guess javac has kinda reached its pinacle; closures look unlikely as does any kind of simplification or progression.

So whats gonna be the long term replacement for javac? Certainly the dynamic languages like Ruby, Groovy, Python, JavaScript have been getting very popular the last few years - lots of folks like them.

Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.

So why Scala? Scala is statically typed and compiles down to the same fast bytecode as Java so its usually about as fast as Java (sometimes a little faster sometimes a little slower). e.g. compare how well Scala does in some benchmarks with groovy or jruby. Or this. Note speed isn't everything - there are times when you might want to trade code thats 10x slower for more productivity and conciseness; but for a long term replacement for javac speed is important.

Yet Scala has type inference - so its typically as concise as Ruby/Groovy but that everything has static types. This is a good thing; it makes code comprehension, navigation & documentation much simpler. Any token/method/symbol you can click on to navigate to the actual implementation code & documentation. No wacky monkey patching involved, or doubting of who added a method, when and how - which is great for large projects with lots of folks working on the same code over long periods of time. Scala seems to hit the perfect sweet spot between the consise feel of a dynamic language, while actually being completely statically typed. So I never have to remember the magic methods that are available - or run a script in a shell then inspect the object to see what it really looks like - the IDE/compiler just knows while you edit.

Scala has high order functions and closure support along with sequence comprehensions so you can write beautifully concise code. Scala also unifies functional and OO paradigms beautifully together into a language thats considerably simpler than Java (though the type system is of a similar order to truly understand than generics - but then thats usually an issue for framework creators rather than application code developers). It also lets folks gradually migrate from a traiditional OO/Java way of coding to a more functional way - which is particularly relevant for folks writing concurrent or asynchronous code (which due to the GHz of chips no longer going up but instead we're getting more cores is becoming more necessary). You can start the OO way and migrate to using immutable state if/when you need its benefits. Increasingly functional programming is becoming more and more important as we try and make things more concise and higher level (e.g. closures, higher order functions, pattern matching, monads etc) as well as dealing with concurrency and asynchrony via immutable state etc.

Scala also has proper mixins (traits) so you don't have to muck about with AOP wackiness to get nice modular code. There's even structural types in case you really do need some duck typing.

The thing which most impresses me is the core language syntax is pretty small and simple (the spec is about a quarter the size of Java's); but its way more powerful and flexible and is very easy to extend in libraries to add new semantics and features. For example see the Scala Actors. So its ideal for creating either embedded DSLs or external DSLs. There's really no need to have Java , XPath, XSLT, XQuery, JSP, JSTL, EL and SQL - you can just use Scala with some DSLs here and there (examples of this later...).

Scala does take a little bit of getting used to - I confess the first few times I looked at Scala it wasn't that pleasing on the eye - with Java you're kinda used to dumb verbose code which doesn't do very much - it can be quite a shock to see quite a few symbols at first. (It took me a while to get over the use of _ in scala which is the 'wildcard' symbol since * is an identifier/method).

If you've been doing lots of Java then Scala does feel quite different at first - (e.g. the order of types & identifiers in method/variable/parameter declarations - though the reason for that is to make it easy to miss out redundant type information).

e.g. in Java

List<String> list = new ArrayList<String>()

in Scala

val list = new List[String]

or if you want to specify exact typing

val list : List[String] = new List[String]

However if you keep at it, the beauty of Scala soon becomes apparent; its simplified so many of the gremlins in the Java language, allows you to write very concise code describing the intent behind the code rather than the implementation cruft - together with providing a nice migration path to elegant functional programming which is awesome for building concurrent or distributed software.

I highly recommend you take a look at Scala - with an open mind - and see if (once you're brain adjusts) you can see its beauty too.

Some scala links and online presentations

• I can highly recommend the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners - its a great read and describes the features of Scala and design choices very well. Its a big book - but you can skip chunks and come back to it later.
• I've only skim read it a little so far but the O'Reilly Scala book looks great too
  
• the Tour of Scala is a good read if you're short on time and want a quick look at its syntax; though it can take a little while to truly appreciate why things are different to Java
  
• Martin Odersky's Scala talk at JavaOne 2008
  
• Jonas Bonér's presentation on Real-World Scala
• Gert's presentation on how he created the Apache Camel DSL for Scala
• speaking of internal cool DSLs try this blog post on program like you mean it with links to some other great internal DSLs for Scala
• a scala version of LINQ for type safe querying of JDBC also check out dbc
• a great presentation on using Scala and OSGi with DSLs
  
• how to work with Scala and XML (kinda embedded XML, XPath, XSLT, XQuery in neat syntax in the language :) more here
• Scala by example
  
• Scala cheat sheet
• an example showing how to create bean style properties (or C# style getters)
  
• creating a chat demo using Lift or more on the Lift site
  

If you have a spare hour or so these video talks are great to watch

• The Feel of Scala by Bill Venners
  
• Scala: Bringing Future Languages to the JVM by Lex Spoon

Handy Scala frameworks and libraries

• liftweb the rails of scala
• specs and ScalaTest for BDD and more literate testing showing how a typesafe DSL can help you write more consise and expressive code that is very IDE friendly
  
• scalaz a handy library of utilities
  
• dispatch for working with HTTP/JSON services

BTW for those like me who love JAXRS you can now use lift templates with Jersey via the new jersey-lift module.

As an example of this in action you can check out RestMQ which is an open source project I've been working on lately to provide a RESTful API and web console to message orientated middleware which is built on JAXRS (Jersey), Scala and Lift.

From a tooling perspective there's Ant/Maven plugins, an interactive Scala console (REPL) and IDE plugins for IDEA, Eclipse, NetBeans along with the usual editors (TextMate/Emacs etc). The IDE plugins are not yet up to the Java grade, but they are very useful with good code navigation & completion.

I've tried the plugins for NetBeans, Eclipse and IDEA they all have strengths and weaknesses; it seems Scala folks are split between them all. For code navigation and completion along with maven support I've found IDEA to be quite good. When you open a Maven pom.xml it seems to grok the code nicely, finding the scala source so you can navigate through any type/method to see its documentation/source etc. (You do typically have to manually add the Scala facet to run/debug stuff). Though IDEA is not always the best at highlighting syntax errors as you type. They could all use some work to bring them up to line with their Java counterparts though - try them out and see which you prefer.

Scala nits
With any language there's gonna be bits you love and bits you're not so keen on. Early impressions of Scala do seem like there's a bit of an attempt to use a few too many symbols :-; but you don't have to use them all - you can stick to the Java-ish OO side of the fence if you like. But then I guess longer term its probably better to use symbols for the 'special stuff' to avoid clashing with identifiers etc.

I'm not a massive fan of the nested import statement, using _root_.java.util.List to differentiate a 'global' import from a relative import. I'd have preferred a child prefix. e.g. if you have imported com.acme.cheese.model.Foo then to import model.impl.FooImpl i'd prefer an explicit relative prefix, say: import _.impl.FooImpl which would simplify things a little and more in keeping with Scala's attempt at simplifying things and removing cruft (being polymorphic to import java.util._).

However compared to all the massive hairy warts in Java, these downsides of Scala are tiny compared to the beauty, simplicity and power of Scala.

Conclusion
Given that MrJava, MrJRuby and MrGroovy are all tipping Scala as javac's long term replacement, there might be something in it. So what are you waiting for; get the Programming in Scala book or the O'Reilly Scala book and start having fun :)

thoughts on the new @Inject JSR

There's been some interesting feedback from JSR299 folks on the new @Inject proposal. (Though there is a bit of argument for argument sake in there :).

I can understand 299 folks wanting there to be just one spec that talks about IoC. However IoC is a large complex area that is still undergoing quite a bit of innovation (e.g. see the changes in Guice 2 and the JavaConfig which is part of Spring 3).

For me the great thing about the new @Inject JSR is that its small, simple and focusses on the common well understood part of IoC (the annotations you add to your objects so that popular IoC containers can inject your objects). This is the thing I most want - a standard set of annotations I can use everywhere in objects - then consumers of those objects can choose whatever IoC container they wish to wire things together be it Spring or Guice or a JSR 299 provider or whatever. The actual wiring code (in Java, XML or some other script/language) tends to be kinda small stuff relative to the tons of Java code for the objects themselves. Given the large variety and constant innovation in the wiring side of things, its probably a bad time to try lock that part down as I don't think there's consensus on how that part should look (though Guice 2 and Spring JavaConfig seem to get closer all the time).

299 however standardizes lots of things which only seem to be done in Seam; I don't see Spring, Guice or Pico implementing 299 any time soon as its a bit too big - however all IoC containers should be able to implement @Inject pretty easily; most IoC containers have already got something like @Inject in them today.

So as a practical kinda guy at heart, the best way forward IMHO to be able to write IoC container agnostic objects that can then be injected by Spring, Guice, Pico, Tapestry or indeed a 299 provider seems to be the @Inject JSR.

This doesn't mean 299 isn't useful; there's some interesting stuff in there particularly relating to eventing and JEE integration to IoC; but I see getting @Inject done and adopted by Spring, Guice & Pico (and hopefully the JSR 299 RI too!) to be most important for IoC in the Java ecosystem as a whole.

If you are using OSGi then give Pax Exam a try

Pax Exam is a great piece of work! It makes it super easy to write JUnit4 tests which can then be run in multiple OSGi containers like Felix & Equinox using the exact bundles you require - plus it lets you inject BundleListener and so forth. Here's the tutorial which should get you started pretty quick.

I recently added an OSGi integration test to Apache Camel, here's the test case if you're interested. Notice how the versions of the bundles added to Felix and Equinox are not mentioned in this test case - they are inherited from the pom.xml from Maven.

The depends-maven-plugin from ServiceMix Kernel (soon to be Apache Karaf) generates the file target/classes/META-INF/maven/dependencies.properties which Pax Exam can then use to resolve the version dependencies of groupId/artifactIds. This lets you keep all your version information in your pom.xml and avoid having to update all your test cases whenever your pom.xml changes - keeping things nice and DRY!

Great stuff Pax-folks, keep up the good work!

Apache Camel switching from Java to BPEL, WSDL and RDF XML (with some XSLT)!

The Apache Camel team has always strived to make complex integration challenges as easy as possible connecting pretty much all transports, protocols and middleware together easily using any of the enterprise integration patterns typically in a single line of Java code.

However our users have often said that Java is way too complex to understand. So to tackle that need we're dropping support for Java due to its complexity and instead we're switching to a combination of BPEL, WSDL and RDF XML Syntax instead (with maybe some XSLT too).

We're hopeful that a single XML document with 6 or 7 namespaces along with 2 or 3 spring ones should just about be able to route from one endpoint to another in a similar way to using a line of Java code - but using all the power of the various XML specifications; making it easy to add any WS-* specifications you fancy too!

One downside of this approach is that the XML header to define all the namespaces and their prefixes is about page or so of text but we're hoping a netbeans plugin will be completed soon that just hides the first page of your XML - making development much more agile!

We've also got a signed CLA on file so we can reuse Opera's new face gestures technologies to help typing in all those pointy brackets and XML namespaces; while giving yourself a great face workout at the same time. Agile integration and fitness in one!

More detailed design notes are available here from our new technical architect on the project.

Go Camel! :)

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?

Apache Camel 1.6.0 released - 2.0 not far away!

Both Claus and Jon beat me too it, so being lazy am just gonna link to their posts. You can grab the latest Apache Camel 1.6.0 release with its 169 improvements on top of the 266 improvements from the 1.5 version.

Get it while its hot! Work is progressing well on 2.0 which will hopefully be out soon too! Great work Camel Riders!

How Sun could fix Swing and promote innovation and unification in the UI space

I saw Jonathan's post on Swing 2.0 and it was late, I'd had a nice glass of wine so I fired off a wacky idea on twitter which got some interesting feedback. I'd like to just expand on the background of the idea some more as I'm not so sure it is so wacky an idea afterall. Its feeling more and more like a no brainer and complete win win.

I'm afraid this post is gonna be quite long. (Holy crap - no blogging for ages and then two big posts in a week!) - first some background...

Programming Rich Java Applications Is Sucky
Imagine the scene. You're part of a team of Java developers; you're tasked to write a rich application. It might be a commerical app or some intranet enterprisey thing, or some rich application to improve the user experience of some web app (like the iphone versions of facebook/twitter/gmail etc) - whatever. So what do you do?

You've a mindnumbingly broad choice to choose from - here's just a few options...

• Swing
• SWT/JFace/EclipseRCP
• web app with some combination of Ajax/JavaScript/GWT libraries
  
• JavaFX?
• Flex/Flash

Each have their own strengths and weakesss. Though they all totally different. Write for one of those then later on you're requirements change (making one of the other options more attractive) and you've gotta scrap it all and start over.

Write once and run everywhere - except if your application has any kind of user interface.

This is maybe why so many Java folks like writing server side apps; as the client side in the Java ecosystem is such a mess.

Helping Swing Developers
Lets imagine you pick Swing to develop rich applications. In its day, Swing was a good piece of work by Sun. However that day was in the nineties :)

I've done a fair bit of Swing in my time and worked on Swing projects; in my experience you can spend years trying to tart up a swing app and it still looks - well like Swing. You can get a day of a good web designers time and make any web application look stunning via HTML/CSS/images. It just seems so much easier to hack up HTML/CSS to look great. Just compare some great web 2.0 applications out there to your typical Swing UI. As an end user which would you rather use?

As a developer one of the big PITAs with Swing is layouts, styling and working with images and links. The standard layout managers suck. (GridBagLayout anyone?). Yes I know there's a zillion layout manager implementations out there - all doing different things well with different results & rendering bugs - and which one do you choose?

Generalizing hugely but most of the work that goes into most data entry-ish rich applications is creating loads of screens which are full of text, images, links and some rich widgets with plenty of documentation, popup help, cheat sheets and then laying it all out and styling it nicely. Swing is lousy at these UI basics. Sure its got a good JTable and JTree, something that many a web developer will probably have been envious of at some point or other when hitting gremlins in their JavaScript table/tree - but at laying out forms, dialogs, help screens, documentation and working with links and images - well its kinda sucky.

Swing developers should be using HTML/CSS for this - its great at it. The web browser is the best layout manager we have - and HTML/CSS is the best standard for laying out widgets. With HTML/CSS there's a ton of tooling out there too for viewing/editing/styling. You can then pass the HTML/CSS to your web designer while the Java Swing hacker focusses on the business logic or the complex widgets.

Plus any time you spend hacking HTML/CSS - being a simple, standard text format used inside web browsers means you can reuse your work in web applications as well as rich applications. You don't spend your time hacking up some Swing Java code thats only useful inside a Swing application.

My Proposal
So my proposal is, in Java 7 we integrate WebKit into the JVM. Why WebKit? Well its smaller and easier to integrate than Gecko; Apple chose it for Safari & iTunes and the iPhone and Google chose it for Chrome and Android. If its good enough for a cell phone surely we can fit it into a JDK/JRE for a rich desktop application?

If Sun wanted to get clever, the browser engine could be pluggable; letting folks pick different versions of WebKit or FireFox/Opera/IE - but lets not go there right now - lets just assume a recent WebKit version is baked into the JRE/JDK.

Some would argue it should be optional; but then given the size of the JDK/JRE there's a ton of not-that-useful stuff in there; I'd rather include it by default over loads of whats there :) But then the JDK/JRE is getting more modular right - so lets leave the optional nature of WebKit for when the JDK/JRE is truly modular - right now its huge; so if a cell phone can include it, so can a JDK/JRE :)

Next we have a standard Java API for creating a BrowserPanel which can be hosted inside any AWT/Swing/SWT/JFace based UI. So a browser window becomes a standard embeddable widget in Swing and SWT/JFace/Eclipse. There should also be an API for controlling the browser (loading/saving URLs and interacting with the DOM).

Finally I'd like any AWT/Swing/SWT/JFace/JavaFX component to be usable within the DOM of WebKit. So I could create a nice HTML page with nicely formatted and CSS'd text, images, tables but then include, say, a JTable and JTree in the middle somewhere; letting the browser do the layout stuff.

This last requirement might seem complex but thats exactly what Flash and JavaFX are already; plugins which create custom UI widgets within the DOM.

For those that are aware of GWT Hosted Mode; this proposal is very similar - embedding a web brower inside the JVM as a single process. The main differences are

• we need a standard API to spin up browser windows and embed them inside any Panel and to be able to bind any UI Panel inside the DOM easily (e.g. finding a div by ID and binding it to a JTable)
  
• we don't need the restriction of being able to turn the Java bytecode into JavaScript - as for standalone Swing/rich apps you can can leave it as it is :). So any Java code could work with the browser. So none of the GWT restrictions would apply - plus you could use Groovy/Ruby/Python/JavaScript/whatever
  

Benefits for Swing Developers
Swing would instantly get an awesome, standards based layout engine capable of easily rendering styled text, images and widgets while dealing with other kinds of media. Through the use of CSS Swing applications would be easily styled using all the existing HTML/CSS tooling.

Swing developers would then have the best of both worlds; their Swing widgets still working when they want to use them - but having the great power of the browser window around the widgets to make the layout easy, powerful and great looking.

Since the JVM would now have a standards based browser; and it can already run JavaScript (and pretty much all other languages) easily - any Swing application could make use of any of the current GWT or JavaScript frameworks out there. There's a ton of innovation happening in the JavaScript/GWT space right now leading to ever better UI capabilities. e.g. take a look at SmartGWT and jQuery to name but 2.

Benefits for Web Developers
So how will this move - aimed at helping Swing developers help Web developers? The common PITA for web folks is often the browser imposes restrictions (for good reason) such as

• only being able to interact nicely with the single domain that serves the web page
• not able to interact with the file system
  
• only having 2 threads for communication
• limited connectivity (kinda hard to use native sockets, Java web stacks, JMS, native JDBC etc)
• unable to use things like Java2D/3D without via plugins
  

Plus there's dealing with the large number of different browsers of different capabilities & configurations & versions to support.

Now if you're making a public application; you're probably gonna have to deal with this (though now we're seeing custom apps for the iphone and android - maybe rich applications for public web sites are gonna be more common?). However loads of folks build web applications when they are really building internal, intranet applications.

So why not turn that web application into a desktop application making it run in a JVM? You can then package up your application with the exact, known browser you use and test with - and have access to all the features of the Java platform in your UI; whether its Java2D/3D, Swing/JFace, JavaFX or JMS/JDBC/JAX-WS etc

How this application is then made available to your users could come in different flavours; an application they install, Java Web Start (which might become cool again) or maybe even via JavaFX inside a browser?

So this could give a big safety net to folks building web applications. If you hit a browser limitation such as (say) a Canvas limitation? Just provide a Java2D version and ship a desktop application or Java WebStart it? It could end up that the JVM turns out to be the best place to host a web application reusing HotSpot?

Benefits for UI Developers
This single act of unifying the browser with Swing (and SWT/JFace) would provide a massive unification of standards based technologies for most UI development. More of the time spent building UIs would lead to creating more reusable standard artefacts (e.g. HTML and CSS) which are reusable in other contexts (e.g. transform HTML into PDFs or reuse the embedded microformats etc).

In these days of Dependency Injection; we're used to having a single code base then switching component implementations in different circumstances and environments; so we can start building more UIs which can be both web application and rich UI with each UI making the best use of its platform (zero install for web app, no limitations for desktop app).

Previously changing an application from a web application to a desktop application or vice versa was a massive undertaking (near total rewrite). Now it'll be pretty trivial to switch from one to the other as your requirements change. Applications will no longer be locked into one UI technology unable to move. UI code will become more aligned with the Write Once Run Anywhere mantra.

If folks create rich applications and web applications - there could be massive code reuse. While a web application and a Swing/JFace application are clearly going to have differences; they may use different views, components and features - there could be a huge amout of reuse of code. Even if the code reuse is only 30-50% its is big a saving; and we all need to do more with less these days. Though I can see - as UI frameworks improve, more and more chance of better code reuse across both.

Benefits for Sun
Folks have often said things in the past about Sun like

• Sun doesn't get the desktop, its not its core business
• Sun can't compete with Microsoft in its back yard (the desktop)

Sun is tightening its belt as is prudent for any company to do in the current climate. Sun has already de-funded SwingX. Also so far all the feedback and responses I hear from non Sun folks about JavaFX is at best lukewarm.

This move however would be a massive, positive move in the UI space and earn Sun a lot of kudos IMHO. Sun could then leverage all the innovation thats taking place in the browsers and WebKit in particular (HTML5, SVG, microformats et al) along with in the JavaScript worlds.

It would also mean there's not that much for Sun to do (other that integrate WebKit and provide APIs to control the browser and expose the DOM). All the innovation can then happen above this layer by the Swing, JFace & web developers and the WebKit & JavaScript communities. Immediately the Java ecosystem could then reuse all of the amazing work being done by the webby folks in JavaScript or by the GWT ecosystem.

i.e. the Java platform would then become a cool place to develop applications for (removing all the limiations with web browsers) with loads of buzz -and Sun doesn't really have to do much other than take all the credit :)

Heck they could even brand the WebKit-in-JVM as part of the JavaFX brand; so JavaFX doesn't have to beat Flash/Flex & Silverlight in the market to avoid looking like a turkey. JavaFX Platform (or whatever we call it - basically Java7 + WebKit) could turn into an instant success (anyone doing Swing or JFace would probably start using the embedded browser for better layouts & rendering) and if that helped the JavaFX Plugin (the JavaFX-as-browser-plugin) make some inroads to Flash/Silverlight its an added bonus. (Whereas right now JavaFX as just a browser plugin looks setup for failure to be honest, I don't see it ever eclipsing Flash).

Note its worth mentioning that there's similar moves to DOMs and whatnot being experimented with in the Eclipse ecosystem; who knows we could maybe finally unify on a single DOM?

Benefits for the Java Platform
Being able to build rich desktop and web applications in any language - without any browser limitations would be a massive boost to the Java platform; allowing folks to reuse all the good stuff from the OpenWeb and the Java platform (language diversity, IDEs and tooling, connectivity, Java2D/3D and even JavaFX).

We'd also hopefully see significant cross-pollination of the Swing / JFace folks and web folks to help UI innovation (which Sun doesn't have to try do itself).

If nothing else hopefully it will encourage more folks to write web applications and desktop applications to take advantage of both environments to provide better user interfaces for our users and customers for less effort.

Sounds like a win win for everyone doesn't it?

Update - JWebPane
So I should probably pay more attention to the JavaFX stuff :)

It seems that there is such a thing called JWebPane (see page 27 onwards of this presentation) which has been announced - so maybe this is gonna actually happen soon! :).

IMHO JWebPane sounds way more important to the Java ecosystem than JavaFX - I really hope it gets enough backing and funding from Sun to get completed and released real soon! Its not good to see nothing at all being released to the community despite it being announced about 7-8 months ago - so fingers crossed that whatever the legal/licensing issues are holding it back get resolved really soon.

We've just gotta lobby Sun to release it ASAP - then include it in Java 7... :-)