Bug 15474 - libgcj jar file should always be in classpath at runtime
Summary: libgcj jar file should always be in classpath at runtime
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: unknown
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-16 10:49 UTC by Anthony Green
Modified: 2007-04-14 00:59 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-07-14 18:35:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Green 2004-05-16 10:49:30 UTC
We should always put the libgcj jar file in the runtime's classpath.  This
should be OK, even if this file isn't installed.

This code...

public class showString
{
  public static void main (String args[]) throws Exception
  {
    Class c = showString.class;
    System.out.println (c.getResource( "/java/lang/String.class"));
  }
}
                                                                                
...should print something like...

jar:file:///home/green/install/jhbuild-inst/share/java/libgcj-3.5.0.jar!/java/lang/String.class

I propose we stick it on the path just after core:/
Comment 1 Andrew Pinski 2004-05-16 11:29:26 UTC
Confirmed.
Comment 2 Mark Wielaard 2004-05-16 12:06:32 UTC
What is the real reason you want this?
It seems strange to return a byte code array for a class that hasn't been loaded
from byte code in the first place. And adding this makes the bootstrap
classloader (which each and every classloader delegates to before doing its own
lookup) more inefficient.

libgcj.jar is only needed for compiling classes. It is out precompiled header
file so to speak. It isn't needed at runtime. Your proposal means we open an
extra file during startup and do a lookup for each child classloader of the
bootstrap classloader when they want to load a class or resource.

I suspect there is a bug or design flaw in your program if you need this
funtionality. Most likely you need a setting in your program to point it to the
byte code class archive you want to access. If you could post a real snippet of
code that uses this functionality we can most likely provide you with a cleaner
way of doing this.
Comment 3 Andrew Pinski 2004-08-25 09:20:07 UTC
Actually I think it should the way Anthony wants as I think like any good java implemenation we should 
provide the class files also.  Even though we provide most (if not all) of our java class files as already 
compiled code is just an implemenation detail rather than making it the main factor here.
Comment 4 Bryce McKinlay 2004-08-25 12:57:43 UTC
FWIW, I agree with Mark here. We shouldn't be encouraging application developers to make 
unwarranted assumptions about class files being available at runtime. There is no good reason why 
bytecode must be available at runtime.

Unfortunately, if there are important applications that rely for some reason on being able to do this, 
then we may not be able to avoid it. Anthony, what prompted this PR exactly?

If we decide to do this, there is the issue of how to _find_ the right libgcj.jar at runtime. The only 
reliable place is on a path relative to libgcj.so, so we'd have to first find the path to that. Perhaps we can 
do this using dlinfo(). That may be useful in other ways, such as automatically finding the right extdir.
Comment 5 Anthony Green 2004-08-25 16:17:20 UTC
(In reply to comment #4)
> There is no good reason why 
> bytecode must be available at runtime.

I suppose -- but if it's installed, what's the harm?

> Unfortunately, if there are important applications that rely for some reason
on being able to do this, 
> then we may not be able to avoid it. Anthony, what prompted this PR exactly?

The testsuite for a bytecode munging library required it.  I believe it was a
dependency of Groovy.

> If we decide to do this, there is the issue of how to _find_ the right
libgcj.jar at runtime. 

What's wrong with the sun.boot.class.path property we're already depending on in
Ant?

> That may be useful in other ways, such as automatically finding the right extdir.

We have the java.ext.dirs property.

AG
Comment 6 Bryce McKinlay 2004-08-25 17:47:02 UTC
We'll continue to use the existing properties, of course. But how is this
property set? Is it compiled in based on the --prefix when libgcj is built? If
so, thats wrong, because libgcj.so and its associated files could be moved at
runtime.
Comment 7 Bryce McKinlay 2004-08-25 17:52:29 UTC
As Mark suggests, the harm is that adding extra things to the classpath will
cause these .jar files to be opened and searched for classes. That could slow
down runtime start-up and increase memory usage.

Even if our classloaders are smart enough to avoid looking in .jar files for
classes that are compiled in to libgcj.so, they will still have to look when
someone does, for example, a Class.forName() on a non-existant class. This
actually happens all the time when loading ResourceBundles, for example, so even
a well-written application can't easily avoid it.

With well-written classloaders, however, it should be possible to minimize the
overhead - so I'm not totally against this idea if it prooves to be useful. We
just have to be careful about minimizing the cost.
Comment 8 Anthony Green 2004-08-25 18:01:44 UTC
(In reply to comment #6)
> We'll continue to use the existing properties, of course. But how is this
> property set? Is it compiled in based on the --prefix when libgcj is built? 

Yes.

> If
> so, thats wrong, because libgcj.so and its associated files could be moved at
> runtime.

I don't think it's necessarily wrong.  You can override the builtin values at
runtime with GCJ_PROPERTIES, just as you may override the library location with
LD_LIBRARY_PATH.  That being said, there is probably room to improve this scheme.

Comment 9 Anthony Green 2006-07-14 18:35:00 UTC
I ran into another instance of needing this in the jakarta-commons-io testsuite.

It's been two years since the performance arguement against this change was made.   A lot of code has changed since then.  Is it still a valid argument (vs correct and expected behaviour)?

Comment 10 Mark Wielaard 2007-04-13 20:44:47 UTC
Does this recent patch help?

2007-04-13  Andrew Haley  <aph@redhat.com>

        * gnu/gcj/runtime/BootClassLoader.java (getBootURLLoader): New
        method.
        (bootGetResource): Use getBootURLLoader() to load resources.
        (bootGetResources): Likewise.

And does it prevent the feared slowdown?