Consumer JRE Explained (and Confirmed)
May 21, 2007
Chet Haase’s recent blog entry “Consumer JRE: Leaner, Meaner Java” sketches a thorough overview of what we can expect of the “Consumer JRE”. An excellent read!
Next to that I also found Augusto Sellhorn’s blog entry, which offers some more specifics on the installation experience and the upcoming Javascript API. He had the chance to attend the JavaOne “Easy Deployment Is Finally Here” talk by Dennis Gu and Ethan Nicholas.
Now if only the guys at Sun realized what they missed.
PS: Let’s hope the JavaOne sessions will become available online soon. This talk looks promising (among others).
JavaFX in the Browser: What They Missed
May 11, 2007
1. Applets have a bad name
Is it really hard to imagine this: you’re at the water cooler, and one of your colleagues asks you what you’re up to. You admit it: you’re implementing Java Applets. So the other guy just stares at you for a second and starts laughing, guessing it was a joke!
What I’m trying to illustrate here, is that Sun should have waited until they had the “consumer JRE”, and should have launched a new Applet initiative at the same time that new JRE launched. Call it AppletFX, drop the name, whatever… just get that bad taste out of people’s mouths. Which brings me to my second point.
2. They announced it too early
Sun probably felt the Adobe and Microsoft pressure in the same market, so the announced their thing ASAP. Guess what, they had nothing impressive to show. Sure, there’s JavaFX Script. Sure you can draw circles and make buttons spin. Hell no, you can’t use your mouse wheel in JavaFXPad (what gives?). I mean, where’s the candy? The impressive story? The leading vision? The cool feature? The great performance? As they say, you only have one chance to make a good first impression.
3. They forgot to include rich video an sound support.
People come for the bling, but stay for the platform. If you haven’t got the bling, nobody is there to stay. I didn’t hear them announcing anything on the subject. Did I miss that part?
4. Scripting is harder to read compared to XML (for designers?)
Say what you want about XML formats, but people got used to reading XML. Not a lot of syntax to look at, and easily toolable.
Sun is looking at yet another missed opportunity to revive in-browser Java apps. But they do have a nice alternative for creating desktop UI’s now.
JavaFX: The Return of the Bling
May 9, 2007
My summary:
- Sun started the JavaFX initiative, which currently includes JavaFX Mobile and JavaFX Script (formerly F3). The latter one is a scripting language (and associated libraries) for UI design and eye candy, which builds on Swing and Java 2D foundations. Some interesting bits:
- It uses the regular Java JAR deployment techniques: standalone, browser applet, Java Web Start.
- This is Sun’s WPF/XAML. They even cloned XAMLPad.
- It looks to me that it’s possible to use the JavaFX Script libraries in Java too, because they’re regular Java classes. So no obligations there.
- JavaFX Script ships plugins for Netbeans and Eclipse.
- The whole thing will be open sourced (GPL)
- Early next year Sun will release a consumer JRE, which would be a fast and lightweight version of the JRE, targeted at desktop/applet end users. At the same time they will be revamping the installation experience. There’s a related project codenamed “Java Kernel” which will modularize the JRE so that Sun can ship minimal JRE versions more easily. In other words, they will try to fix applets.
Obviously they’re trying to catch up with initiatives such as Microsoft’s Silverlight and Adobe’s Flex (and Apollo). But they still have a long way to go. Coming up next: what’s missing?
It all started with this InfoQ article. Apparently, Sun will announce an early version (alpha?) of JavaFX at JavaOne, an open source RIA platform that uses the F3 scripting language and has a set of UI libraries and a programming model that would rival those of Silverlight or Flex. The F3 programming language itself feels a bit like a mix of Groovy and Javascript 2 to me, but is looks like a powerful solution.
Of course it remains to be seen if it was really needed to have yet another programming language. Scrolling to the F3 spec, I can see one thing that they didn’t get exactly right: integrated query syntax. I’ve seen some interviews and presentations on Microsoft’s LINQ project recently, including the one Anders Hejlsberg gave at Mix 07. Someone in the audience asked “why do you guys put the from clause before the select clause?”. The answer was simple: how would the IDE know how to help you if you start with the select clause? Select it from what? Subtle, but important. But it looks like a nice language, and the type inference thing is what I like to call “dynamic typing done right”. And it has excellent Java interoperability, so there’s a whole universe of libraries available to you. Check out Chris Oliver’s blog for more info on F3.
Although JavaFX looks like a worthy addition to the Java platform, they’ll have to get some important things right:
- Tooling support: GUI builder, IDE plugins for F3, …
- Excellent browser support: easy deployment and fast (Silverlight and Flex got this one right)
I fear that Sun, as the “spec company”, will only implement a part of that story, and will count on the community to complete the picture. Well, we all know that some things just need some company throwing some money at it to get the whole story. Including timing…
I guess I’m exited. Let’s wait for the JavaOne announcement before we draw any conclusions (based on some rumors). But draw ‘em we will ;-)
Update: this blog links to some interesting stuff, including some hands-on exercises. Looks like they’re using Java Web Start for deployment. Where’s the browser integration?
Update: added link to official JavaFX page, lots of info there. The IDE support is there, but they’re using Java’s mechanism for deployment (standalone, Web Start, Applet).
Scripting Guice
May 6, 2007
I really like Guice, a Java 5 style Dependency Injection framework by the bright guys at Google.
People who are used to Spring’s DI config often complain that they don’t like the “compiled configuration” thing (Java Modules) Guice has. In Spring, all your wiring is usually done in XML. So on one side you have compiled Java Guice Modules, a more natural programming model for Java developers, and on the other side you have XML configuration, nicely externalized. And yes, I know the Spring guys plan on having a Java version of their configuration syntax, but it looks just like the XML, so I don’t see any real advantages there.
Anyway, for the Spring users who want to try out Guice, you could externalize your configuration to a properties file, and load it from that. Or whatever format you’re willing to use. Heck, you could even write some code that parses a Spring config file and translates it into a Guice Module.
But here’s another idea: what about using a scripting language for all your object wiring needs? Why create a configuration file if you could use the highly readable Guice Binder syntax? Well, I tried it, and it works great :-)
Let’s start with an example. This one’s about me drinking some beer. So here’s me:
public class Robbie {
private Beer myBeer;
@Inject
public Robbie(@Strong Beer freshBeer) {
this.myBeer = freshBeer;
}
public void startDrinking() {
myBeer.drink();
}
}
And here’s some beer:
public interface Beer {
void drink();
}
public class Duvel implements Beer {
public void drink() {
System.out.println("Duvel!");
}
}
public class StellaArtois implements Beer {
public void drink() {
System.out.println("Stella Artois");
}
}
The @Strong annotation basically means I’d like a strong beer, not just some water with taste. So I created a Guice BindingAnnotation for that, and expressed the binding in a module:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Strong {}
public class BeerModule implements Module {
public void configure(Binder binder) {
binder.bind(Beer.class).to(StellaArtois.class);
binder.bind(Beer.class).annotatedWith(Strong.class).to(Duvel.class);
System.out.println("Configured using Java implemented Guice Module!");
}
}
So everyone is getting regular beers, unless they specify they want some stronger beer. You could run this code like this:
public class StartGuice {
public static void main(String[] args) {
Injector i = Guice.createInjector(Stage.DEVELOPMENT, new BeerModule());
Robbie robbie = i.getInstance(Robbie.class);
System.out.print("Robbie starts drinking: ");
robbie.startDrinking();
}
}
This prints:
Configured using Java implemented Guice Module!
Robbie starts drinking: Duvel!
Hmm… tasty. Now, let’s get us some scripting. I’ll thankfully use the new Java 6 scripting support, you could probably use the BSF as well. Also, I’ll use Jython for scripting, a Java Python implementation. So I throw in jython.jar, jython-engine.jar (from the scripting site), aopalliance.jar next to the guice.jar. By the way, if you want to know how all this scripting support stuff works, check out Jurgen’s excellent introduction.
Anyway, let’s try binding our dependencies in Python. Create a file called BeerBinder.py that looks like this:
import java
from scriptguice import *
def configure(binder):
binder.bind(Beer).to(StellaArtois);
binder.bind(Beer).annotatedWith(Strong).to(Duvel);
print "Configured Guice using Python method!"
Then we add some scripting magic to our Guice Module, so that we delegate the configure call to the Python script:
public class BeerModule implements Module {
public void configure(Binder binder) {
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine python = mgr.getEngineByName("python");
Reader reader = ReadUtil.getReaderForClassPathResource("scriptguice/pythonmethod/BeerBinder.py");
try {
python.eval(reader);
Invocable invocablePython = (Invocable) python;
invocablePython.invokeFunction("configure", binder);
} catch (ScriptException e) {
throw new RuntimeException(e);
} catch (NoSuchMethodException e) {
throw new RuntimeException(e);
}
}
}
If we run StartGuice again, the output now looks like:
Configured Guice using Python method!
Robbie starts drinking: Duvel!
Great, it works! Now let’s take it one step further and get rid of the ugly Java / Python mix. Python all the way! Create a file called BeerModule.py:
import java
from scriptguice import *
from com.google.inject import *
class BeerModule(Module):
def configure(self, binder):
binder.bind(Beer).to(StellaArtois);
binder.bind(Beer).annotatedWith(Strong).to(Duvel);
print "Configured using Python implemented Guice Module!"
# Factory method that returns new BeerModule
def getBeerModule():
return BeerModule()
So we created a class called BeerModule, and subclassed the Java class com.google.inject.Module. Jython really starts to shine here. Let’s do some magic to get the thing back in Java:
public class StartGuice {
public static Module getPythonBeerModule() {
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine python = mgr.getEngineByName("python");
try {
Reader reader = ReadUtil.getReaderForClassPathResource("scriptguice/pythonclass/BeerModule.py");
python.eval(reader);
Invocable invocablePython = (Invocable)python;
return (Module)invocablePython.invokeFunction("getBeerModule");
} catch (ScriptException e) {
throw new RuntimeException(e);
} catch (NoSuchMethodException e) {
throw new RuntimeException(e);
}
}
public static void main(String[] args) {
Injector i = Guice.createInjector(Stage.DEVELOPMENT, getPythonBeerModule());
Robbie robbie = i.getInstance(Robbie.class);
System.out.print("Robbie starts drinking: ");
robbie.startDrinking();
}
}
It’s been a long time since my last beer, so here we go:
Configured using Python implemented Guice Module!
Robbie starts drinking: Duvel!
Man, how cool is this? Now we have defined the entire Guice module in Python code, and I got drunk in the process. Life just doesn’t get any better, does it ;-)
Now you could take it even further and return an array of Modules or what not, which is probably what you want in a real world app. Oh and one final note: don’t just copy paste this code. Close the Reader and stuff. I’m just being lazy for the sake of the example.
Thanks to Bob Lee and Kevin Bourrillion for creating Guice, the coolest DI framework on the planet.
Silverlight: an offer you can’t refuse
May 4, 2007
If you haven’t heard of it yet, Silverlight (formerly WPF/E) is the RIA platform Microsoft announced recently. But at the Mix 07 conference this week they surprised many: Silverlight 1.1 will ship with a stripped-down CLR. At the same time, they also announced the Dynamic Language Runtime (DLR), a framework for implementing dynamic languages on top of the CLR. In short, all this enables you to target the browser in your favorite .NET targeted language: C#, VB, Python, Ruby and even an ECMAScript 3 implementation that runs on the CLR (not to be confused with JScript.NET, which has different goals). Anyway, 1.0 beta and 1.1 alpha have shipped, so you can try it out yourself.
For people who never really liked Javascript, like me, this is great news. This means that you will no longer have to rely on Javascript to get some RIA/Ajax behaviour in your web app (built-in Javascript engine, or Adobe Flex and the like). Being able to use the language you know best in all tiers makes absolute sense.
Now if only Java had something like this (and God no, applets are NOT equivalent), because after all, Java is the language I know best, and damn right I would like to use it in the browser as well. An intriguing possibility is to use IKVM for targeting the Silverlight CLR. That would still be a little bit involved, but it could work.
Sun should wake up and smell the Java. I want real Java in the browser. Not GWT. Not Java Web Start. Applets done right. Friction-free deployment, and fast as lightning.
Thanks in advance.
