I emerged blackdown-jre-1.4.2_rc1 without a problem, but it doesn't seem to work at all. Even when I do a java -version I get the error: zac@moebius java $ java -version Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object I'm also trying to use this with the program azureus: zac@moebius zac $ azureus/azureus Starting Azureus... Loading Azureus: /opt/blackdown-jre-1.4.2_rc1/bin/java -cp .:Azureus2.jar:swt-mozilla.jar:swt-pi.jar:swt.jar -Djava.library.path=/home/zac/azureus org.gudy.azureus2.ui.swt.Main '' Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object Azureus TERMINATED. There is no eBuild of azureus, by the way, which I find surprising so I used the installer from their site. Reproducible: Always Steps to Reproduce: 1.go to java directory, in this case /opt/blackdown-jre-1.4.2_rc1 2.type java -version Actual Results: Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object Expected Results: It's supposed to output the version. I've also tried unmerging it and remerging it after doing an emerge sync, but everything was the same. Restarting didn't change anything either. One thing I did notice though.... java-config -o outputs the path of jre home and for me it outputs /opt/blackdown-jre-1.4.2_rc1, but since java is in the bin dir, shouldn't it be /opt/blackdown-jre-1.4.2_rc1/bin? I'm pretty new at this so let me know if you need any more info.
Do you already have a different JDK installed? Which VM is active when you do java-config -L? Does the active JDK work (if this is different from the JRE)? What is JAVA_HOME set to?
I can confirm that gm ib # java-config -L [blackdown-jre-1.4.1] "Blackdown JRE 1.4.1" (/etc/env.d/java/20blackdown-jre-1.4.1) [blackdown-jre-1.4.2_rc1] "Blackdown JRE 1.4.2_rc1" (/etc/env.d/java/20blackdown-jre-1.4.2_rc1) * gm ib # echo $JAVA_HOME /opt/blackdown-jre-1.4.2_rc1
Karl Trygve Kalleberg, I did not have another JDK/JRE installed, and still don't. root@moebius zac # java-config -L [blackdown-jre-1.4.2_rc1] "Blackdown JRE 1.4.2_rc1" (/etc/env.d/java/20blackdown-jre-1.4.2_rc1) * root@moebius zac # java-config --jre-home /opt/blackdown-jre-1.4.2_rc1 Let me know if you need anything else. Zac
ayanami root # java-config -L [blackdown-jdk-1.4.2_rc1] "Blackdown JDK 1.4.2_rc1" (/etc/env.d/java/20blackdown-jdk-1.4.2_rc1) * [blackdown-jre-1.4.2_rc1] "Blackdown JRE 1.4.2_rc1" (/etc/env.d/java/20blackdown-jre-1.4.2_rc1) ayanami root # java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) works here... is this really an amd64 bug, or can i yank amd64 out?
It is happening to me too. blackdown-JDK works fine. JRE is messed up. Here's some information I gleaned from the forums at sun: - There could be up to hundred files, drivers, etc that could get corrupted and cause this in the OS - Permissions problems - Deleted files, deleted directories, even lack of swap space. - Corrupted java binaries. - Corrupted java class files. - Some application locking one of the many java binaries or class files.
I think I have the reason. It is because their are files that are "packed" in the jre's lib directory. Specifically, rt.pack. This contains the Object class so that is why it isn't getting loaded. Anyone know how to "unpack" these files?
Specifically, these files ater probably the problem. /opt/blackdown-jre-1.4.2_rc1/lib/ext/localedata.pack /opt/blackdown-jre-1.4.2_rc1/lib/plugin.pack /opt/blackdown-jre-1.4.2_rc1/lib/rt.pack /opt/blackdown-jre-1.4.2_rc1/lib/jsse.pack /opt/blackdown-jre-1.4.2_rc1/lib/charsets.pack
Finally figured it out, almost. This is my first gentoo ebuild fix, so bear with me. The reason is that the unpack file doesn't exist for some reason when the unpack_jars() method is called to execute blackdown's own code. So, nothing gets unpacked. Anyone know where this file goes? I suppose simply comparing the differences between this and the working jdk ebuild should be most enlightening. There is an error also about not finding a directory during the installation...
just for kicks I unmerged jre, deleted the distfile, and emerged jre and at the end I got this message: ... * Found no JDK, setting blackdown-jre-1.4.2_rc1 as default system VM * Setting blackdown-jre-1.4.2_rc1 as default * Use java-config to reassign your VM. javac not found at /opt/blackdown-jre-1.4.2_rc1/bin/javac or /opt/blackdown-jre-1.4.2_rc1/jre/bin/javac javadoc not found at /opt/blackdown-jre-1.4.2_rc1/bin/javadoc or /opt/blackdown-jre-1.4.2_rc1/jre/bin/javadoc jar not found at /opt/blackdown-jre-1.4.2_rc1/bin/jar or /opt/blackdown-jre-1.4.2_rc1/jre/bin/jar rmic not found at /opt/blackdown-jre-1.4.2_rc1/bin/rmic or /opt/blackdown-jre-1.4.2_rc1/jre/bin/rmic THIS SYSTEM VM IS NOT SUFFICIENT, REQUIRED BINARIES WERE NOT FOUND System Virtual Machine set You may want to update your enviroment by running: "/usr/sbin/env-update && source /etc/profile" >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... >>> dev-java/blackdown-jre-1.4.2_rc1-r1 merged. ... I don't know if this is related or not.
I just emerged Azureus, a java-based bittorrent client. It emerged blackdown-jdk-1.4.2_rc1 as well as about 20 other java packages and library looking things and finally azureus. Trying to start azurus by typing "azureus in a shell returns the following error: zac@moebius ~ $ azureus Attempting to start Azureus... Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object If you recieved an error about a missing java class, you need to setup your classpath correctly. This should do the trick (as root): java-config --add-system-classpath=junit,log4j,commons-cli,systray4j env-update && source /etc/profile Currently, your classpath (including azureus additions) is: swt.jar:swt-pi.jar:swt-mozilla.jar:seda.jar:Azureus2.jar:. And when I do that I get: root@moebius /home/zac # java-config --add-system-classpath=junit,log4j,commons-cli,systray4j Error reading classpath file [Errno 2] No such file or directory: '/etc/env.d/21java-classpath'root@moebius /home/zac # env-update && source /etc/profile >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... I thought maybe this could provide more clues. Let me know if there's anything else I can do to help.
Comment 9 and Comment 10 may be spurious. Here's the real information. I got lost in the ebuild because I'm not that savvy with them yet. Here's what Juergen Kreileder of Blackdown replied to me about .pack files. I think there is a logic bug in the ebuild and the files never get unpacked. The code Juergen lists is in the ebuild, but for some reason in the line if [ -f "$JAVAHOME/`dirname $i`/`basename $i .jar`.pack" ]; Those files don't exist!!!! ============================================ Mail from blackdown ============================================ I WROTE: >>> There is a gentoo bug about .pack files. >>> Do you know anything about rt.jar -> rt.pack? >> HE WROTE: Thanks. If you see these files ,---- | /opt/blackdown-jre-1.4.2_rc1/lib/ext/localedata.pack | /opt/blackdown-jre-1.4.2_rc1/lib/plugin.pack | /opt/blackdown-jre-1.4.2_rc1/lib/rt.pack | /opt/blackdown-jre-1.4.2_rc1/lib/jsse.pack | /opt/blackdown-jre-1.4.2_rc1/lib/charsets.pack `---- then the unpack phase was skipped for some reason. I don't know how the gentoo package works, so I can't say where this happens exactly. If gentoo manually extracts the tarball from the installer script, they have to do a few additional steps. If you look at the original Blackdown installer you'll see something like: ,---- | PACKED_JARS="lib/rt.jar lib/jsse.jar lib/charsets.jar lib/ext/localedata.jar lib/plugin.jar javaws/javaws.jar" | [...] | if [ -f "$JAVAHOME/lib/unpack" ]; then | UNPACK_CMD="$JAVAHOME/lib/unpack" | chmod +x "$UNPACK_CMD" | packerror="" | for i in $PACKED_JARS; do | if [ -f "$JAVAHOME/`dirname $i`/`basename $i .jar`.pack" ]; then | printf "Creating %s\n" "$JAVAHOME/$i" | "$UNPACK_CMD" "$JAVAHOME/`dirname $i`/`basename $i .jar`.pack" "$JAVAHOME/$i" | if [ ! -f "$JAVAHOME/$i" ]; then | printf "Failed to unpack jar files %s. Please refer\n" "$i" | printf "to the Troubleshooting section of the Installation\n" | printf "Instructions on the download page for more information.n" | packerror="1" | fi | rm -f "$JAVAHOME/`dirname $i`/`basename $i .jar`.pack" | fi | done | fi | rm -f "$UNPACK_CMD" `---- This code uncompresses the .pack files to .jar files. The 'unpack' utility gets deleted after that. > blackdown-JDK works fine. JRE is messed up That would indicate that something like above is done for the JDK package but not the JRE package. Juergen PS: Another thing an installer should do is creating /etc/.java/.systemPrefs/.system.lock and /etc/.java/.systemPrefs/.systemRootModFile if they don't exist. In our installer we do ,---- | if [ x"$PREFS_LOCATION" != x ]; then | if [ x"$userid" = xroot ] ; then | PREFS_LOCATION=/etc/.java | else | PREFS_LOCATION="$JAVAHOME/$PREFS_LOCATION" | fi | if [ ! -d "$PREFS_LOCATION" ] ; then | mkdir -m 755 "$PREFS_LOCATION" | fi | if [ ! -d "$PREFS_LOCATION/.systemPrefs" ] ; then | mkdir -m 755 "$PREFS_LOCATION/.systemPrefs" | fi | if [ ! -f "$PREFS_LOCATION/.systemPrefs/.system.lock" ] ; then | touch "$PREFS_LOCATION/.systemPrefs/.system.lock" | chmod 644 "$PREFS_LOCATION/.systemPrefs/.system.lock" | fi | if [ ! -f "$PREFS_LOCATION/.systemPrefs/.systemRootModFile" ] ; then | touch "$PREFS_LOCATION/.systemPrefs/.systemRootModFile" | chmod 644 "$PREFS_LOCATION/.systemPrefs/.systemRootModFile" | fi | fi `---- Our Debian packages[1] additionally creates MIME entries, so that Java Web Start and executable JARs automatically work with Mozilla and GNOME stuff. Footnotes: [1] http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/j2se/debian/?cvsroot=pkg-j2se --
fixed in blackdown-jre-1.4.2_rc1-r2
