Community
Participate
Working Groups
Build ID: I20070205-1800 Steps To Reproduce: 1. Download Eclipse 3.3M5 to a Gentoo Linux system 2. Run the launcher. 3. Scratch head about the following message: * run-java-tool is not available for sun-jdk-1.5 on i686 * IMPORTANT: some Java tools are not available on some VMs on some architectures 4. Use Google. 5. Find http://ahtik.com/blog/2007/02/11/eclipse-33m5-is-not-working-with-gentoo/ 6. Try eclipse -vm `java-config --java` to find out that it works. I didn't find the bug mentioned in this blog entry, so I filed this one.
Confirmed on 3.3M6. run-java-tool is a script that should not be called as "run-java-tool" but as a symlink to the name of a java tool. This error message suggests somehow the script was called as run-java-tool, and not as "java" as I suspect it should be called.
Also in 3.3 M7. The theory in comment #1 sounds likely to me.
Problem persists in 3.3RC3
Created attachment 70047 [details] patch We resolve symlinks so that we can find the vm libraries and load them using the JNI Invocation API. If on Gentoo the normal /usr/bin/java does not actually point into a vm, then we will never be able to use JNI invocation by default. The only thing I can see to do is if we got the vm from the path and can't find vm libraries, then use the unresolved "path command" to exec java instead of the resolved symlink. Note that this code is central enough that we would want to recompile all platforms if this change goes in.
This is a relatively significant change for this late in the cycle.
(In reply to comment #4) > Created an attachment (id=70047) [details] > patch > > We resolve symlinks so that we can find the vm libraries and load them using > the JNI Invocation API. If on Gentoo the normal /usr/bin/java does not > actually point into a vm, then we will never be able to use JNI invocation by > default. > Our JAVA_HOME does point to a VM though. The executables in /usr/bin are symlinks to run-java-tool that takes are of executing the tool it's called as from the selected vm. This way we can easily support per user vm's.
-1 for 3.3 This should not go in for 3.3. The change is too risky too late and there is a work around.
Why is that you choose to break the commonly used JAVA_HOME environment variable as a way to select a JVM ? And is it true that it is for splashscreen's sake ? This is *not* specific to gentoo, it's just that the way gentoo allow one to have multiple JVMs installed shows the breakage. Sorry, but for me, this would have been P1, as in: prevent release type of regression.
Created attachment 76798 [details] Patch updated for 3.3.1 Patch updated for consideration in 3.3.1
Jeff, do you have an opinion on this for 3.3.1? Or should we just put it in for 3.4? Re: Comment #8, The eclipse launcher has never consulted JAVA_HOME. Adding it now would not help this situation since to maintain behaviour, JAVA_HOME would need to be the last place to look. We found a java in /usr/bin/java and have no reason to ignore it and use JAVA_HOME instead.
After further review, this patch is insufficient and leaves a couple of cases that still need to be handled.
If I am understanding correctly, the fix does not fix the situation for 3.3.x since we cannot change the behaviour in the maintenance release. If that is the case then there is no point in putting the fix in. Is that an accurate summary?
The patch Andrew proposed was to use the unresolved symlink to fork java if we could not find the jni library from the resolved symlink. If I understand correctly we did not resolve symlinks in 3.2 in order to fork the vm process when launching. The fix here would be to use unresolved symlinks when forking the java process. To me that is a regression bug fix for 3.3.1. Now if I'm wrong and we used resolved symlinks to fork java in 3.2 then I agree with Jeff that this would be a change in behavior that will be hard to justify in a point release.
Created attachment 77052 [details] updated patch Here is an updated patch which fixes the missing cases in the previous version. Tom is correct, 3.2 did not resolve symlinks. This patch is using unresolved paths when forking java. Resolving symlinks occurs for finding the jvm shared libraries. This will fix the problem on Gentoo, they just end up forking java since we won't find the jvm shared libraries. Jeff, I think perhaps comment #10 is throwing you off. Consulting JAVA_HOME would not help the situation, and is not part of this patch (and won't be part of any fix in head either)
The patch looks good.
ok I am fine with this if we are confident/happy with the change not causing other problems.
done in HEAD & 3.3.1
It appears that this fix did not get released to 3.4 (HEAD) stream yet. Note that the fix introduces bug 203325. When integrating into HEAD be sure to include the fix from bug 203325.
done in HEAD (for real this time), fix for bug 203325 as well.
*** Bug 207197 has been marked as a duplicate of this bug. ***
Is Bug 207197 really a dupe of this? Or is the patch to this bug have side effect of solving it. 207197 doesn't have anything to do with Gentoo not starting up... it's about the paths of JREs being resolved when they are symlinks, which makes upgrading a JRE a real pain.
This bug is about resolving symlinks when launching eclipse itself. If bug 207197 is about the Installed JRE's preference page, then that is something different, and should be sent to JDT/Debug.
