The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
Sun's Danny Coward on the Latest Java Update

9 replies on 1 page. Most recent reply: Oct 24, 2008 2:17 PM by Mark Thornton

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 9 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Sun's Danny Coward on the Latest Java Update Posted: Oct 22, 2008 4:56 PM
Reply to this message Reply
Advertisement

Available for some time in various beta releases, Sun released this week a final version of Java SE Update 10, a desktop-focused version of the Java SE runtime.

In this interview with Artima, Danny Coward, chief architect of Java SE and Sun's Java Runtime, discusses the key new features in the latest Java update:

This is an update to the Java runtime environment on the desktop. The driving factor around this [update] is to make the runtime better-suited for rich Internet applications. We've spent many years building out the [Java] platform for enterprise development: Java SE is the basis for the Java EE technologies, and also for more traditional-looking Swing GUI applications on the desktop.

Over the last few years, the amount of rich-client content has started to eclipse the amount of enterprise content around the world. It was time for us to look into how we could make the runtime for the desktop much lighter-weight, quicker to download, quicker to start, and something that would make the content more modern looking. Those are the main desires that formed the basis of Java 6 Update 10.

The starting point for these changes is when consumers first download and install the JRE. We have a technology, Java Kernel, that streamlines and speeds up the download and install process. As we've added more and more features to Java SE over the years, the runtime has become bigger and bigger, until it has gotten up to about 14.5MB [in download size]. Even over a reasonable Internet connection, that's a noticeable download. In addition to download, unpacking that amount of code takes a significant time as well.

With Java Kernel, we've slimmed down that initial download from 14.5MB to about 4.5MB. In the Java Kernel, you have a stripped-down Java VM, with just the barebones features you need to run simple Java code, and just enough of the core APIs in Java SE to run a Swing application. Our judgement was that most consumer applications are Swing-based applications, and there are lots of features in the Java SE platform they don't typically use, such as CORBA or RMI. So this initial download allows a Swing application to start up really quickly, and then, in parallel, the rest of the platform is lazily downloaded. By the end of the process, you'll have the whole JRE, but that first piece installs much faster and starts up much quicker.

Another area that the JRE had fallen behind in terms of running consumer content is Java QuickStarter. It's all about starting applets and applications very quickly. When we analyzed why some applets took many seconds to start, most of the time was spent touching the files of the JRE, and moving them into the disk cache. Now we preemptively do that so the files are ready and, as a result, applets start in a much more reasonable time. Obviously, the actual time an applet takes to start depends on the applet, but most consumer-focused applets we tested are in the sub-2-second start-up range, which is acceptable for consumer content.

Next, we made modifications to the Java Plug-in architecture. This is the software that integrates the JRE within the browser, and it's responsible for starting up the JRE, starting up the applet, and for the all communication between an applet and a Web page. Prior to this release, the plug-in and applets ran in the same process as the browser. That was fine, but it if you had a rouge applet that consumed a lot of memory, that affected the browser's performance. Or, if you had an applet that had to do some very intensive work at start-up, users were not able to use the browser while that was going on because the applet consumed all the resources of the browser.

With the new plug-in architecture, the process that runs the new plug-in spawns off a new JVM process to run the applet. As a result, the browser is running in one process, and the applet is running in another process. This is a much more robust and scaleable architecture for running applets in a Web page.

The new Java Plug-in architecture allows some neat deployment tricks. If you navigate to a Web page with an applet in it, you can invite the consumer to drag that applet out of the Web page, and onto the desktop. The applet is then a free-floating window on the desktop, and still continues to run even as you're dragging it out of the Web page. Because it's running in a separate process, you can shut down the browser, and the applet keeps running. If you then close the applet, you'll be prompted with a choice of whether you want to install the applet onto the desktop. So the next time you want to run the applet, you don't need the browser at all. This enables developers to stick an applet in a Web page, and if consumers like that applet, they can just pull the applet onto their desktop and use it again later, without even having to be connected to the Internet. This is something other rich-client technologies can't do at the moment.

The new plug-in also eliminates lots of the differences between applets and desktop Java applications. Applications that are deployed via JNLP had access to JNLP-specific APIs and JNLP services. Now these APIs are also available to Java applets as well, because we have a common deployment infrastructure. Applets can also see all the SE APIs that desktop applications have access to.

Obviously, applet lifecycles are unique to applets, such as init(), start(), stop(), and destroy(), that's different for a desktop application. Applets also have access to the Web page in which they are embedded in: using the DOM API, they can interrogate their surroundings, which is a Web page. When an applet is dragged onto the desktop and installed as a local application, the JNLP framework still supports the applet lifecycle. But that applet no longer has access to a Web page environment, since the applet is no longer running in a Web page.

The final piece is that we made existing Java applets and applications look better. We did that in two ways. On Windows Vista, instead of rendering the 2D graphics in the Java layer, which works fine, but is an extra layer on top of the OS, we now render those graphics natively, using the DirectD API, which is part of Vista. For applications that heavily use animations, translucency, and shading, rotations, all those features that are becoming much more common, they're all done natively. Consequently, the rendering is much quicker, and much smoother than you could ever achieve by rendering it at a higher level in the stack.

