Right. Except the bashing was misplaced in this case.
Could you list the bugs that were closed?
Dmitri
Well, as it seems, the bugs are not closed, they aren’t even added to the bug database.
One of the bugs:
http://www.indiespot.net/files/spooky_applet.html (~20% of the pageviews would result in deadlocks and crashes prior to 1.6.0u10)
See: http://www.java-gaming.org/index.php/topic,19440.0.html for pictures
Bug report to Sun:
--------------------- Report ---------------------
category : java_plugin
subcategory : misc
release : 6
type : bug
synopsis : NPE in dynamically loaded applet causing deadlock while loading JARs
language : en
hardware : x64
os : windows_vista_64
bug id : 0
date created : Sat Apr 05 03:09:15 MST 2008 date evaluated : Thu Apr 24 07:56:03 MST 2008
description :
FULL PRODUCT VERSION :
from 1.5.0 until 1.6.0_latest (don't know about 1.7.0)
ADDITIONAL OS VERSION INFORMATION :
Vista Home Premium 64bit
EXTRA RELEVANT SYSTEM CONFIGURATION :
the problem manifests itself on
A DESCRIPTION OF THE PROBLEM :
NPE in dynamically loaded applet causing deadlock while loading JARs
100% of the time an applet is dynamicly loaded, the following stacktrace is printed to Java Console:
java.lang.NullPointerException
at sun.plugin.AppletViewer.loadJarFiles(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
However, the orange Java logo is visible, and in 80% of the time it launches the Applet just fine. In the other 20% it hangs at the first pixel of the 'glowing white bar' in the orange Java logo.
When the *hanging* applet is removed from the DOM tree, the following stacktrace is printed to the Java Console:
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at sun.plugin.ClassLoaderInfo.lock(Unknown Source) <----------
at sun.plugin.AppletViewer.loadJarFiles(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Which seems like it has the same 'root' at the previous NPE.
The NPE probably makes certain assumptions wrong, causing it to lock on ClassLoaderInfo causing the deadlock 20% of the time.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
any applet that is dynamicly loaded into a page:
document.getElementById('my_div').innerHtml = .....;
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
a successfully launched applet
ACTUAL -
the applet-loader hangs at/before loading the JARs, 20% of the time
ERROR MESSAGES/STACK TRACES THAT OCCUR :
// on inserting in DOM tree
java.lang.NullPointerException
at sun.plugin.AppletViewer.loadJarFiles(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
// on removing from DOM tree
// IN CASE IT HUNG
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at sun.plugin.ClassLoaderInfo.lock(Unknown Source) <----------
at sun.plugin.AppletViewer.loadJarFiles(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
could be a simple "HelloWorld" Applet.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
1. moving the applet out of the screen (stylesheet: top:-1000px)
2. making some javascript-call to the page in Applet.start() which tells the applet to move back to visible coordinates.
3. when the applet hasn't notified the page in X seconds that it was loaded, re-insert the applet in the page
4. GOTO step 1
don't forget the nice animation to trick the user into thinking everything is alright.
with multiple applets on 1 page, it's very unlikely that all launch properly: chance = 0.80^applet_count
I know this bug has been fixed, so it’s to little use for you at this time, but you can google those stacktraces and you’ll see a lot of people running into problems, certainly 6 months ago.
I’ll dig into my mailbox to find the other bugs. Don’t hold your breath though.
On a sidenote… running 1.6.0u12, I managed to completely flood my RAM… MSIE doesn’t seem to close the applets properly, as memory usage goes up every pageview.
Yes, I found this issue - it was closed at the “incident” stage as “not reproducible” by the plugin engineer.
Your submission didn’t include a test case or a link to an applet reproducing the issue, which of course reduced
its chances of being reproduced. You were asked in a email to provide a test case - perhaps you didn’t, and that’s why it was closed?
Also, it doesn’t say which release it wasn’t reproducible with - may be the reviewer used 6u10 (this was 04/08)?
There are currently ~500 issues waiting to be reviewed in the plugin queue, so no wonder it takes a while for an issue to be reviewed/converted to a bug…
Dmitri
Also, the only other issue I found that was filed by you is “Add API to access SIMD instructions”, which was filed as a bug.
So what were those other issues that you filed?
Dmitri
Hm… I don’t recall a request for a test-case. I will search through my mailbox again. Further, it might sounds silly, but even an applet rendering 1 pixel did exhibit the crashing behaviour, so I didn’t feel like providing a test-case. Maybe that was a mistake, from a bug-fixing point-of-view with hundreds of other bugs in queue.
The bug was filed when 6u7 was just released. IIRC there was quite some time (months?) between 6u7 and 6u10.
Eh, not a bug, a RFE (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6526380)
Anyway, also I have filed a bug in NIO where under certain circumstances the selector.select() would not block at all when at least 1 socket was accepted, yielding 0 selected keys all the time, thus spinning very fast. --> Response: “not a bug”, while the darn Javadocs says otherwise: select() must never return 0, unless wakeup() or interrupted() … It felt (!) like there wasn’t any effort made in analyzing, which ofcourse, is just a wild assumption, due to the lack of feedback.
And a NIO bug were OP_READ was fired before the socket was accepted, also: “not a bug”, as it turned out it had to do with the OS being ‘eager’, and not NIO’s implementation - just adding this one for completeness.
I think the other bugs in the Plugin category (like the FireFox plugin with AccessControlExceptions, connecting to its own host, depening on on which thread the socket is opened, and the Opera plugin failing to do hardly any LiveConnect) have only been posted here, and not submitted in the parade, which is my fault - so I might have been a bit too harsh.
I have to agree I actually submitted fewer bugs than I expected or those encountered, but every bug report I did (I’m not talking about that RFE), was either not-reproducable, not-a-bug or just closed - when those bugs were causing so many hangs and crashes that we (at the company I work for) lost many potential customers, simply because they couldn’t get a crucial applet to work - not joking. You might argue that pre 6u10 it was a poor discision to make an applet such a curcial part of the business - that might be true. If nothing else, that situation caused my utmost dislike to the (previous) state of the Java Plugin, which is finally getting stable, for which I must add, I am very grateful.
A poor decision I think was not to buy support for something your business depended on. It depends on the situation, of course, but support contract isn’t all that expensive.
It’s not that I advocate the “you pay - we fix” thing, but you’d get a lot more attention if you were a paying customer.
Dmitri
The problem is, that even if we’d pay $$$, our visitors barely know how to install an application. They don’t know what Java is, or that it actually is installed on their PC, or that it is important to have an up to date version installed. So even if each and every bug is fixed today, it will only be fully adopted after roughly 3-5 years. Therefore you can’t expect much incentive to buy support, it needed to work yesterday.
We didn’t do enough research, that’s what it boils down to.
We saw 70-85% of our visitors had Java 1.4 - 1.6, which led us to make the descision to go for it. Currently between 60-70% visitors with Java, gets both the applet running where the applet is able to ring home. That’s ~55% of our visitors. To add insult to injury, that 55% has browser freezes (>5s), random browser crashes or totally swapped out systems because prior to 6u10 RAM wasn’t properly freed (e.g. data in static variables is not freed, as the classes are not unloaded) - and the heap couldn’t shrink yet. Since 6u10, 99% of our problems are gone, but it will take a long time for the majority of visitors to have upgraded.
Currently we redirect the requests to the page with the applet to a page where you can choose whether you want to download a standalone version, or a webbased (applet) version. So if they pick the applet, and their browser goes belly up, at least they know there is an alternative. This way the problems are ‘managable’, but it aint pretty.
The standalone version works flawlessly, it’s simply the Applet inside a Frame - so kudos for the uncrashable ‘java2d’ part which the app heavily relies on 
Pardon my ignorance since I’m just a novice, but doesn’t the Web Start JNLP interface allow a request to be put out to the customer to update the JRE? I realize applets are mentioned and that those aren’t JNLP files. It could be beneficial at least to M$ customers I would think.
welcome shatterblast,
i am not sure if this is possible only by using jnlp. You could put a minimal required version or a version range as restriction to the jnlp but AFAIK this won’t update the client’s jre.
[Edit] its indeed possible 
The best way to trigger a jre update on windows is by using the deployment toolkit (http://java.com/js/deployJava.js) which is a set of javascript utility methods. This works for first deployments also not only for updates.
see installLatestJRE function in the script.
The trickiest part is to reliably detect the installed jre version in a platform and browser independent manner, the standard deployment toolkit should work on windows in most cases. But it it is more difficult on other OSes and with not mainstream browsers to detect java version.
One of my users had looked deep into this problem. I’m not sure how many of my users are effected but the bug is there and annoying users playing my game.
He said:
[quote]Ok, so after searching round, and patching a few fixes together, here is the way which I found a fix, can someone please varify this way works.
I messed arround with permissions in the firewall, and this still left intermittant failures, the way I now do this, is so that when loading the game, there is no splash screen.
This fix means that you can leave your firewall running whilst loading the java.
[/quote]
So making a shortcut and adding “-Xnosplash” solves the problem.
He also noted this bug only affected Vista for him.
So I’m going to try adding Xnosplash to my jnlp file for now and see if that solved the problem.
I hope this gets fixed.
Huh, if true, sounds like a bug in the splash screen code (which is written in C?), and not Java itself. Good to hear. If that fixes the problem, it might be worth filing a new bug (fingers crossed).
FYI, I filed this bug to track this issue (will appear on bug parade in a day or so):
6814940: problems with loading jws apps with specified splash screen when firewall is present
Feel free to add your comments or findings to the bug report once it appears on bugs.sun.com.
Dmitri
Thanks trembovetski, I’ll add more info if anything is missing.