Friday, April 11th, 2008

Java Plugin: The Kernel is back

Category: Java

Ethan Nicholas of Sun has posted an article on Java 6 update 10 which just came out in beta to play.

For Java folk there are some huge wins, and for the first time in ages the Java applet has huge changes. If Java Applets can get past the sniggering baggage, there is actually interesting things to see there.

What was the pain again?

Once a Java program is up and running, it’s generally smooth sailing.
Modern Java Runtime Environments (JREs) are stable, reliable, and fast.

Unfortunately, getting to the “up and running” part has historically been
more difficult than it should be. Challenges have included:

  • Difficult to detect JREs, especially from a web browser
  • Difficult to automatically install new JREs
  • Large download size
  • Poor cold start performance
  • Little overlap between applets and Web Start programs

Java 6u10 was created as a response to these challenges. By carefully
avoiding public API changes, we can get the fixes into your hands sooner —
no need to wait for Java 7!

And the solutions?

Java Kernel

Java Kernel is a new distribution aimed at getting Java software up and running faster. Instead of a full JRE, users download a small installer (the “kernel”) which includes the most commonly needed JRE components. Additional components are downloaded as needed, and the JRE will download remaining components in the background and then reassemble itself.

In the current build, the typical download size for Swing programs and Java applets is on the order of 4-5MB, compared to 14.4MB for the full JRE.

Next-Generation Java Plug-In

Java 6u10 includes a brand-new implementation of the Java Plug-in, which is
used by default as long as you are using Firefox 3 or Internet Explorer. The
next-generation plug-in runs applets outside of the browser in one or more
separate processes. Applets still appear inside of the web browser window as
they always have, but this means that it is now possible to use different JRE
versions, command-line arguments, and configurations to run different applets.
The isolation provided by running the web browser and the JRE — two very large,
very complex pieces of software — in separate process spaces improves the
reliability of both, and gives applets the same flexibility and control over JRE
configurations that other Java software has always enjoyed.

Since applets now feature the same powerful JRE selection and configuration
that Java Web Start programs do, it was only natural to use the same mechanism
for both. The Java Plug-In now supports using Java
Network Launching Protocol
(JNLP) files to specify applet configuration and
startup options. With very little additional work, you can now deploy the same
program as both an applet and a Web Start program, and still take advantage of
JNLP services such as PersistanceService and

FileSaveService.

New Plug-In Advantages:

  • Improved reliability
  • Improved JavaScript communication
  • Per-applet control of JRE command-line arguments
  • Per-applet control of JRE memory settings, larger maximum heaps
  • JNLP support
  • Per-applet JRE version selection
  • Improved Vista support

Much more information about the new plug-in can be found in the release notes.

Java Deployment Toolkit

The Java Deployment Toolkit makes deploying Java applets or Java Web Start
programs a snap. The
Deployment
Toolkit JavaScript file
provides:

  • Accurate detection of installed JREs
  • Seamless JRE installation
  • Complete applet launching (JRE detection and, if necessary, upgrading)
    in a single line of code
  • Complete Web Start program launching in a single line of code

The following HTML code is all it takes to ensure that Java 1.6 is installed and
then a Java applet is launched:

javascript

  1. <script src="http://java.com/js/deployJava.js"></script>
  2.    
  3. <script>
  4.   deployJava.runApplet({codebase:"http://www.example.com/applets/",
  5.      archive:"ExampleApplet.jar", code:"Main.class",
  6.      width:"320", Height:"400"}, null, "1.6");
  7. </script>

Also note, that with this version you can take a running Applet in the browser, pull it OUT of the page, close the browser, and see the applet still running (since it runs in a different process). This is very cool indeed.

Add to all of this the easy bridge between Java and JavaScript, and there are interesting opportunities.

Posted by Dion Almaer at 12:32 pm
16 Comments

++++-
4.3 rating from 38 votes

16 Comments »

Comments feed TrackBack URI

In general, this is a VERY welcome improvement that has been a LONG time coming, like 12 years overdue. If Sun had not bumbled this so much and spent so much effort on enterprise Java and selling E10000’s during the dot.com bust :), perhaps the Java Plugin + Common DOM API could have been what Flash/Flex is today.

Maybe they’ll be able to get back some lost ground over a long time, but at this point, they’re starting at the same position and Silverlight, when compared to Flash. Which is a shame, because Java2D blows away Flash’s drawing API, and JavaGL would rock in the browser.

That said, I’m still happy they’re doing this, but here’s my concern:
1) No Safari/Webkit support
2) What of OSX? Sun is still delegating responsibility for a JRE to Apple, and given the sloth-like speed of Apple JRE releases, it’s likely Java8 will be out before Apple can release a JRE u10 compatible release. Now, Apple doesn’t have a need of the Java Kernel, since they will just pre-load it via an update on everyone’s machine, but there is still the need of a OSX Safari plugin that is feature-for-feature compatible with the new Plugin API.

Comment by cromwellian — April 11, 2008

