Wednesday Aug 27, 2008

Firing up the engines for multiple languages

Have you seen the latest update from John on our efforts to make the JVM run multiple languages ? (I'm in a staff meeting writing this, but don't tell anyone :) ).

From one to many languages

For those of you who would like a little context around International Invokedynamic Day, for the last few years we've been on a path towards first class support for other languages on the JVM. No small feat this, since the Java Platform was originally designed with one language in mind. Now, we still believe that Java is the best language for robust, long lived code. But we know that developers like to mix in other languages that for special reasons: for particular applications, for particular styles of development. Just as important, we've spent 13 years creating an incredibly scalable and high performing runtime across a variety of operating systems. So for developers who create applications with other languages (and we hope there will be many who like JavaFX Script), we figure they would like to run those apps on the best runtime around.

So, as a matter of fact, do the creators of the engines for other languages like Ruby, Python, Groovy, Scala - they started creating the engines to run on the Java Platform.

Lining up the engines

So for Java SE 6, we provided a framework by which those interpreters could plug easily into the Java Platform. And the developer APIs by which the code from those other languages can be asked to execute. We even bundled a JavaScript engine into our own JDK. At the same time, more and more developers created the engines to run other languages on the Java platform.

Firing up the engines

Now, many of the languages that are attracting the buzz that have been invented since the Java language have a feature in common with each other, but not with Java: they are dynamically rather than statically typed. So the types of the variables, method parameters, return variables and so on are not known at development time, unlike in Java where you are required to declare them. All very nice for rapid prototyping and a more informal style of programming, but a big problem for compiling it down to the Java bytecode because the Java bytecode needs that type information filled out. So engines for dynamic languages have to create artificial interfaces or classes just to do the form filling. Making them brittle, difficult to maintain and slower than they could be. But not if we modify the bytecode to remove the need to fill out all the type information.

So back to the update: John has prototyped support for the modified bytecode in the HotSpot JVM !

What this means is that implementors of dynamic language engines are now free to try this out and prove the theory. I'm predicting that Charlie will be one of the first with his JRuby project, but the race is on.

Some of the newer languages have other features in common, like closures for example. There may well be other features we will build into the Java runtime to support such features better like tail call recursions, continuations and lightweight method handles. But we'll see how it goes with new bytecode and get some real data and decide how much further we need to go.

If, say, Ruby, Python and Scala run faster on the JVM than anywhere else, we may just be done. For now :)

Friday May 16, 2008

Top 10 JavaOne 2008 Rich Client things

Here's my top 10 list from Java on the client at JavaOne this year. Enjoy x 10 !

Top 10
What is it ?
Know more...
The JavaFX SDK is (almost) here !
Hot demos (there were quite a few) and a cool new website are all good, but signing up for the SDK to get it next month or so is going to be awesome. Its built with Java, built on Java. Its built in Java.
JavaFX can run Did I mention its fast ?
JDK 6 is everywhere
JDK bundled with Linux, JDK 6 for Mac
On stage, I mentioned that the JDK, from the OpenJDK JDK6 project, is bundled with the latest release of the Ubuntu distro. Since then, its started shipping inside Red Hat's Fedora 9, and Red Hat's Enterprise Lunix too. Who's next ?
And, have you tried the JDK 6 release for OS-X yet ?
The Consumer JRE
Get the latest beta of JRE 6u10, its quick, quick, quick. Quick to download, quick to install, quick to start applets.
Applets that you can pull out of the web page. Applets that can live beyond the browser and drop onto the desktop. Applets that developers can write in Java or designers can write in JavaFX Script. See and believe that applets are back.
Get the release candidate of THE single cockpit for watching, diagnosing and tuning Java applications. If you thought JConsole was cool, you need to check VisualVM out. It integrates all the management and profiling tools for Sun's JDK into a graphical environment. See it for yourself.

