The JVM Is Not The Center Of The Universe!
If you follow the Java blogs and tweets in the last couple of years, you've heard the argument that the Java vitual machine is where the value of the Java platform is, and Java the language is mrely one language among many languages that allows programmers to write frameworks, libraries, and applications for the JVM.
And according to the stories, the race, of the alternative JVM languages—including Groovy, Scala, JRuby, Jython, Clojure, and others—to become the Java.next is on, and Scala is winning it, if the Java Posse is to be believed.
It is therefore not surprising that in the latest episode of the podcast, JavaPosse #262: The Week Of Controversies, Dick Wall raised the point that Google is leveraging Java in a different way:
Dick Wall [7:39—8:59]: Google has invested a lot of effort into doing Java language centric work. So Android compiles Java to Dalvik executable format. GWT takes Java and compiles it to JavaScript where it runs in various browser environments. And Google App Engine takes Java source code and runs it on a targeted subset of Java SE, minus some features like threads, background processing, and some of the core classes.
So it seems like Google is centered on the Java language. Now this is my point: Of all the Java landscape right now, the Java language is the least interesting to me, important for sure. But honestly why are they centered on Java the language and not Java the platform or more importantly Java the community. That just seems like a crazy thing to be concentrated on.
Java at this point feels like a language which is going into maintenance mode. Why this Java obsession? I think they are missing the much much more important parts of the overall Java landscape, which is the Java platform and the Java community.
And I can't get why they are so focused on the language. It's like they don't seems to get the other parts of Java right now, the more important parts of Java.
A debate ensued both in the podcast and in the JavaPosse Google Group:
While I agree with Dick that the Java platform (by which I assume he means the JVM plus the APIs) is a compelling one to develop and deploy applications, I don't share his puzzlement about the way Google uses Java the language to target platforms other than the Java platform (Dalvik, DOM, GAE, etc.).
One reason Dick gave for paying less attention to Java the language is that large scale innovation seems to have stopped for Java the language. However, that could be a very good reason for teams like those inside Google to adopt the language. After looking at all the alternative languages I mentioned above, my sense is that Java is still the undisputed easy-to-grok, easy-to-write, easy-to-read, and easy-to-maintain language among them all. Given the resources Google has, it is natural for them to experiment with targeting Java the language on different platforms. The era of the thou shall not separate the language, the virtual machine and the API has long gone. And the irony is that that policy has severely limited the reach of Java, as I blogged 810 days ago.
I believe the general Java scene is too much intoxicated in the belief that The JVM's the One True Virtual Machine!. It may seem that way from some perspective. However the history of computing teaches us that there is no One True Thing™. Eventually, some of the less mature VMs will catch up with the JVM. And two or three, or even four, of them will dominate the computing scene for some time. By then, the single VM languages will look silly. Groovy and Scala are particularly in danger. Python, with its Jython, IronPython, and python-parrot implementations will win the day.
I see Java the language jumping out of the JVM sea and reaching the land of the lesser known but equally promising runtime environment as a crucial step for the survival of Java.
In case you don't know, Java the language already runs on the .NET platform, as well as the native (amd64, sparc, etc.) platforms.
The JVM may seem to be the center of the universe to some. But it really isn't. And it's Achilles' Heel is the topic of another post. Stay tuned...
Tuesday JavaFX Quiz: What Will It Print?
Inspired by the on-going discussion titled Indexing access for Lists and Maps considered harmful? on the coin-dev mailing list, in which the Java language designers are hashing out the true meaning of
map["a"] = map["b"] = "c";
under the List and Map access through array-like indexing proposal, here is a somewhat similar question asked of JavaFX Script sequences.
Q: Will the following program compile? Run without exceptions? And if so, what does it print?
var seq:Integer[]; seq[0] = seq[1] = 1024; println(seq);
Lenient rules apply: no actual compiling for the first thirty minutes, but Googling, and consulting with books are allowed (and encouraged).
Undocumented JavaFX: The ScriptShell Repl
The recently released JavaFX SDK 1.2 includes the developer tools javafxc, javafx, and javafxdoc that are similar to the javac, java, and javadoc tools from the JDK.
What is not well-known is the fact that the JavaFX SDK 1.2 also includes a read-eval-print loop (repl) that developers can use for exploratory programming.
Well, almost. The Java class for the repl is included in the javafxc.jar file that is part of the SDK. However no command line tool for invoking the repl is available.
It is not hard to modify the existing javafx shell script to create a launcher script for the repl. That's what I did yesterday evening. I also throw in some JLine magic so that command line editing works. Here is javafxsh, shell script for the JavaFX Script repl. And for Windows users, here is javafxsh.exe (Cygwin users running rxvt or xterm should use the shell script). Just throw these into your javafx-sdk1.2/bin directory, and add the jline-0.9.94.jar file into your CLASSPATH environment variable, you are in business.
To comply with the GPL v.2 license of the original OpenJFX-Compiler, I've put my modified version of the source here. All of my modifications are also GPL v.2 licensed, so that you can further enhance it if you wish.
The repl is actually fully documented here by its author Per Bothner. The claim in the title of the post about undocumented-ness refers to the fact that the JavaFX SDK itself does not contain any documentation of this feature.
Here is an interactive session of me playing with javafxsh:
[weiqi@gao] $ javafxsh
/*fx1*/ function fib(n:Integer):Integer{ if (n<=1) n else fib(n-1) + fib(n-2) }
/*fx2*/ fib(6)
8
/*fx3*/
The current version of the repl has some limitations, e.g., it doesn't handle multi-line expressions yet. It also allows you some latitude in redefining variables, which is illegal under the compiler. However, there are considerable amount of experiments that can be done in the repl.
I hope you enjoy playing with JavaFX Script in a repl. And let me know if you encounter any problems.
Jython 2.5.0 Released
Frank Wierzbicki: On behalf of the Jython development team, I'm pleased to announce that Jython 2.5.0 final is available for download. See the installation instructions.
Jython 2.5.0 brings us up to language level compatibility with the 2.5 version of CPython. This release has had a strong focus on CPython compatibility, and so this release of Jython can run more pure Python apps then any previous release. Please see the NEWS file for detailed release notes.
Congratulations to the Jython team. And good luck with 2.6 and 3.0 and everything else.
You can try out some of the Python 2.5 features:
[weiqi@gao]$ jython Jython 2.5.0 (Release_2_5_0:6476, Jun 16 2009, 13:33:26) [Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_14 Type "help", "copyright", "credits" or "license" for more information. >>> import functools >>> def add(n, a): return n + a ... >>> add3 = functools.partial(add, a=3) >>> add3(10) 13 >>>
There were some (JLine related) issues of using the jython shell script under Cygwin in 2.5 RC2. The issue has been addressed in the final release.
If you are using Cygwin, like me, you can do a full (select "All") installation and copy the jython2.5.0/src/shaell/jython shell script to the jython2.5.0/bin directory; add the jython2.5.0/bin to your PATH; and invoke it with the -i command line option for interactive sessions. If your use of Jython is mostly interactive, you can use
export JYTHON_OPTS='-i'
to set up an environment variable so that you don't have to type the -i command line option on every invocation of Jython.
Larry Ellison: Committed To JavaFX
It's been several days since I came back from JavaOne 2009. This is my first JavaOne. Since the keynotes were streamed live, and the twitter stream were constantly being updated by so many people, I did not feel the urge to blog about it at the conference. I did a couple of tweets.
This blog entry is mostly for my friends and colleagues who did not go to JavaOne this year and who did not follow the various news and blog feeds. Answers to the "Hey, Weiqi, you are back. How's JavaOne?" I get in the hallway.
Oracle Endorses JavaFX
Any lingering doubts I had about Oracle's attitudes towards JavaFX were resolved on the Tuesday keynote address, in which Larry Ellison, the next leader of the Java community according to Scott McNealy, praised JavaFX by name:
Larry Ellison (7 minutes into Chapter 5): I've been meeting with different groups inside of Sun, and one of the things we are looking forward to is seeing libraries coming out of the OpenOffice group that are JavaFX based. So I think inside of Sun we would like to see accelerated development based on this exciting new platform, Java with FX, which now allows us, thank you very much James, (for) no more Ajax tools. A lot of suffering programmers will pray for you for the rest of their lives, because they don't have to program Ajax anymore.
Going to JavaFX is going to allow us to build fantastic UIs in Java. And we hope, we are going to encourage the OpenOffice group quickly to build their version of a spreadsheet and a word processor using JavaFX.
So we are very committed to see JavaFX exploited throughout Oracle and throughout Sun.
Meeting People
Meeting people is one of the reasons I went to JavaOne this year. And boy did I meet people!
First off, I met the coauthors of the Pro JavaFX Platform, Jim Weaver (aka JavaFXpert), Stephen Chin (aka Steve on Java), and Dean Iverson (aka Pleasing Software). The four of us presented the JavaFX course at Java University on Monday. I also attended Stephen and Jim's technical session based on the book. The printed book will come out in a few weeks.
I also got to meet these people: Josh Marinacci, Richard Bair, Jasper Potts, Chris Campbell, Amy Fowler, Brian Beck, Brian Goetz, Jai Suri, Neal Gafter, Joshua Bloch, Tor Norby, Jeff Brown, Guillaume Laforge, Graeme Rocher, Dierk Koenig, Jonathan Giles, Carl Dae, Stuart Marks, Jeff Martin, Peter Pilgrim, Geertjan Wielanga, Andres Almiray, Danno Ferrin, Chet Haase, Eric Bruno, Jim Clarke, Gail and John Anderson, and more. It's nice to meet people face-to-face. Nicer still when they say: "I read your blog" or "I read your article" or "The name rings a bell. You are the ..." Thank you.
Java 7
The big story on the Java 7 front is
The CLASSPATH is dead.
How so? Through the new work that is being done with modularity in Project Jigsaw.
On the JVM side there is JSR 292 invokedynamic bytecode. The story there is that the JVM is multi-lingual and will be home to all sorts of languages. Scala and Groovy had very strong presence.
And then there is Project Coin—small changes (slides).
I think it's been long enough from the debates that I can say without getting emotional that closure and reified generics won't be in Java 7. Maybe they really do want us to use those other languages on the JVM that have closures.
But, in honor of the original Java 7 feature list, which I blogged 1455 days (that's almost four years) ago, let me just say XML literals and move out of the way... You may now throw rocks.
Cloud Computing
I'm completely green in this area, but even I picked up some of the cloud computing vibe at Moscone Center. The Sun cloud and Google App Engine for Java were the most prominent. This blog is served by a collection of servlets running on my home machine. I imagine from a cost saving perspective, it would make sense to host it on the Google cloud.
I did go to the Google App Engine BOF and asked the question about obstacles for porting existing web apps to Google App Engine. The short answer is that file system access, data storage, and threading restrictions are the major obstacles. A longer, more philosophical answer is that one should not think of Google App Engine as "another Java hosting service" but rather a highly scalable machine managed by Google that happens to be programmable in Java.
The Toy Show (And The Show Toy)
The James Gosling toy show was fun to watch. Although none of the featured acts strike as super cool, The JavaFX Designer Tool that Tor Norby demoed did inspire awe from the audience.
Aside from its utility (think InterfaceBuilder for the Mac) for designers of JavaFX application when it is released by the end of 2009, I think another message, subliminal though it may be, is that JavaFX can be used for serious applications now.
The Java Store that is also previewed at the show reinforces that message, as do other presentations that demonstrated the use of JavaFX in their applications (I missed the talk by Dierk Koenig about JavaFX + Groovy = Beauty + Productivity, but the Geertjan has blogged about it on JavaLobby).
This year's JavaOne show device is the HTC Touch Diamond phone that is selling for $219 at the JavaOne store. It is a pretty usable device that has JavaFX pre-installed. Come to my cube tomorrow (or go to the St. Louis JUG tomorrow evening) and I'll show it to you.
That's some of my impressions of JavaOne this year. I'll post some JavaFX specific thoughts and pointers in future blog entries. Now that the book is almost done, I can resume my regular blog posting pace.