A Posteriori

With Larry Ellison’s recent public endorsement of JavaFX at JavaOne, it looks like JavaFX has a future once the Oracle takeover of Sun. In fact, he suggested that OpenOffice be rewritten in JavaFX (some considered it a bizarre comment, but it would be a bold strategic initiative). This is good news, because the efforts by Sun’s engineers are finally bearing fruit.

Joshua Marinacci has summarized the top 5 features of JavaFX 1.2, including Linux and Solaris betas:

http://weblogs.java.net/blog/joshy/archive/2009/06/top_5_most_impo.html

Osvaldo Pinali (of java.net) has some interesting observations on JavaFX 1.2:

http://weblogs.java.net/blog/opinali/archive/2009/06/first_look_at_j.html
http://weblogs.java.net/blog/opinali/archive/2009/06/first_look_at_j_2.html

However, his most important conclusion is that JavaFX Script may be a successor to the Java language:

http://weblogs.java.net/blog/opinali/archive/2009/06/javafx_script_a.html

With that and perhaps other few enhancements, JavaFX Script would become just as “complete” as other modern high-level OOPLs. JavaFX Script really could be a very viable candidate to the role of successor or companion to Java as a language for implementation of full Java applications.

Consider this: The Java language has come to a dead-end. The community, apparently, cannot stomach any evolution that would introduce even minimal backwards-compatibility breaking. The full compatibility constraint (both source and binary) makes very hard to introduce any major feature without some big compromise in either functionality, complexity, or interoperability with legacy APIs.

This conclusion was also reached by a poster (prime21) on a java.net poll a while ago:

http://java.net/cs/user/view/cs_msg/673284

The primary language on the JVM in the future will be JavaFX Script. New language features will go there. Java will not accept new features. That’s my prediction.

Sun’s plans seem to be to let legacy components of the Java framework unchanged for the sake of backwards compatibility (or legacy constructs) languish while it builds new components in parallel. This means that deprecated libraries will be maintained as separate modules and the Java language itself will no longer evolve (ex no addition of closures). This is the goal of Java 7’s module framework (Project Jigsaw) and the enabling of multiple languages in the JVM, respectively.

JavaFX Script seems to be less of a strict client-side Domain-Specific Language (DSL), and more of a prototype for the new default language of the JVM.

After all, it has support for closures, functional programming, data binding, no primitives (everything is an object) and more compact syntax.

Still, lots of work needs to be done, including, but not limited to:

1) Open source. JavaFX can become the RIA framework of choice for the open source community, and this would give it an unmistakable advantage over Flash and Silverlight. What’s more, it would allow for better debugging, since it would be possible to step into JavaFX classes (which I can’t do now).

2) Junit or unit testing functionality. Chalk this one to Fabrizio Giudici. This is absolutely essential for any serious programming.

3) Decoupling of GUI logic constructs from any server-side implementation. Otherwise, it would be weird to instantiate any of the GUI objects in the server VM.

4) Robust native support for multithreading. Right now, this is a bit of kludge:

http://forums.sun.com/thread.jspa?threadID=5382439&tstart=0

5) Profiling tools. Java has lots of these.

6) Some kind of native plugs into a more sophisticated database/ORM/JPA framework.\

After all, JavaFX will need to make up for around 15 years of evolution of Java tooling.