We are here at InfoQ with Chet Haase. Chet, could you tell us a bit about yourself and what you are up to

I was born in Georgia... I am a client architect in the Java Desktop group, which means that I am one of the leads in charge of all the technologies that get the Java client onto the desktop machine and run it. That's the deployment technologies for downloading and installing, and launching and running the plugin. It's also the Swing and AWT technologies for the components, the GUI toolkit functionality as well as the Java2D technologies for actually rendering -- so when Swing draws a button it's actually using the Java2D libraries to do that rendering -- as well as the internationalization technology. So I am a graphics person myself, I come from the graphics arena, originally Java2D in this group, but I am focused on the overall client technologies, where are they and where they need to go.

I'm just throwing this out there, you don't have to answer it. Where did we go wrong initially with Java on the desktop and what do we doing about it?

Wrong? We didn't go wrong at all! It depends on what your focus is, right? So, originally we had applets out there very early on and it was very cool. It was executable content in the browser for the first time and people were very jazzed about it. Sun's focus has always been more on the back-end, this is where we sell servers, we're friends with the IT shops and we think more about how to enable enterprise customers. And so, the focus of client Java shifted over time early on to be more about enterprise development, development of IDEs, development of intranet applications, development of large applications for solving business problems and the dynamics in that part of the market are quite different from the dynamics in the consumer side. So if you view Java from a consumer orientation instead and think of "can I write a media player in it?" or "how do I write this whizzy Facebook thing?" Java is not necessarily a player in that market anymore because that really wasn't where the focus of development was in the last several years. So I wouldn't say "where did we go wrong?", but "where was our focus?" And our focus tended to be on enterprise development instead of client and consumer focus. We have shifted that focus now and said "well, actually consumers matter a great deal". For one thing there is a follow-on adoption of features that are critical for consumer applications now, will be critical for enterprise development later. Maybe enterprises don't care about video today, but you know what? They use it at home all the time, they are probably going to start to integrate it into their applications at work eventually as well. And there's other things like animation, it sounds really cool and whizzy but it's not just about cool graphics, it's about enabling better user experiences that make users more productive. Well, that needs to be part of the enterprise solution as well. Even from our traditional perspective we need to get more consumer-friendly. But we are also releasing Java as a platform in the mobile space and we've got new mobile solutions on the way as well as our traditional wonderful ME stuff. The more we focus on consumers, and clients and what we need in that market, the better it's going to be for Java overall. The shift in focus for the upcoming release, the Update N release and the Java FX release, as well as some of the features that we were talking about for Java SE 7.

Can you bring the audience up to date on what is going on now with making Java more of a consumer and desktop platform?

Sure. The most recent thing that has happened in the Java space was the release of Java SE 6 which was December of 2006, lots of very cool desktop features in there, some of my personal favorites. But it was after that or about the time that we released it that we realized we need to have more of a consumer focus and fix some of the issues in the consumer space. The drivers for the Update N release which we are working hard on and should be in beta sometime soon now is mainly in the deployment space. So it's the realization that if we want to be a player in the consumer world, we actually need to fix some of the longstanding issues which we have known about but which frankly weren't that critical in the enterprise space.

For instance, if you go to a browser page, a web page that has an applet embedded in it, you may see a ten to fifteen second pause as that applet starts up, if it's the first time you've run Java on that system. That's totally appropriate for intranet applications where it is going to run all day or applications where this is the thing I need to run I don't really care what the startup metrics are for it. But if it's a casual application that a consumer is just browsing to, they may not put up with that. They might just navigate off that page and go do something else instead. We have got to fix this startup issue. Some of the other deployment issues that are important are the install time: if they don't have Java or if they don't have the right version of Java, then we'd better make sure that they get the right version and get it as seamlessly as possible.

