Wednesday August 27, 2008
Firing up the engines for multiple languages
Filed under: javafx javase7
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 :)
Posted by dannycoward ( Aug 27 2008, 02:38:21 PM PDT ) Permalink Comments [5]
Friday May 16, 2008
Top 10 JavaOne 2008 Rich Client things
Filed under: consumerjre javafx javame javaone javase7
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... |
| JavaFX
SDK |
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 parleys.com. 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. |
| VisualVM |
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. |
| Java
ME LWUIT |
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 ! |
Posted by dannycoward ( May 16 2008, 03:23:28 PM PDT ) Permalink Comments [15]
Wednesday May 30, 2007
Souvenirs from JavaOne 2007
Filed under: javafx javaone javase7 postcards
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.
Posted by dannycoward ( May 30 2007, 12:07:25 PM PDT ) Permalink Comments [3]
Thursday December 07, 2006
Java SE 7 Caught on Camera
Filed under: javase7
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
- Slides
- Video (WMV - sigh, I know...)
Friday September 22, 2006
Channeling Java SE 7
Filed under: javase7
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 jdk7.dev.java.net 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.