On2 Media and JavaFX
Cross screen video, cross device sound.
Finally, one rich media format you can depend on that spans all the devices you own. Because it'll be built into JavaFX.
JavaFX Tools
First views of new tooling.
You've had the NetBeans support for nearly a year for JavaFX Script - and Eclipse support for that matter - but we previewed a new tool called JavaFX Distiller (see here: jump to minute 14). If you've ever written a GUI, and needed a little artistic help from a visual designer, this is one you need to know about.
Making better looking applications easier on today's Java ME devices.
This is a new open source community project in early access to add some portable fit and finish to your MIDP 2.0 applications. Shrinking some of the familar core pieces of the Swing framework, all you need is the NetBean Mobility pack to get started with it.
Java SE 7 sightings
Modularity, OSGi and turbo charging multiple languages I talked with Bob about some of the pieces we'd like to include in Java SE 7 that are progressing well. Here also are my session slides with more detail. In particular, the Java Module System, and its support for OSGi in JDK 7 (which is gaining some encouraging support) and the DaVinci project for accelerating multiple language support which has started producing prototypes.
BluRay, Java and Neil Young
Java as foundation for HD content.
In January, BluRay emerged as the winner of the biggest format war for a generation. So just in case you didn't know BD-J, the programming model for interactive BluRay content (so its on all the BluRay players), is based on Java ME (Personal Basis Profile, to be precise), and Neil Young announced he's releasing his full catalog on BluRay, using BD-J to provide all the interactivity.
Java SE Performance
Latest high performance release of Java SE
Its tuned for the racetrack and breaking records !

Wednesday May 30, 2007

Souvenirs from JavaOne 2007

In the wake of JavaOne 2007, here are a couple of souvenirs for those of you who could not make it. As promised, here are my slides for my presentation on Java SE Present and Future, and here is a picture of my Java SE: Ask the Experts BOF.

From left to right: Chet Haase, Lance Anderson, Mark Reinhold, Stanley Ho, Paul Hohensee, Dave Dagastine, Alan Bateman, Andreas Sterbenz and Danny Coward.

My favorite souvenir was the dark horse announcement I made about the Consumer JRE and how it got picked up all over the place.

Thursday Dec 07, 2006

Java SE 7 Caught on Camera

What with open sourcing the JDK and all, our early head start on Java SE 7 planning has slowed from a run to a trot. Not to worry, every thoroughbred needs to catch its breath between races, with Java SE 6 only on the verge of completion. And there are good signs we can get the Java SE 7 planning team here at Sun to pick up steam again in the New Year.