And right now the process and the time involved in actually getting a new version of Java installed means that they may not complete the process or if they do they may not navigate back to your page to actually run the applet or the application that you want them to. And so we are improving a lot of things in that spectrum, the deployment spectrum of making the thing start faster, making the install process more seamless and more speedy as well as detecting Java, making sure that they actually have the right version of Java; or if they don't, help them install it and then launch your application. And then we're also adding some other goodies at the same time, some graphical goodies about speeding up graphics performance on Windows, a new cross platform look-and-feel called Nimbus that should enable a more modern Swing experience. There is also a new plugin architecture for making applets more robust and performant in general, which we are also adding in. So, lots of good stuff specifically in the space of solving longstanding issues for this new space that we are interested in, the consumer-facing space.

How are we going to solve the problems of quicker deployment, faster download time, richer interface? What's the vision for Java 7 in that regard?

There are a couple of specific projects that are meant to address them. The things I called out in particular, where we want to start up quicker. You want an applet that doesn't pause ten to fifteen seconds if it is the first time that it is being run on the system since reboot. Well, we have a project called Quickstarter, which starts up a small process at boot time, which will then page in, it will touch pages on disk and bring them into the disk cache, so that when you run Java some time later, those pages are actually available in the cache and things start much faster because of that.

The real problem with startup is not just that the VM takes a long time to start, and classloading takes a long time, it's simply that there is a lot of data on disk, and disk is a very slow resource, so anything we can do to get the data from the disk into the disk cache of the OS instead, it's going to get our cold-start situation, the first run of Java since reboot, much closer to the warm start, which is just "I want to run Java for a second time" and that stuff just sits in the disk cache and it's much more accessible and speedy to bring in. Some of the other projects going on are the Java Kernel project which is all about making the download and install process much faster. One of the constraints with the JRE that's very important, especially in the world of backward compatibility and dependability of the Java platform, is that the JRE is a single thing.

You can't deliver part of the JRE and say "This is Java" because then what happens if you run an applet that actually needs a part that didn't get delivered. You might think from your Swing perspective "I don't need CORBA". So why don't I just deliver a JRE that doesn't have CORBA? Well what if another applet runs, and runs your flavor of Java and depends upon CORBA? Then it breaks. We deliver one single thing which is the JRE. Well, that JRE happens to be as large as it is and it takes a certain time to download over whatever your bandwidth is and install. And so how can we actually minimize the time when we still have to have this single thing that's the JRE. The Java Kernel is a project to address that. The Java Kernel operates by saying: "Ok, well my application only needs this set of functionality. It only needs Swing and AWT and the core kernel stuff of VM, networking, and security in the classloader".

So, download this stuff first and launch. And it will do that, and it will pack everything up and zip it down and come up with a download that's maybe 30-40% of what you might have otherwise. And it'll get it down onto disk, and you will launch your application and you'll be happily running away and in the meantime the real installer kicked off in the background to stream down the rest of the bits and install everything in the correct location on disk so that a later Java application that starts three minutes later when everything is actually down there, can actually depend upon launching Java with the real bits of everything being available just as it normally would be. And then there's other specific projects in the Update N release, like the deployment toolkit that makes it easier to detect whether a user to your web page has Java and what version of Java they have.

There's a project to re-architect the plugin that's basically a ground-up rewrite of the plugin architecture: going back to this old applet code that has been patched over the years and saying, "Ok, there are some robustness issues we would like to address. We would like Java to Javascript communication to work better. We would also like to be able to launch an applet with different VM versions with different VM arguments." And you can't do that right now, you basically get the VM arguments that were passed into the first instantiation of the applet because it's just in one process. We have a project going on right now to actually create an out-of-process model for applets, so there is one core process that starts up, much faster because it is much smaller, and then it actually spawns a second process to run applets.

Maybe by default they'll run it in the same process, but if they have different command-line parameters, or if they want to run a different JRE version, which is important for enterprises that may be qualified on one JRE version instead of another, then it will actually spawn separate processes for these applets. Much more robust system, this applet can be taken down without actually taking down the browser, other applets and other advantages like signed application behavior is better on Vista because it is not constrained to being within the browser process. So very cool stuff. And then there is some other stuff happening as well. Those are all the big deployment issues that we're solving and at the same time we were making graphics better by enhanced graphics acceleration capabilities on Windows, through using Direct3D by default, and adding a new cross platform look-and-feel called Nimbus.