Many developers when they create a client application, that want that application to look as if it's a native application. We've worked hard over the years to make sure that Java applications have kept up-to-date with the look-and-feels of the native OSs. But there are also developers who like to develop an application that has a characteristic look which is the same regardless of the platform you're running it on. We've had the Swing Metal cross-platform look-and-feel, but it was time for an update. We we've added a new look-and-feel called Nimbus, which is rendered using vector-scalable graphics. That means that Nimbus looks great at any magnification, and is infinitely scalable. It also helps keep the Nimbus very small—it's only about 56KB.

These technologies are currently available only on Windows. We have to decide where to allocate our priorities, and what we see is that the majority of consumers are on the Windows platform, because that's by far the pre-dominant platform. In the OpenJDK project, there are people who ported these features to other, more niche platforms. As well, Apple has now completed its support for Java SE 6 on the Mac platform. I'm not sure what of these new features will eventually become available on the Mac, but some may eventually be. Of course, Apple does its own work to accelerate graphics on OS X, including graphics for Java applications, and we work very closely with them.

What do you think of Sun's latest Java update?


James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 22, 2008 5:25 PM
Reply to this message Reply
Does this update provide support for heavyweight components in JInternalFrames? I'm waiting anxiously for this feature.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 23, 2008 10:46 AM
Reply to this message Reply
> We've had the Swing Metal cross-platform look-and-feel,
> but <i>it was time for an update</i>.

This is a new Java feature: the understatement.

> As well, Apple has now completed its
> support for Java SE 6 on the Mac platform. I'm not sure
> what of these new features will eventually become
> available on the Mac, but some may eventually be.

Oh look, another one already! :)

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 23, 2008 3:35 PM
Reply to this message Reply
> Does this update provide support for heavyweight
> components in JInternalFrames? I'm waiting anxiously for
> this feature.

That is in J7(b19), but not in J6_10 as far as I can see.
Bug 4811096.

Mike K

Posts: 2
Nickname: mkorcy
Registered: Jul, 2008

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 23, 2008 5:34 PM
Reply to this message Reply
"As well, Apple has now completed its support for Java SE 6 on the Mac platform. I'm not sure what of these new features will eventually become available on the Mac, but some may eventually be."

Wow, this is really disappointing. The MRJ is a disaster, Mac OSX *must* support these features in order for applets to be viable, you can't have a web application that only runs on windows. Things are already confusing enough, these new features HAVE to make it the Mac for this release to be successful, saying that they may eventually get there really worries me. Who should applet developers be contacting at Apple to push for these features to be added, or to push for a better java plugin?

Also, this post left out one of my favorite new features the PACK200 compression without server side components.

Finally, are there any tips for deploying large complicated applets to minimize start time, is a one jar model better or having multiple jars staged with enough classes to get your app going faster, a better approach?

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 23, 2008 7:01 PM
Reply to this message Reply
> Wow, this is really disappointing. The MRJ is a disaster,
> Mac OSX *must* support these features in order for applets
> to be viable, you can't have a web application that only
> runs on windows. Things are already confusing enough,
> these new features HAVE to make it the Mac for this
> release to be successful, saying that they may eventually
> get there really worries me. Who should applet developers
> be contacting at Apple to push for these features to be
> added, or to push for a better java plugin?

Well, there has probably been more *consistent* support for Java on the Mac than on other platforms for quite some time now. You certainly don't have to worry about updating or installing the JRE, since every copy of OS X already has JRE 6 now. For that reason, visiting Web pages with applets is probably a more pleasant experience on the Mac than on other platforms. I use OS X and Windows XP/Vista, and have used Solaris and Linux a lot in the past 10 years or so, and the applet experience, by and large, has been the best on OS X.

If you need truly cross-platform support for any kind of feature, than Flex may be a better choice than applets, because Adobe does put a lot of effort into making sure the Flash VM works pretty much the same on many platforms. (But even there, there are platform-specific differences.)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 23, 2008 9:19 PM
Reply to this message Reply
> > Does this update provide support for heavyweight
> > components in JInternalFrames? I'm waiting anxiously
> for
> > this feature.
>
> That is in J7(b19), but not in J6_10 as far as I can see.
> Bug 4811096.

Thanks.

Javier Diaz Soto

Posts: 29
Nickname: javierbds
Registered: Sep, 2005

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 24, 2008 2:10 AM
Reply to this message Reply
What about plug-in and WebStart for 64 bits? It is for Java 7 too?

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 24, 2008 3:32 AM
Reply to this message Reply
The 64 bit plug in and WebStart are expected in a future update of Java 6. Something like update 12 I seem to remember (I would have checked except the forums are down).

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Sun's Danny Coward on the Latest Java Update Posted: Oct 24, 2008 2:17 PM
Reply to this message Reply
"Yes, the 64-bit plugin will be available before JDK7, in an JDK6 update release, sometime after 6u11 and before JDK7"

From http://forums.java.net/jive/thread.jspa?threadID=48543&tstart=0

Flat View: This topic has 9 replies on 1 page
Topic: Python Decorators III: A Decorator-Based Build System Previous Topic   Next Topic Topic: The Adventures of a Pythonista in Schemeland, Part 7


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us