Description of problem: Class.getResource() in gcj currently returns null for resources that do exist. Version-Release number of selected component (if applicable): All How reproducible: Always Steps to Reproduce: 1. Instantiate this class from a main(): class NonStaticClass { public NonStaticClass() { System.out.println(getClass().getResource("/java/lang/Object.class")); } } Actual results: stdout shows 'null' Expected results: It should show the file path. e..g with the IBM jvm, it shows: jar:file:/usr/lib/jvm/java-1.4.2-ibm-1.4.2.3/jre/lib/core.jar!/java/lang/Object.class
This is marked "All" for hardware, but AFAIK this is a 32-bit problem. Fixed upstream, awaiting a rebuild.
This returns null even with svn head gcj, because the code is requesting Object.class. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474 Deepak, did your program need some standard class file? Or was this just a convenient example?
Looking at PR15474, is adding the jar file to the classpath the only way to "fix" this? I can understand how expensive that is given a multi-megabyte jar file. Can't just the getResource() for natively implemented classes try to map the DSO back to a corresponding jar file, e.g. using the database?
The database maps class files to DSOs. There is no map in the opposite direction because the is no need for one. Adding the jar file to the classpath would work, but I'm not convinced that there is any real purpose to this. What is the real problem?
(In reply to comment #2) > This returns null even with svn head gcj, because the code > is requesting Object.class. See > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474 > > Deepak, did your program need some standard class file? > Or was this just a convenient example? I discovered this issue when running tests for plexus-utils. See line 209: http://svn.plexus.codehaus.org/browse/plexus/trunk/plexus-utils/src/test/java/org/codehaus/plexus/util/FileUtilsTest.java?r=3786 The testCopyURLToFile() there is aborting with a NullPointerException as soon as it reaches line 209.
In re comment #3: this is only a problem for the core classes. (Well, it could be a problem for other shared libraries, but in those cases the user is typically specifically using gcj, and should know about the weirdnesses. So we can ignore that.) Could we change this test instead? Or perhaps run the test in a different way? Putting libgcj.jar onto the boot class path is pretty heavy just to make a single test pass. To be precise, of course, per the other PR we know of other code that wants this. But the overall number of such places is small...