The features you mention that you're working up to, then, sound like a lot of updates to applet architecture. But how is this leading into, eventually to Java FX and the overall new graphics strategy from Sun?

You can think of the features that we talked about for the Update N release as being infrastructure changes that's required by any consumer platform. So, when we came out with the information about Java FX, and started to focus on the functionality this platform needed, it was clear that, yes it may offer all these neat media capabilities and data binding and fast rapid prototyping stuff but we've got to fix the deployment model or else it still doesn't matter in the consumer space. And so the stuff that we are doing for the Java platform in the Update N release is also clearly about fixing the deployment strategy for Java FX as well.

Ok. Applets, I haven't really heard much talked about applets in a while. That's lead into my question. The actual question is: with these changes is the goal to see resurgence in the use of applets as an RIA framework in the browser, or is this just a transitionary step to deliver the true vision of Java FX?

I think applets will continue to be one of the deployment strategies. I don't think it is going to be the focus, I think it's more that applets were there originally and there are some historical applets out there. In general people use either standalone applications or Web Start to deploy their apps right now. Applets are still a good model; they have some rough edges that we would like to vastly improve through some of the stuff that I was talking about. If people can see applet development as resurged and appropriate for deploying their apps, that's great, there are other deployment models as well. Certainly I would like to see more applets out there; more web pages that you get to have applet in it. Having said that Web Start and standalone Java applications are still viable models that will always be a part of the strategy.

On the notion of the Java Kernel allowing incremental download of Java, give us an example of your typical applet that might do some client-server interaction and use Swing for doing business like forms and such. What kind of a download footprint are we looking at, at start time for such an application?

It would certainly depend on the application; my favorite example is Limewire. We did a simple test where we basically ran Limewire for a couple of minutes so we got all the stuff that happens at start up as well as menu interactions, and stuff that was being lazily loaded in the GUI. Limewire is a graphically-oriented file-sharing application and so it has a lot of Swing functionality for a rich GUI, it also uses XML processing for dealing with data coming in. And it also does a lot of networking transactions and when we printed out the class list of everything that it dragged in from rt.jar as well as all of the native files that it touched, it came out to something under 4 Mb and this was compared to something around 10-11 Mb for the actual full JRE. In this case it was 30-40% to run Limewire for that first couple of minutes compared to getting nearly three times that for the full JRE for a normal install.

And how was the download set for an application determined? I mean how granular can you get? Can you separate classes within packages of the JDK, how streamline really is it?

I think for the first release of this I believe... Java Kernel is one of those things that we can continue to tune as we get more experience and get the basic insfrastructure in there. Right now the mechanism is going to be to use these chunks; we have sort of coarse chunks, not on a package level but sort of on a subject area level, so you can say "I have a dependency upon Swing" and it'll grab Swing. And Swing has a dependency upon AWT so it'll grab that as well. But then it won't grab CORBA, or it won't grab...

Swing is pretty heavy, as a full package too. Can you get more granular than Swing?

Yes it is. So there is certainly advantages of being able to break it down. One of the problems that we have in the Kernel project is that the JRE really wasn't developed with this constraint in mind, which means that it is very easy for a class in one package to have a dependency upon a class in another package, because there really wasn't this programming paradigm of "stick to your class, and we are going to have modularity". I think we need to take another step at it in some future release and say "OK, now can we actually separate things more cleanly and have a more modular JRE so that we can break things down at a finer-grained level?" There is also the possibility of being able to create very custom bundles for applications so Limewire can say "These are the exactly the classes I want, I don't want all of Swing, I want these specific classes in Swing", because they have been able to determine that this is all the classes they are ever going to need at start up. The problem with that is that it is a little hard to get that information because maybe when you did your test run to see what the classes were, you didn't happen to throw an exception which is needed at runtime or maybe you are running on a different Windows system and it actually pulls in a different look and feel. It's kind of hard to statically determine the classes that you need; it's also hard to make a run to dynamically determine them. So I think this is a viable model but we need to think hard about that one. I think it's a little easier to declare these functional chunks that you have requirements of instead.

