Problem w/ setting Sun's JVM via (g)alternatives?

[Dan Thurman]

Since I am trying to get Eclipse's Ganemede working
again, I am told that I would need to use Sun's JRE,
however, I opted to use the JDK instead of the JRE.

I have downloaded and installed Sun's JDK 1.6 & 1.5
into /opt and it looks good.  I can via environment
setting run the java -version tests.

However

I have added the /opt/jdk[...]/bin/java to the alternatives
list in the 'java' category for both versions as follows:

/opt/jdk.1.6[...]/bin/java   priority: 1000
/opt/jdk.1.5[...]/bin/java   priority: 500

then selected JDK v1.6, and tried to launch Eclipse.

What resulted was a popup failure with the
relevant entry:

[...]
-vm /opt/jdk1.6.0_16/bin/../jre/lib/i386/client/libjvm.so
[...]
Note: the entire "barf" is at the end of the line.

Why is 'java' replaced with '../jre/lib/i386/client/libjvm.so'?
Yes, the -vm path exist.

Is this normal?

Side question: is the JRE instead of JDK required?  I wanted
the JDK so that I can do Java development but I do not think
there is a difference except only where the jre path is different.

Thanks-
Dan

The "barf":
===========================================
JVM terminated. Exit code=-1
-Xms40m
-Xmx512m
-XX:MaxPermSize=128m
-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith
-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding,<init>
-XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates,instantiateTemplate
-XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage,addBinding
-XX:CompileCommand=exclude,org/python/pydev/editor/codecompletion/revisited/PythonPathHelper,isValidSourceFile
-XX:CompileCommand=exclude,org/python/pydev/ui/filetypes/FileTypesPreferencesPage,getDottedValidSourceFiles
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins
-Djava.class.path=/usr/lib/eclipse/plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20081125.jar
-os linux
-ws gtk
-arch x86
-showsplash 
/usr/lib/eclipse//plugins/org.fedoraproject.ide.platform_3.4.2/splash.bmp
-launcher /usr/lib/eclipse/eclipse
-name Eclipse
--launcher.library 
/usr/lib/eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.0.101.R34x_v20080805/eclipse_1116.so
-startup 
/usr/lib/eclipse/plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20081125.jar
-vm /opt/jdk1.6.0_16/bin/../jre/lib/i386/client/libjvm.so
-vmargs
-Xms40m
-Xmx512m
-XX:MaxPermSize=128m
-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith
-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding,<init>
-XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates,instantiateTemplate
-XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage,addBinding
-XX:CompileCommand=exclude,org/python/pydev/editor/codecompletion/revisited/PythonPathHelper,isValidSourceFile
-XX:CompileCommand=exclude,org/python/pydev/ui/filetypes/FileTypesPreferencesPage,getDottedValidSourceFiles
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins
-Djava.class.path=/usr/lib/eclipse/plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20081125.jar


===========================================

[Mark Wielaard]

Hi Daniel,

On Thu, 2009-08-27 at 10:20 -0700, Daniel B. Thurman wrote:
>  Since I am trying to get Eclipse's Ganemede working
>  again, I am told that I would need to use Sun's JRE,
>  however, I opted to use the JDK instead of the JRE. 
The Sun JVM is proprietary and so not shipped with Fedora, which only
contains Free Software (and sadly some firmware blobs).

What is the reason it cannot run with one of the free alternatives like
GCJ (java-1.5.0-gcj) or IcedTea (java-1.6.0-openjdk) that are shipped
with Fedora?

I am sure we want to fix any issues that prevent Eclipse's Ganemede from
working out of the box.

Thanks,

Mark

[Andrew Overholt]

* Mark Wielaard <mark(a)klomp.org&gt; [2009-08-27 16:36]:
>  I am sure we want to fix any issues that prevent Eclipse's
> Ganemede from
>  working out of the box. 
Eclipse works just fine with OpenJDK.

I've spoken with Dan offline and while I don't have confirmation, I
suspect he was bitten by the fact that the XULRunner APIs changed
post-Eclipse 3.4 (Ganymede) release so out of the box on Fedora 11,
Eclipse 3.4 will crash when trying to render the welcome page (and other
browser-using bits).

In our Fedora packages of Eclipse 3.4.2, we carry a patch from upstream
to work with the latest XULRunner APIs.  Eclipse 3.5 (aka Galileo) works
with the latest XULRunner APIs so this is will no longer be necessary in
Fedora 12.

HTH,

Andrew

[Dan Thurman]

On 08/27/2009 01:49 PM, Andrew Overholt wrote:
>  * Mark Wielaard<mark(a)klomp.org>  [2009-08-27 16:36]:
>     
> > I am sure we want to fix any issues that prevent Eclipse's Ganemede from
> > working out of the box.
> >      
>  Eclipse works just fine with OpenJDK.
>
>  I've spoken with Dan offline and while I don't have confirmation, I
>  suspect he was bitten by the fact that the XULRunner APIs changed
>  post-Eclipse 3.4 (Ganymede) release so out of the box on Fedora 11,
>  Eclipse 3.4 will crash when trying to render the welcome page (and other
>  browser-using bits).
>
>  In our Fedora packages of Eclipse 3.4.2, we carry a patch from upstream
>  to work with the latest XULRunner APIs.  Eclipse 3.5 (aka Galileo) works
>  with the latest XULRunner APIs so this is will no longer be necessary in
>  Fedora 12.
>
>  HTH,
>
>  Andrew
>      
I read the bug report and it says that someone was able
to apply a patch and to get the XULRunner issue resolved.

Can I get the the fix now, at least so I can continue on or do
I need to wait for upstream to release the fix, sometime in
the future?

Thanks!
Dan

[Andrew Overholt]

* Daniel B. Thurman <dant(a)cdkkt.com&gt; [2009-08-28 14:53]:
>  Can I get the the fix now, at least so I can continue on or do
>  I need to wait for upstream to release the fix, sometime in
>  the future? 
There will not be a release of 3.4 with that fix [1].  The fix is there
and we carry it in our Fedora packages.  You could always re-build SWT
from 3.4 with it.  I recommend speaking with upstream if you really want
to do that.

Andrew

[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=268651#c30