User account creation filtered due to spam.
We should always put the libgcj jar file in the runtime's classpath. This
should be OK, even if this file isn't installed.
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...
I propose we stick it on the path just after core:/
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.
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.
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.
(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
> That may be useful in other ways, such as automatically finding the right extdir.
We have the java.ext.dirs property.
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
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.
(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?
> so, thats wrong, because libgcj.so and its associated files could be moved at
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.
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)?
Does this recent patch help?
2007-04-13 Andrew Haley <firstname.lastname@example.org>
* gnu/gcj/runtime/BootClassLoader.java (getBootURLLoader): New
(bootGetResource): Use getBootURLLoader() to load resources.
And does it prevent the feared slowdown?
Closing as won't fix as the Java front-end has been removed from the trunk.