So in order to take advantage of Java Kernel, what do developers need to do differently, like what artifacts are exposed to them to configure or program?

There is going to be a configuration file that you associate with your application, where you can basically tell the Java Kernel... well you can specify that you want to use the Kernel as the installer for your application, you can tell the Kernel what chunks of functionality you need and that's where you declare the dependencies upon Swing and AWT and the other sort of coarse dependencies, coarse chunks of the JRE. And that's pretty much it and then the Kernel installer takes care of it after that, so it takes that configuration file and creates the download for you that gets streamed down initially, launches your application and then automatically starts the online install of everything else and that just happens under the covers.

What is Sun's vision with Java FX?

Making consumer-oriented applications easier to develop and deploy. One of the things that is interesting about Java FX is that it takes advantage of capabilities that are already in the platform, for the most part. It also adds some nice features on top. But it allows easy creation of applications that have animated components and graphics and easily declared animations, very whizzy, dynamic, involving user experiences. You can do that stuff right now using Swing and Java2D but it is not necessarily obvious how to do that. To do that kind of stuff with Swing you need to be a fairly sophisticated Swing developer. The idea with Java FX script is to make it much easier to create that kind of application so that maybe we can actually see more of these types of applications out there for the Java platform.

You mentioned using a lot of what's in the platform, but technically what are some of the innovations coming that will really change the experience of using Java for the consumer?

There are some new things like data binding. These exist in other platforms and various parts of Java in different ways. We are actually exposing data binding for Swing, in JDK 7 it is one of the features that we have on the list. But the ability in Java FX script to do it very tersely is very attractive. You can basically associate two objects, two variables with each other, just say: "I want to bind their value" so that if one changes, it automatically updates the other. Then you can associate a trigger based on that change which means you'll automatically get a callback when the value changes, and then you can perform some action on it. That's one of the new innovations with FX script that's very powerful. There are other things that are more along the lines of not necessarily new features but exposing existing features in much easier ways, and this involves things like laying out the screen very easily saying "I want my components, my graphics to look like this". And then the system handles rendering it for you. The traditional model with Java2D is called an immediate-mode model, very geeky term for it, where basically you override a method in your Swing application and then, when that method is called, you'll draw the line and you'll copy the image and you'll do all these operations one by one. But an application developer, especially a designer, thinks more in terms of "well, what do I want this screen to look like?" and they don't want to think about "what are the lines of code I have to write in order to render the screen at any point in time". They'd love to just say: "I want a button here, I want a line there, I want this image to be here, and I want to scale this image from here to there over time using the following interpolation semantics" and FX script enables you to do that in a very simple way. You are going to have much more rapid development of applications, rapid prototyping so you can quickly throw stuff up on the screen and see if it's right and then keep tweaking it.

How would you position Java FX compared to Silverlight and Adobe's Flash and Flex and AIR?

I see us as all entering the same arena from different directions. You can have your own spin on it but Microsoft is entering from "well we've always been on a particular platform, we are trying to get into the cross platform space". It's sort of taking .Net into the Silverlight space in that way to be able to access some of that functionality from the browser. Adobe comes from the model where they had a very small renderer that was mainly used for small lightweight graphical applications and now they are building a component model and a deployment strategy on top of it. So now they can get out of the browser and render enterprise applications. In the meantime Java is coming from the space where we actually have the enterprise space nailed, we have a very powerful component and rendering model, and a deployment strategy that can work in or out of the browser, very cross platform. What we don't necessarily have is the consumer angle where we need thinner deployments that start up and install faster. We need some of the more rich user capabilities you might see in other platforms that are perhaps more difficult to program in Java, we need to expose those in an easier way to broaden the developer base for Java.