pjt33
JGO Strike Force  Posts: 913 Medals: 17
|
 |
«
on:
2009-02-27 20:00:06 » |
|
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.
|
|
|
|
|
nva225
Sr. Member Posts: 298
|
|
«
Reply #1 on:
2009-02-28 02:41:32 » |
|
Not only that, but it turns on a semi-broken version of OpenGL acceleration which runs horrendously slow in XOR mode.
For those that don't know, XOR mode is when you draw the inverted color of what is onscreen, a feature used to select regions in a couple of programs I use.
Really regret downloading this release.
|
|
|
|
|
zammbi
JGO Strike Force Posts: 963 Medals: 9
|
|
«
Reply #2 on:
2009-02-28 03:03:48 » |
|
I haven't had any problems myself. Everything I have tried has worked for me. Though I don't think I've used anything that has used XOR.
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
Riven
« League of Dukes » JGO Kernel  Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #3 on:
2009-02-28 07:28:36 » |
|
What you have un u12, I've had for ages in u11.
Webstart is just plain broken. Eventually it works, but I sometimes have to launch a JNLP files 10 (or more!) times before it works.
I thought I was the only one with this problem, as nobody else ran into it.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
bienator
JGO Ninja Posts: 632 Medals: 1
OutOfCoffeeException
|
|
«
Reply #4 on:
2009-02-28 10:30:13 » |
|
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.
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #5 on:
2009-02-28 10:53:05 » |
|
I gave up on filing bug reports...
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 |
|
|
bienator
JGO Ninja Posts: 632 Medals: 1
OutOfCoffeeException
|
|
«
Reply #6 on:
2009-02-28 12:06:25 » |
|
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.
Sun changed priorities.
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #7 on:
2009-02-28 13:02:26 » |
|
For starters, they shouldn't *close* the bug immediately.
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 |
|
|
bienator
JGO Ninja Posts: 632 Medals: 1
OutOfCoffeeException
|
|
«
Reply #8 on:
2009-02-28 13:55:13 » |
|
For starters, they shouldn't *close* the bug immediately.
i agree, in this case this wasn't very nice. |
|
|
|
pjt33
JGO Strike Force Posts: 913 Medals: 17
|
|
«
Reply #9 on:
2009-02-28 16:15:53 » |
|
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. |
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
CommanderKeith
JGO Wizard Posts: 1455 Medals: 9
|
|
«
Reply #10 on:
2009-02-28 20:25:47 » |
|
Actually Sun's testing is tip-top. I saw something on the web about they're batteries of computers which they test the jre's on in Russia.
Sounds like webstart is being left out of the tests though...
|
|
|
|
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #13 on:
2009-03-01 13:30:35 » |
|
 Uninstalling Comodo Firewall now... I was not too happy with it anyway. Update: problem solved.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
h3ckboy
JGO Kernel Posts: 1645 Medals: 4
|
|
«
Reply #14 on:
2009-03-01 13:42:54 » |
|
is the problem the update or the firewall then?(I dont have 1.6 12, or this problem for that matter)
just curious
hope oyu guys can work it out.
|
|
|
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #15 on:
2009-03-01 21:15:21 » |
|
So, after all that Sun's client team bashing the problem turned out to be caused by third party software, huh?
Anyway, FYI, the XOR perf bug has been fixed - or, rather, worked around - in 6u14 (the build with the fix isn't out yet).
Dmitri
|
|
|
|
|
Abuse
JGO Kernel Posts: 1866 Medals: 5
falling into the abyss of reality
|
|
«
Reply #16 on:
2009-03-01 22:26:43 » |
|
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.
|
|
|
|
|
brackeen
Full Member Posts: 247
|
|
«
Reply #17 on:
2009-03-02 00:54:18 » |
|
What's on my mind is:
Is the out-of-process Java Plugin sometimes stopped by firewalls, too?
Or is this a bug in the splash screen code of JWS?
|
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #18 on:
2009-03-02 01:57:34 » |
|
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 |
|
|
pjt33
JGO Strike Force Posts: 913 Medals: 17
|
|
«
Reply #19 on:
2009-03-02 05:00:37 » |
|
So, after all that Sun's client team bashing the problem turned out to be caused by third party software, huh?
My problems aren't caused by a firewall, because I don't have one. (I run Linux, before anyone tells me that my computer is probably zombied). |
|
|
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #20 on:
2009-03-02 23:22:45 » |
|
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'.
Right. Except the bashing was misplaced in this case. Could you list the bugs that were closed? Dmitri |
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #21 on:
2009-03-03 12:47:24 » |
|
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/topics/applet-reliability-test-with-me-msie-7-0-please/19440/view.html for pictures Bug report to Sun: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
| --------------------- 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. |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #22 on:
2009-03-03 13:03:35 » |
|
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.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #23 on:
2009-03-03 18:14:06 » |
|
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.. Dmitri |
|
|
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #24 on:
2009-03-03 18:20:25 » |
|
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
|
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #25 on:
2009-03-03 19:33:33 » |
|
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. 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
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. |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #26 on:
2009-03-03 21:03:35 » |
|
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. Dmitri |
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #27 on:
2009-03-03 21:57:25 » |
|
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 |
|
|
shatterblast
JGO n00b Posts: 44
Noobier Than Thou
|
|
«
Reply #28 on:
2009-03-08 18:24:40 » |
|
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.
|
|
|
|
bienator
JGO Ninja Posts: 632 Medals: 1
OutOfCoffeeException
|
|
«
Reply #29 on:
2009-03-08 19:40:39 » |
|
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. |
|
|
|
|