Even though I’m not a Java fan, there are some great improvements to applets. The on demand and running the applets outside of the browser is a big improvement (who knows, maybe people will start using applets again).

One thing makes me laugh though: “Modern Java Runtime Environments (JREs) are stable, reliable, and fast.” Java is pretty slow running on Windows, I’d like to read their requirement metrics on performance ;-).

Comment by posure — April 11, 2008

I am excited about the updates to Java. At Nexaweb, where I have worked for the last 5 years. We set on a mission to build a platform, which developers could use to create the biggest and most impressive applications deployed in a web browser.

The list of things mentioned above, which this version of Java will fix combined with the improvements that Nexaweb made to the experience of developing Java client application –
http://dev.nexaweb.com/blogs/nexablog/?p=9
– makes Java a viable second options for applications after Ajax.

The one thing I would like to see from Sun; build a community of people that want to see Java client’s succeed. If Sun tries to go it alone with JavaFX as the only choice it will fail to catch on.

One of the things about Ajax I like is there are many options that I can choose from. If this is to work they need the dojo’s, jQuerys and Mootools of the Java client world.

Comment by digitalIchi — April 11, 2008

@posure,
On numerically intense code, Java is pretty fast. Your perception of slowness is most likely related to subjective UI responsiveness, which is in turn related to issues surrounding startup, file-system warming, and the labyrithine ways that events are propagated to, and hanged by Swing. SWT apps are must snappier, yet run on the same JRE.

Do you think that Flash or Javascript, or Python, or TCL executes faster than Java? They are orders of magnitude slower, but the UI code is native and tuned to respond fast, thus the impression of speed.

They’ve done alot of work in 1.6 to streamline the UI problems, for example, how Java2D calls get pipelined to DirectX or OpenGL. Java’s unfortunate bane has always been it’s little understood performance issues, wherein non-GUI code has smoking performance, but enduser facing code is often perceived as laggy.

Comment by cromwellian — April 11, 2008

I’ve already been playing around with the Java Kernel and the improved Common DOM API and I’m impressed. If we don’t have to pull Swing down the wire, but can use Java (or JRuby as in a very cool demo Dion made awhile back) to “script” the HTML page it might be pretty cool.

Brad Neuberg

Comment by BradNeuberg — April 11, 2008

Would be nice if “deployJava.js” was packed/minified.

Comment by Jordan — April 12, 2008

@cromwellion: the UI’s in flash, javascript and so on are no more native than java’s. And while I don’t doubt that java is great at numerical processing, this simply is not that relevant to the desktop. What matters on the desktop is perception of speed, and responsiveness is a way more important component of that than throughput.

Comment by Joeri — April 12, 2008

@Joeri,
That’s just not true. Flash and Javascript rely on retained-mode/scenegraph rendering, Java relies on immediate mode rendering. In Swing, when a repaint needs to occur, or hit detection needs to run, Java has to walk the UI graph issuing low-level Java2D calls, which are then translated into native calls. In Flash or Javascript, if a redraw needs to occur, Display objects or the Document are rerendered with no intervention from Javascript. Think about what happens when foo.innerHTML is assigned, a massive amount of native processing and rendering occurs, from one line of Javascript. Likewise, with hit detection, Javascript does little to no work, whereas Java Swing has to do all of the computation in Java.

Let’s flip this around and look at an area where Flash lacks native acceleration, so it competes with Java on equal footing: 3D rendering. Papervision 3D has to do alot of work just to produce an inaccurate rasterization of an small amount of texture polygons. Likewise, Java, without Java3D/JavaGL, performing the same workload as Papervision 3D, doing rasterization in pure Java with just image filled polygons, would stomp all over it by a factor of 50x in performance.

Flash has an awesomely tuned (but limited, just look at Porter-Duff modes, font-rendering, bitmapdata vs bufferedimage, etc) vector engine that allows scripting from Javascript, but performance is mostly derived from the native. Java is handicapped by trying to be too cross-platform with as little native code as possible. Couple the Flash vector engine to Java and it would scream too.

Comment by cromwellian — April 12, 2008

I don’t give much merit to sun’s claim “write once, deploy everywhere” – that has not historically held up. platform independence is harder than most java programmers are prepared to admit.
java does well in the programming shootouts, because it has close to native CPU performance, but the JVM takes up much more memory than other languages like flash and javascript, which is important for GUI applications.
I’ve seen some very fast java programs (xalan and nutch for example), but most GUI apps are dog slow (eclipse, you name it).

Comment by grumpytoad — April 12, 2008

The “write once, deploy everywhere” was as much an overstatement as “Mission Accomplished”, but nothing has been created that can run anywhere without some trouble.

Take Ajax as an example; if it wasn’t for the libraries that handle browser compatibilities writing an application that ran everywhere would be difficult.

Using Eclipse as an example of Java’s GUI speed problem is somewhat misleading. Eclipse has millions of lines of code and interfaces to native widgets, I am not sure either Flash or JavaScript has been used to create an application the scale of a Eclipse.

Comment by digitalIchi — April 12, 2008