But in the meantime, I've continued to update our current thinking since last time I blogged about Java SE 7 on where we would like to take the next version of the platform, and what we will be proposing to the JCP. Since I'm now in the video age (I'm sure you saw my debut), what better way than get the update than to watch me talking about it at the infamous Czech Java Users Group in Prague last month.

Java SE 7 Update
For those of you watching the video, I start talking at the 50 minute mark. Rob Harwood fom JetBrains kicks off with a talk on an interesting use of annotations in IntelliJ IDE, and there are various celeb sightings of my techno-buddy Roumen in there too.

<script type="text/javascript" language="javascript"> var sc_project=2104203; var sc_invisible=1; var sc_partition=19; var sc_security="c1ba06ab"; </script> <script type="text/javascript" language="javascript" src=""></script>

Friday Sep 22, 2006

Channeling Java SE 7

Its time for an update on where we're at with Java SE 7. Marketing would probably call this kind of early view into product planning part of a 'rolling thunder' campaign; its really just my inability to keep a secret.

Think of any interaction Sun has with people who care about Java. i.e. a massive number of conversations, comments, emails, RFEs, bugs, articles, presentations at conferences to/with/from developers/Sun customers/JCP members/my dad all being forced into a massive funnel. Otherwise known as the Java SE 7 Planning Team (with guidance from some stellar members). The first thing to pop out the other end of the funnel when we have pushed long enough on the thick end is the platform JSR. Here's the Java SE 6 one, for example, which happens to be finishing its public review. The platform JSR gives the first concrete indication of what we'd like the APIs of Java SE 7 to look like.

So we generally try to identify themes for the release, and highlight the larger API changes and additions I'll be proposing to the Java SE 7 expert group as the Java SE 7 specification lead. These of course are JSRs themselves. And many of them are of course, the larger pieces of engineering and design work in Java SE that we're helping make successful, by putting our smartest people on them. All based on all the input to our planning processes. Phew, full circle !

As we move out of the funnel (into another) I'll write about some of the non-JSR features that are high on our list too. And don't forget you'll see our implementation evolve at as we get going. But its a bit early for that, so for now here are the JSRs that are high on our list for consideration.

Things to do with modularity

JSR 277 - JavaTM Module System This is the specification of 'son of JAR' i.e. a new distribution and deployment format for Java code. I keep calling them superJARs, but it hasn't caught on as nickname yet.
JSR 294 - Improved Modularity Support in the JavaTM Programming Language This is an addition to the Java language for 'superpackages'. That is, fine graned control over the visibility of APIs in packages.
Supporting other languages
JSR 292 - Supporting Dynamically Typed Languages on the JavaTM Platform This aims to add a new bytecode to instruct the JVM to make a method invocation where the return and parameter types are not known until runtime. The Java language doesn't need this, but interpreters for dynamic languages like Python and Ruby do.
Including some dynamic language engines
By the time Java SE 7 is close to shipping in 2008, we'd expect a number of good quality engines that support other languages, other than the Javascript one we put in Java SE 6. Like JRuby, Jython or Beanshell for example. Ensuring they work really well, maybe out of the box, in Java SE 7 is looking attractive.
Thins that ease Swing App Development

JSR 295 - Beans Binding Scott's expert group is aiming to make hooking up one bean to another to keep them in sync really easy.
JSR 296 - Swing Application Framework Hans' expert group is going to take the drudgery out of Swing application development by putting all those pieces of code that pop up repetitively in every Swing application into one framework.
JSR 303 - Bean Validation Jason's expert group has just started out on this, but it could be a really useful way for developers to define easily the validation they want to have happen when binding beans with the Beans Binding APIs.
Language Changes
We haven't finalised these yet !
We'll be bringing a small set of specific Java language proposals into Java SE 7. More on this below.
Things that I can't tie a neat ribbon around yet

JSR 220 Java Persistence Architecture
The Java Persistence APIs that were developed in the EJB expert group look like a promising candidate for Java SE 7. With the ease of development API work for Swing, together with this, writing desktop applications with a database backend could be dramatically easier to do.
JSR 260 JavadocTM Tag Technology Update Our Java API documentation is SO nineties. Enough said.
JSR 255 - JMX 2.0
& JSR 262 - Web Services Connector for JavaTM Management Extensions (JMXTM) Agents
Eamonn's two expert groups are making an update to the JMX programming model for instrumenting Java applications with management agents, and a Java API expression of the web services standard for managing these agents with standard tools.
JSR 203 More New I/O APIs for the JavaTM Platform ("NIO.2") Alan's expert group is defining a much requested new filesystem API, and a true asychronous IO API. Look out for an Early Access Draft soon.

Of course there are many requests and proposals to make smaller update existing APIs in addition to these.

Language Debates

I'm close in fact to having enough to write up the platform JSR for Java SE 7, except really for finalising the set of language changes we would like to include. Language changes are special because they can be powerful and popular - as the humble foreach addition in JavaSE 5.0 has proven, but finalising the set is tricky. Tricky not to trick out, so to speak.

I know which one I prefer\*

Of course each language addition has to be in itself useful - and the current debates around closures, simple closures and the like, shows the difficulty in concluding on some of those even for Click and Hack. But we will be keeping sight of the language as a whole and ensure that we are sticking to its principles, and not ratcheting up its gravitational mass by adding too many new features and turning into Steelian Black Hole. In no particular order, language level XML support, closures, block constructs, strings in switch statements, language support for BigDecimal, Java property support, lightweight method references, extensions to the annotation mechanisms are the leading candidates.

I don't know about you, but I want to remain employable for many years to come.

\*Updated: Thanks to David for pointing out that as beautiful as is the styling of a Ferrari (the original image I put on the left), its gas mileage ain't winning beauty contests. Unlike the Tesla I replaced it with.

<script type="text/javascript" language="javascript"> var sc_project=1902652; var sc_invisible=1; var sc_partition=17; var sc_security="42b01f0b"; </script> <script type="text/javascript" language="javascript" src=""></script>



« July 2016