Bug 181412 - gcj class loader behaves inconsistently
gcj class loader behaves inconsistently
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-13 16:08 EST by Rafael H. Schloming
Modified: 2014-12-01 18:13 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:22:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rafael H. Schloming 2006-02-13 16:08:24 EST
Description of problem:

For some classes, e.g. java.lang.Object, java.util.Map, the gcj class loader
will allow Class.forName(...) to succeed, but
ClassLoader.getResourceAsStream(...) will return null if libgcj.jar is not in
the classpath.

Version-Release number of selected component (if applicable):

gcc-4.1.0-0.24

How reproducible:

Allways

Steps to Reproduce:
1. Place the following code in Test.java:

class Test {

    public static final void main(String[] args) throws Exception {
        ClassLoader loader = Test.class.getClassLoader();
        for (int i = 0; i < args.length; i++) {
            String name = args[i];
            String path = name.replace('.', '/') + ".class";
            Class klass = Class.forName(name);
            Object o = loader.getResourceAsStream(path);
            System.out.println(klass + ", " + path + " = " + o);
        }
    }

}

2. javac Test.java
3. java -cp . Test java.lang.Object
  
Actual results:

class java.lang.Object, java/lang/Object.class = null

Expected results:

class java.lang.Object, java/lang/Object.class =
java.util.zip.InflaterInputStream@3213c0
Comment 1 Bryce McKinlay 2006-02-13 16:38:03 EST
In the original FC4, I believe java-gcj-compat used to add rt.jar to classpath.
Since some time during the FC4 cycle, it appears that this is no longer
happening. I think the quickest fix for FC5 would be to fix java-gcj-compat.

The best fix however is for libgcj to add its .jar's to its own classpath
automatically, just like other JVMs. We've resisted doing this in the (distant)
past because it would have made libgcj difficult to relocate after building it.
However, we are going to need this for loading locale data etc anyway. It will
be possible to locate libgcj's "JAVA_HOME" directory based on the location of
libgcj.so itself, via dl_iterate_phdr().
Comment 2 Andrew Haley 2006-02-14 05:31:11 EST
As far as I'm aware libgcj*.jar doesn't even have to be installed.  I suppose
there are some programs that use their own class loaders to load core classes
and assume that these will always be bytecode available.  In such cases it makes
sense to be compatible, so we go with the flow, I guess, at least for the "java"
alternative.  Having said that, I don't know if loading core classes from
bytecode in this way would work.

> It will
> be possible to locate libgcj's "JAVA_HOME" directory based on the location of
> libgcj.so itself, via dl_iterate_phdr().

This sounds rather fragile.  Better to fix it at config time, I would have
thought.  

I agree it's best to fix java-gcj-compat in FC5.
Comment 3 Thomas Fitzsimmons 2006-02-14 12:26:38 EST
(In reply to comment #2)

> > It will
> > be possible to locate libgcj's "JAVA_HOME" directory based on the location of
> > libgcj.so itself, via dl_iterate_phdr().
> 
> This sounds rather fragile.  Better to fix it at config time, I would have
> thought.

libgcj configure has the --with-java-home option for this purpose.

> I agree it's best to fix java-gcj-compat in FC5.

OK, our java command is a C wrapper binary.  Are you suggesting that I add
-classpath $rt_jar_location to the arguments passed to gij?
Comment 4 Andrew Haley 2006-02-14 13:00:41 EST
Comment #1 says

"In the original FC4, I believe java-gcj-compat used to add rt.jar to classpath."

Presumably, someone somewhere decided to change it no longer to do so.  I'm
suggesting we change it back, that's all.

Comment 5 Bryce McKinlay 2006-02-14 13:46:42 EST
(In reply to comment #2)
> > It will
> > be possible to locate libgcj's "JAVA_HOME" directory based on the location of
> > libgcj.so itself, via dl_iterate_phdr().
> 
> This sounds rather fragile.  Better to fix it at config time, I would have
> thought.  


Using the runtime path is much _less_ fragile. If it is fixed at config time,
then moving or renaming the installed tree in any way means we can't find the
.jar resources.

GCC in general is fully relocatable, but currently libgcj is not due to this
problem.

Of course, we can always keep the config-time path around as a fallback in case
we can't find it using the runtime path for some reason. 
Comment 6 Bryce McKinlay 2006-02-14 13:47:54 EST
OK, it turns out that rt.jar is still on the classpath. Its put there at config
time by --with-java-home. The problem is that ResourceBudle.getBundle() is not
finding resources that are on the bootclasspath.
Comment 7 Tom Tromey 2006-02-14 14:43:10 EST
Perhaps the fix is to have VMClassLoader look in libgcj.jar for
resources as well.

Adding libgcj.jar to the search path in BootClassLoader may
result in weird things happening, I don't know.  But, we could
add ad hoc code to bootGetResource{,s} to search the jar.

I can't work on this for the next couple of weeks.  If it is urgent
someone else will have to do it, I'm afraid.

Note that we already know where libgcj.jar is located, it is stored in
sun.boot.class.path.  I don't think we try to handle relocation here.
Comment 8 Bryce McKinlay 2006-02-16 11:54:42 EST
Unfortunately it doesn't seem like there is an easy fix. If we fix libgcj's
bootstrap class loader to honor the bootstrap classpath, it tries to load
classes as bytecode from libgcj.jar in preference to the native versions in
libgcj.so. The real fix will be to fix the bootstrap classloader so that it
understands native classes (currently it is just a URLClassLoader), but that
isn't trivial.

This bug should probably be moved upstream, and Tomcat patched for FC5.
Comment 9 Tom Tromey 2007-03-30 15:25:48 EDT
What is the status of this?
Having getResourceAsStream work for core classes is probably inadvisable.
Does our tomcat have a workaround in place?
Comment 10 Andrew Haley 2007-03-30 16:26:35 EDT
I think we'll have to make getResourceAsStream work for core classes.  The
Jasper compiler uses this, for example, to resolve core classes as it cimpiles.
Comment 11 Bug Zapper 2008-04-03 12:58:34 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 12 Bug Zapper 2008-05-06 20:22:19 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.