Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Ken Russell Discusses The Rewritten Browser Java Plug-In
URL: Java SE 6 Update N Early Access Program
At 9:48 PM on Oct 21, 2007, Geertjan wrote:
Fresh Jobs for Developers Post a job opportunity
The browser Java plug-In is the piece of software that makes applets run in today's web browsers such as Mozilla Firefox, Internet Explorer and Safari. It's been the default implementation of applets for a number of years. Sun Microsystems is responsible for delivering the plug-in on the Solaris, Linux and Windows platforms for IE and the Mozilla browser family.
Ken, what were the main benefits of this plug-in and what were its defects? The browser Java plug-in supplies the latest version of the Java VM and Java platform for the execution of applets. These are mature, high performance technologies that allow developers to write dynamic web content once and largely run it anywhere inside the browser. There were a couple of downsides to the previous implementation of the plug-in. The code was very old and versions for different browsers had been written by different teams. This basically meant there were three separate implementations of the plug-in. The Java/JavaScript integration was uneven and had varying levels of support on different browsers. Finally, the user experience during applet startup and shutdown was poor, causing the browser to be unresponsive for long periods of time.
What specific defects does the rewrite attempt to deal with?
Reliability foremost. The new plug-in runs applets in a separate operating system process from the web browser. At an architectural level this greatly improves reliability. It also gives us the ability for the first time to forcibly terminate poorly behaved applets. Other major issues that have been addressed are the user experience, Java/JavaScript integration, requests from enterprise customers to run one particular applet in a particular JRE version, and issues with signed applets in Protected Mode Internet Explorer on Windows Vista.
Can you state two specific gains that the user will get from this rewrite?
Number one, browser hangs and crashes related to Java will go away. Second, much more powerful applets can be deployed with the new plug-in; an individual applet can request more Java heap size, for example.
But, Java in the browser?! Can that possibly be performant at all? Doesn't it cause the page to freeze whenever you enter it?
This is now a solved problem. First, the new plug-in starts up applets in the background. The user experience is now that you go to the web page, the content renders, you can scroll around, etc., and if there is any delay in starting the applets on the page, they just pop into existence as soon as they're ready to go. Second, there is a new Java Quick Starter feature (not related to the new Java Plug-In) in the 6uN early access builds . This is a great piece of work and basically completely solves the startup time problem for applets. People are very happy with the quickstarter.
So, this rewrite is going to be delivered as a plug-in that will be switched off by default. Isn't it a bit demanding to expect the user to switch this on prior to using it?
It's true that the new plug-in will be delivered in 6uN side-by-side with the previous plug-in, and that the current plan is to have the new plug-in off by default. However, it's easy to switch between them with the Java Control Panel. We are also trying to achieve as close to 100% compatibility as possible and if this looks good then we might turn it on by default.
OK, but isn't this rewrite basically "too little, too late"?
I don't think it's ever too late. The new plug-in's architecture removes some artificial limitations on applets, allowing them to become much more powerful. It also improves reliability and cross-browser scripting behavior.
Which browsers are being targeted?
Sun will support Internet Explorer 6 and 7 and the Mozilla family of browsers (Firefox). Currently the new plug-in runs on the Firefox 3 alpha builds. We have been working closely with Mozilla.org during the development of the new plug-in. We hope that they will bring back the browser-side changes needed for the new plug-in to an update of Firefox 2 later this year.
What's the future of this plug-in?
It is going to become the default Java Plug-In at some point in the future. In particular, Mozilla is going to drop support for the old plug-in in a future Firefox release.
Can I already start using it? How? If not, when?
It will show up in the 6uN early access builds some time soon. At the latest it will be in the beta we plan sometime in December.
Is there a single site where I can get all the info I need, report bugs, and so on?
The 6uN early access site is the place to go. We are watching the forums and you will also be able to report bugs using the Sun Bug Database. Look for the subcategory "plugin2" under the "Java Plug-In" category soon.
Any specific final comments you'd like to make?
We're hoping to change the web landscape for developers and end users with this update and are looking forward to all of your feedback.
11 replies so far (
Post your own)
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
> the current plan is to have the new plug-in off by default.> However, it's easy to switch between them with the Java Control Panel.
WTF! Nobody, except people like me that actually know about this, will enable the new plugin!
In practice that means that the java experience will stay the same for 98% of people. It seems to be ok for you...
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
I'm very happy they are working on this. The approach sounds like a good re-think and it seems promising.One thing I'm wondering is how we will manage misbehaving applets, for example, ones that go into a tailspin and need to be shut down. I assume we can locate the process hosting the JVM and kill it, but will we then need to restart? Will there be built-in controls to help with this? This would also be important if we hit an applet which requires better hardware resources than our machines have available, where the applet starts chewing up as much CPU as it can grab. How can we control applets in that case?
Another question is whether applets can ever block browser navigation. Currently, if an applet takes a little bit of time to shut down, the browser will actually wait for it (or appears to, anyway). In that context, I'm also wondering if we have to worry about rogue applets--will navigating away from a page force an applet to be removed/killed, and can this be made 100% reliable?
Looking forward to trying this out.
Patrick
Thanks
I also would like to thank Sun for working on client-side java that serious lately.It has always been hard to argue for java because of (compared to the whole complexity and power of the platform) some small problems and quirks (like the old plugin), webstart bugs or slow startup - its really great to see those small showstoppers now beeing adressed.
I did not notice that the new plugin also won't block the browser - but its simply great. I guess this is the most important improvement at all - if an applet takes 10s to start well nobody is angry, but if an applet blocks your browser for 10s its quite problematic
Great job, thanks a lot
lg Clemens
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
Is there any way to push use of the new JPI from the server?Having each client have to ask for it via the Control Panel is unwieldy, whereas having a "use new JPI if client has it" flag from the server would be much better.
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
Relax, they're just playing it safe. A complete rewrite of the plugin is a big risk. They'll turn it on by default when they're 100% confident it works properly.Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
> Relax, they're just playing it safe. A complete> rewrite of the plugin is a big risk. They'll turn it
> on by default when they're 100% confident it works
> properly.
This is correct. I hope this alleviates peoples' concerns. Right now there are two large pieces of compatibility work that still need to be done to avoid breaking significant numbers of both consumer and enterprise applets. I am optimistic this work can be completed before the beta and that the new plug-in might be enabled by default by that time.
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
> One thing I'm wondering is how we will manage> misbehaving applets, for example, ones that go into a
> tailspin and need to be shut down.
We don't currently detect misbehaving applets while they're running, but:
> Another question is whether applets can ever block
> browser navigation. Currently, if an applet takes a
> little bit of time to shut down, the browser will
> actually wait for it (or appears to, anyway). In that
> context, I'm also wondering if we have to worry about
> rogue applets--will navigating away from a page force
> an applet to be removed/killed, and can this be made
> 100% reliable?
There are new detection mechanisms in the new plug-in for identifying applets which misbehave during shutdown. These were implemented by Hao Dong from the plugin team. Basically, during applet shutdown, we look for exceptions thrown while disposing the container of the applet; the presence of any remaining top-level windows; and any threads left around after the applet was supposed to have terminated. If any of these conditions are true, we mark the JVM instance as tainted, stop launching new applets in that JVM instance, and once all of the other applets running in that JVM have stopped, we forcibly shut down the JVM. This mechanism appears to be working very well. No user intervention is required.
As a side-effect, we now have a guaranteed maximum amount of time that we wait for a given applet to shut down, so we should never block the browser indefinitely any more.
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
> Is there any way to push use of the new JPI from the> server?
Not at this time. Again, the long-term intent is to switch to the new plug-in by default, but we have to get to a certain level of compatibility first. We are looking good on most applet content, but there are some high-profile game sites that aren't working properly with the new plug-in for known reasons. It's just a matter of time.
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
As mentioned on JGO, I am really looking forward to this!However it would be nice to be able to force the new plugin into action using some kind of object param or script.
This will allow customers to force users to use the new plugin architecture which has had QA.
Is this being worked at together with Apple? And if so, is there any time frame?
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
Please don't bother releasing a non-beta version of this with the new applet disabled by default.The people who most need it are exactly the ones that won't have a clue to turn it on.
And then you lose the PR momentum from having a big fixed up release.
Seriously, go for it all or don't bother. Get this in there even if it means a delay.
Re: Ken Russell Discusses The Rewritten Browser Java Plug-In
> However it would be nice to be able to force the new> plugin into action using some kind of object param or
> script.
>
> This will allow customers to force users to use the
> new plugin architecture which has had QA.
This is a technically difficult proposition. Part of this rewrite has been to remove the multiple "shim" layers that provide this kind of indirection. It might be possible to do this on IE but not on Firefox with the way the new plug-in ties in to the Firefox browser. For this reason we are not focusing on adding this kind of functionality, but instead on trying to achieve 100% backward compatibility.
> Is this being worked at together with Apple? And if
> so, is there any time frame?
All we can say at this point is that we've had lunch with some of the engineers at Apple and they're excited about the new plug-in's architecture.