Is anyone else having problems with Java 1.6 update 12 and Webstart? I just tried it out with Gravitational Fourks and it appears to be completely broken - I'm not even getting a console window, just a splash screen which vanishes after a very short period of time and a process which sits using up half my CPU.

as always the best what we can do is to file bugs or vote for already filed bugs (e.g XOR perf regression). Thats what early access builds are for.

Since JavaFX is Sun's new marketing flagship for the desktop, webstart bugs should be taken pretty seriously internally since ws is currently the *only* deployment mechanism of JavaFX apps and applets.

regarding OpenGL pipeline, i pretty much gave up the hope that we will get a reliable pipeline anytime soon.

I submitted about 5 or 6. All were closed withing a few weeks... "could not reproduce".

I mean... it's like JFileChooser. You can't even traverse directories, a doubleclick renames the directory, [enter] selects it. It's been like that for 5 years? People complaining everywhere, Sun is not going to fix it, because they cannot reproduce the damn thing. The Java Plugin is only (more or less) stable since u10. I've given up all hope on Sun in the clientside. The JVM is a masterpiece, but everything they release clientside is just buggy, and bugfixes take 5+ years. Webstart never worked reliably, and now it's entirely broken. Don't the folks have a Quality Assurance team there? With 20 PCs with the most common combinations of operating systems and browser versions?

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

They fixed bugs which are actually pretty old (AFAIK the heavyweight/leightweight thingy was around 10 years old).

Almost the whole desktop team works on JavaFX... webstart is currently the only supported way to get javafx running. Its suicide if deployment doesn't work (They know that). You have to see it from their perspective too - what should they do if they can't reproduce the bug? Next time you see something very rarely reproducible (with latest update release) you could e.g take threaddumps or zip your entire webstart cache and sent it to them. Race conditions are really a pain in the ass and very difficult to track...

Regarding the filechooser. I heard at last J1 that they plan a rewrite for JDK7, not sure if it is still up2date since Sun runs currently with reduced resources.

I talked to some devs about the browser embedded notifications for applets as alternative to the notification *dialogs* and they think about including it in 7 and will provide a workaround for javafx applets (for some scenarios) since they can't implement it in a jre update release.

I mean, if there a dozens of developers complaining, they should be taken serious, even if you cannot reproduce.

I'm fairly disgusted about all resources put at JavaFX: a technology that nobody really is waiting for, and given Suns trackrecord, will finally be stable in 5 to 10 years. We need SERIOUS bugfixes in Swing, where components fire double events, or render totally wrong graphics, even in the DirectX pipeline (I just wasted 1 entire day at work tracking it down) under very specific conditions, in very specific versions.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

You have to see it from their perspective too - what should they do if they can't reproduce the bug? Next time you see something very rarely reproducible (with latest update release) you could e.g take threaddumps or zip your entire webstart cache and sent it to them.

How do we know whether something's rarely reproducible or not? The correct action in case you can't reproduce is to ask for more details, not close immediately.

While the "Splash recv failed" error is a little better than "General error 38",I think it's fair to say that almost no users are going to interprete it as meaning "Unable to connect to host, please check your internet and firewall connection settings".

Case in point;It's taken 1 tech. guru searching forums to find the solution, another to link his blog onto a Java developers forum to help a 3rd resolve the problem.That's 3 tech gurus more than the average casual web gamer is going to have access to.

So, after all that Sun's client team bashing the problem turned out to be caused by third party software, huh?

Dmitri

While it may seem unfair to you that I was 'bashing' you for something not your fault, it seems unfair to me, that now that one bug isn't caused by the Java client team, suddenly all my other instantly closed bugreports are discarded in the same category? I mean, there are very sound reasons for my so called 'bashing'.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

While it may seem unfair to you that I was 'bashing' you for something not your fault, it seems unfair to me, that now that one bug isn't caused by the Java client team, suddenly all my other instantly closed bugreports are discarded in the same category? I mean, there are very sound reasons for my so called 'bashing'.

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 'glowingwhitebar' 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:

ERROR MESSAGES/STACK TRACES THAT OCCUR :// on inserting in DOM treejava.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 HUNGjava.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)

Well, as it seems, the bugs are not closed, they aren't even added to the bug database.

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..

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

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.

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.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

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. I

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.

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

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org