Reimagining Java in the Browser

Story by Al Riske. Photography by Howard Friedenberg.

August 11, 2008 - The way Ken Russell sees it, it was his karma to make Java technology run faster.

It started in the Media Lab at MIT a decade ago, when Russell was working toward his master's degree.

"Our advisor came to us and said, 'Okay, guys we're doing super-intelligent animated characters and we're doing them in Java,' and I said, 'No, it will be too slow!'" Russell recalls. "So it's been my karma over the past 10 or so years to make that not the case in the 3-D graphics realm."

Russell, now a senior staff engineer at Sun, notes that speed is no longer an issue. "At this point, we can do faster 3-D graphics in Java than we can in C++ due to the hard work of everyone in the Java software organization," he says.

But that's only a preamble.

The central story here is how Russell and his team have been able to make Java software run more reliably in Web browsers and, in the process, taught it to do new tricks.

In the course of just one year, Russell and a handful of his colleagues reimagined and redesigned the Java plug-in – the code that goes into Web browsers so they can launch and run Java applications.

"The inspiration? It was an ongoing thing where it was painful, painful, painful, and it was obvious at a certain point what had to be done," Russell says.

Fortunately he saw those limitations as merely technical. All one had to do, really, was read through about 50,000 lines of code, digest it all, distill it, and then start writing again from the beginning.

Oh, and make sure all the Java applets already out there on the Web still run unchanged.

Piece of cake, right?

"The code to the previous Java plug-in was fairly disorganized because it had grown organically over a number of years, and it was done in a big rush when it was first conceived," Russell observes. "There had never been the opportunity to go back and rewrite the whole thing."

Quite frankly, he says, the architecture was exactly inverted from where it needed to be.

"Ken realized that not only was the current architecture fundamentally flawed but that by changing the model, we could break free from the burden of a fragile and universally panned plug-in architecture," says Bob Brewin, CTO of Software at Sun. "By leveraging this new and innovative design, Java could once again take center stage on the Web as the new plug-in would not only allow for transparent execution within and outside the browser but revolutionize the concept of deployment of applications via the Web."

There were, Russell says, "some fairly large unknowns."

One of the biggest was whether technology similar to Java Web Start would work in all browsers running on all operating systems. For Solaris and Linux, probably yes, since a similar technique was already in use (though it would need to be made much more robust to support the use cases Russell had in mind).

The big unknown was the Microsoft Windows platform.

"We had to do a significant amount of prototyping before we could even test the viability of the project in some ways. We had to build enough software to do some tests to see: Is it going to work? Yes or no?" Russell says.

"That was a major hurdle because it's difficult for people to buy into a project until they see results on the screen, but we couldn't show results on the screen until we built a significant amount of the project."

Fortunately, the project had the support of Software CTO Bob Brewin and Sun Fellow James Gosling (a.k.a. the father of Java) right from the start.

"That was Step Zero," Russell says. "That was absolutely necessary to get alignment and enough support to begin to drive the project forward."

"If you want to run your applet, you need the applet container in order to load it, start it, and give it enough services so that it can feel it's in the environment it expects. So the first step was rebuilding the applet container out of the pieces that were in the old applet container," he says.

"It was really picking out exactly the chunks of source code, rewriting some of them, and then putting them in the right places, so that we had an applet container that would run applets completely independently of the Web browser."

That took a long time.

"It took months because it wasn't the top priority project all the time, and it took a long time to go through that much source code and see where all the relevant pieces were because they were scattered throughout many files," he says. "But you needed this piece from here, this piece from here, and this piece from there, so you really had to read all of it."

Then came an intense, highly focused, no-distractions effort that Russell describes as a marathon/sprint.

"Starting from the stand-alone applet version, we were able to get that hooked into the Internet Explorer browser in nine and a half days," he says.

How were they able to do it so quickly?

"Web browsers are typically written in C or C++, so in order to hook into it you have to write some C or C++ code. The old Java plug-in had a lot of C and C++ code and even the Java code was mainly browser specific. In the new Java plug-in, most of this software is written in the Java language and there's the tiniest bit of C and C++ to glue it into the browser," Russell explains.

"So we go from C and C++ into Java as quickly as possible even on the browser side, and from there we go to platform-independent Java as quickly as possible – and from there most of the system is completely platform and browser independent. That's one of the key innovations here."

The main reason the team succeeded, he says, is Java itself.

"We used the advantages of the portable Java language with its much simpler semantics and syntax and powerful things like multithreading support built into the language to be able to construct this system rapidly -- and reliably."

Originally undertaken in support of Sun's Java OpenGL project, or JOGL, the new plug-in is also the underpinning of the JavaFX deployment strategy in the browser.

"JavaFX will rely on a very sophisticated set of libraries to extend the functionality of the Java platform to get the performance and features we need to do rich media content in the browser. So we needed a technology like this that was on par with Java Web Start technology to be able to get these new features of the Java platform down to the end user's machine and run them inside the Web browser," Russell says

"As it turns out there are some very interesting opportunities that became obvious to us by doing this architectural change."

He turns to his computer and brings up a JavaFX applet in his browser.

Then he demonstrated an interesting new feature of the Java plug-in. He drags the applet from his browser to his desktop. Even when he quits the browser, the applet keeps running.

"That was enabled by the architectural changes we made," he says. "Of course we have to do more work. There are some rough edges in the new system, but in terms of achieving a goal that isn't possible with any other Web technology at the moment, I think we did pretty well."

Russell credits his colleagues in the software group as well as early access customers and partners for helping refine the new plug-in, and his manager, Gustavo Galimberti, for supporting the project.

"Now we maintain all this code and have the ability to extend it in some very interesting ways. We're looking forward to really taking advantage of that as we push forward."