Java XUL Redux
Patrick has some thoughts about my Java XUL post earlier:
I wonder if a java XUL implementation is a good idea.
If you only implement XUL and not XPCOM, the XUL apps created this way would not be portable to other XUL implementations, namely Mozilla.
The right thing to do I think is to work on the java-XPCOM interface to make the java constructs easily accessible from XUL using XUL's architecture, based on XPCOM. I wonder if it's not done already. Haven't look at that in years :-)
But if you want to go ahead anyway with XUL in java, the best implementation strategy would be to make a Jelly module, Jelly:XUL, like Jelly:Swing.
What's the deal with Jelly:Swing anyways? (and why isn't it Jelly.Swing, are we now using Perl or something?) Is Jelly Swing a macro that produces Swing code that I then compile, or is it a library that I include in my project and it creates the Swing UI at runtime? I don't really grok Jelly at all in this context (sorry James).
Anyways, I was thinking about XUL because it's becoming a standard for describing the UI using XML. There's already a working implementation of it in Java called Luxor, but it's GPLed and "doesn't strive to be a 100 % Mozilla XUL clone". The site has lots of good info on it including links to other projects including Xulux which seems to have either died or disappeared. (James and Bob what's up with that project?) The Luxor site also has a link to a "hacked together" version of XUL using Eclipse's SWT which would be VERY cool.
Patrick mentioned Java-XPCOM, which looks like it's lost in the either also, but the XRE (XUL Runtime Environment) looks like it's coming to life soon. But I don't really want to get that far out of Java to do my interface. SWT is cool because it's relatively lightweight...
Hmmmmm... Maybe I should take a look at SWT again. It's fast, but at the price of being very low level. Hey wow, a little Googling pulled up a DevX article on exactly these subjects.