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
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().
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.
(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 #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.
(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.
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.
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.
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.
What is the status of this? Having getResourceAsStream work for core classes is probably inadvisable. Does our tomcat have a workaround in place?
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.
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.
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