“but the JVM takes up much more memory than other languages like flash and javascript, which is important for GUI applications.”

And how are you measuring this? Any non-trivial Javascript RIA app running in a web browser like IE or Firefox will easily consume over 200mb of memory, and once it starts leaking memory (as a large chunk of AJAX apps do), that climbs easily to 500mb.

If memory usage is to be the measuring stick, JS for GUI in the Browser fails miserably. To get a very simple application up and running in AJAX, my Firefox will typically consume more memory than an instance of IntelliJ IDEA or Eclipse with a 1,000 + file project loaded.

I routinely develop using Java IDEs on large code bases and when I look at system memory consumption, Firefox is always larger. JS doesn’t even win on codesize. I routinely see packed minified RIA JS apps sending down larger amounts of code than equivalent Java GUIs, think a Java version of ExtJS’s demos would be larger?

RIA AJAX browser apps win IMHO on startup time and ease of development, not on runtime speed or memory efficiency. Flash is memory efficient only insofar as you stay away from DHTML. (I’m not discussing language syntax, I am not fan of Java’s language syntax, I’m talking about maturity and efficiency of execution)

Comment by cromwellian — April 12, 2008

@cromwellian
You may well be right about Java’s performance being better than the UI seems, but when Eclipse is running so slow that it ruins my productivity when other IDE’s have no problem (Visual Studio is lightning fast) – its hard not to point the blame towards Java. Maybe Eclipse is just badly designed software, who knows (but I don’t think that’s the case). Eclipse + JVM hits around 400mb for the projects I load (along with eating quite a bit of CPU). Firefox isn’t really a good example for memory usage, its such a leak heavy app that I never leave it open for more than a day. However, Opera has been open for about two weeks and is still under 100mb. Also, I don’t know why you’re comparing Java to JavaScript, they’re not intended for the same purposes.

Comment by posure — April 14, 2008

Well, to some extent, I would not expect VS to run slower than Java, because VS is not garbage collected, and IDEs tend to have large amounts of heap representing parse trees and type databases, and each time a new file is opened, you end up having more tenured heap space allocated, and GCs in the tenured heap can seriously effect UI responsiveness if you don’t tune the JVM parameters.

Moreover, in my experience, VS does alot less work than IDEA or Eclipse when it comes to maintaining a synchronized view of your entire project, as the latter build and whole massive indexes of the project, every class, every method, every identifier, every type, to provide fast navigation, usage-finding, search, on-the-fly code analysis, and refactoring. You need something like Resharper in VS to even begin to approach what Eclipse and IDEA offer. IDEA for example is running like 500 code inspections every time you type something, and Eclipse is recompiling your code constantly. Maybe if someone implements an IDE as simple as VS in Java (jEdit?) we can have a more accurate comparison.

As to why I compared Java to Javascript, another user Joeri brought it up. The point is, Java execution at lighting fast, the idea that it’s slow is a myth, benchmarks bare this out. Java gives a bad end user impression because of a) slow install time b) slow startup time and c) a UI library that suffers from “overdesign”. The Java6 update is trying to solve a) and b). c) isn’t going to be solved anytime soon.

Comment by cromwellian — April 14, 2008

The neverending language comparisons are as old as programming itself, and are more a matter of personal choice, than hard facts it seems. Equally so the rants about java’s slowness.
I’m excited at these news as it means that my expertise in java, coming mainly from enterprise applications, can also be applied on the user front should the java kernel really succeed ^^

Comment by Snyke — April 14, 2008

It is a well known problem that applets do not obey the proper z-ordering of HTML elements in the browser. The root cause is that applets are a heavyweight OS-level component and inherently overlay all content underneath them. Flash content can specify wmode=”transparent” to attain proper z-ordering support, though there is a performance penalty for doing so. The new Java Plug-In should support a similar parameter though again there might be a performance penalty for doing so.

Does anyone know if this problem is fixed? It is a real showstopper in using Java applets with Ajax.

Comment by pugmaster — April 16, 2008

I’m surprised how little attention architecture gets when comparing performance between platforms. JS and Flash force asynchronous APIs, which best suits UIs. Swing is default synchronous, which makes it easy for “unbounded” code to slip and insidiously chug the UI. I think it’s fair to say that the APIs of JS and Flash are better architected for responsive UIs. However, in the space of computing, I think Java is a far superior platform. I’m curious what programs people think are good examples of Flash or JS applications …

Two years from now I think people will realize how superior OGL is for 2d graphics than anything else available. If you compare what can be done in Processing versus Flash for example, you’ll see the difference.

While I think it’s ridiculous to compare implementations instead of architectures, I think it’s important to note that VS (2005 is my reference) is not as powerful as Eclipse. I also think the latest Eclipse made some (innovative) performance mistakes in their refactoring and template UIs, using linked text areas.

I guess what I’m trying to say nothing else comes close to what’s been happening on the Java platform, and I hope it continues.

Comment by xcolwell — May 18, 2008

Leave a comment

You must be logged in to post a comment.