Summary: | javaws does not start | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Charles Noneman <charless> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | jfmuggs, kolashj, robin, schnake.newsletter, spamlover, tetromino |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Charles Noneman
2004-10-30 13:40:35 UTC
Exactly the same here, but with sun-jdk-1.4.2.06 as well as sun-jdk-1.5.0. No matter which JDK or what javaws options used, javaws goes to 100% CPU and does nothing (no error message, no splash, no anything). Process list shows "javawsbin" with high (> 80%) CPU load and one (zombified) child process "[java] <defunct>" Java itself runs without any problems (e.g. Eclipse and NetBeans IDEs work well). Also unmerged both JDKs and emerged a "fresh" sun-jdk-1.4.2.06. Same result. BTW starting with "JAVAWS_HOME=/opt/sun-jdk-1.4.2.06/jre/javaws javawsbin" does not help either. Sys-Info: Portage 2.0.51-r2 (default-linux/x86/2004.2/gcc34/2.6, gcc-3.4.2, glibc-2.3.4.20041021-r0, 2.6.9-nitro2 i686) CFLAGS="-march=pentium3 -pipe -O2 -fomit-frame-pointer -ftracer" Note that we have the same gcc and glibc versions (and they are pretty up to date, too ;-). Wondering if this is a "bleeding edge" kind of problem. FYI, there is an upstream bug report at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6195591 A more contentful upstream report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6188963 (They claim that it's fixed in the 5.0u2 release, which, as far as I can tell, is not available for download yet - oh well) This seems to be fixed in dev-java/blackdown-jdk-1.4.2.01, closing. blackdown-jdk-1.4.2.01 is based on sun-jdk 1.4.2.07 alpha code, so it should also be fixed in the next sun release Seems like sun broke it again in there .07 release *** Bug 80165 has been marked as a duplicate of this bug. *** *** Bug 74753 has been marked as a duplicate of this bug. *** POSSIBLE WORKAROUND i also had this problem. strace showed that javaws could not open ~/.java/.deployment/deployment.properties i fetched one from another machine, fixed the path locations and stored that file. now javaws works as expected. my deployment.properties: # #Sat Feb 05 20:09:05 CET 2005 deployment.javaws.jre.0.registered=true deployment.javaws.jre.0.platform=1.4 deployment.javaws.player.bounds=354,310,572,403 deployment.javaws.jre.0.osname=Linux deployment.javaws.jre.0.path=/opt/sun-jdk-1.4.2.07/jre/bin/java deployment.javaws.jre.0.product=1.4.2_07 deployment.javaws.player.manager=0 deployment.javaws.jre.0.osarch=i386 deployment.javaws.player.mode=1 deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se deployment.javaws.version=javaws-1.4.2_07 deployment.javaws.jre.0.enabled=true Very good catch. I am interested as to why javaws does not function without a configuration file. It would be good to know that this is not just the side effect of another bug. After reading up on this, the "workaround" is valid. With 1.4.2 the javaws config file (javaws.cfg) was removed, and the configuration was sent to deployment.{config,properties}. The ebuilds do not do this, and as such caused this bug. http://www.advogato.org/person/rmathew/diary.html?start=71 'another workaround' Apparently, this bug may hit when sun-jdk is updated. My .deployment.properties contained references to sun-jdk-1.4.2.05, when it was changed to sun-jdk-1.4.2.08 javaws started to work again. I wonder how an ebuild should handle such things. preferably it would not, and sun would fix the program In my situation, the workaround creating proper deployment.properties does not solve this issue. This bug triggers just on one desktop machine, while it does not appear on a laptop, also running gentoo. On the desktop-machine, it works for root, but not for any other user, while on the laptop, it runs for anybody. I think, it could be related to the desktops setup, where /home is provided via NFS by a Debian Sarge machine. On the laptop, /home has it's own partition, but still is local. updated the ebuilds too use the hack in comment #13 I wonder why the bug is listed as "resolved" and "fixed" when it is not fixed at all in my new gentoo installation (Gentoo 2005.0 up to date, sun-jre-bin 1.4.2.08 first installed today). It works after creating the deployment.properties file (with the appropriate data). it should work with latest ~x86 I'm not sure it's just an ebuild thing. should this be switched by java-config? I got into this bug when I wound up with a default blackdown and then tried to switch to sun. I switched to it using java-config and then tried to load a jws app in firefox. Of course I picked the currently selected java, but my properties file still said blackdown all over it. This of course introduces the broader question of whether or not java-config should also switch what javaws your browser invokes. (which I suspect is a difficult problem). However, as a naieve user of java-config, this was may natural expectation. Certainly the smooth user experience is the one where you say "use jde/jdk X" once, as opposed to set javaws it in your browser and edit a properties file and run java-config to switch which java you are using. Note that if I had said take this action every time in the firefox dialog, I'm not sure how to get it to stop using that program if I want to switch what java I am using (I'm sure I could find it eventually) Perhaps this should just result in a message from java-config stating that javaws is not effected by java-config -S, on each switch |