* [Bug java/15474] libgcj jar file should always be in classpath at runtime
2004-05-16 10:49 [Bug java/15474] New: " green at redhat dot com
@ 2004-05-16 11:29 ` pinskia at gcc dot gnu dot org
2004-05-16 12:06 ` mark at gcc dot gnu dot org
` (6 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-05-16 11:29 UTC (permalink / raw)
To: java-prs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-05-16 11:29 -------
Confirmed.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2004-05-16 11:29:27
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug java/15474] libgcj jar file should always be in classpath at runtime
2004-05-16 10:49 [Bug java/15474] New: " green at redhat dot com
2004-05-16 11:29 ` [Bug java/15474] " pinskia at gcc dot gnu dot org
@ 2004-05-16 12:06 ` mark at gcc dot gnu dot org
2004-08-25 9:20 ` pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: mark at gcc dot gnu dot org @ 2004-05-16 12:06 UTC (permalink / raw)
To: java-prs
------- Additional Comments From mark at gcc dot gnu dot org 2004-05-16 12:06 -------
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.
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug java/15474] libgcj jar file should always be in classpath at runtime
2004-05-16 10:49 [Bug java/15474] New: " green at redhat dot com
2004-05-16 11:29 ` [Bug java/15474] " pinskia at gcc dot gnu dot org
2004-05-16 12:06 ` mark at gcc dot gnu dot org
@ 2004-08-25 9:20 ` pinskia at gcc dot gnu dot org
2004-08-25 12:58 ` mckinlay at redhat dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-08-25 9:20 UTC (permalink / raw)
To: java-prs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-08-25 09:20 -------
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.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
Last reconfirmed|2004-05-16 11:29:27 |2004-08-25 09:20:09
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug java/15474] libgcj jar file should always be in classpath at runtime
2004-05-16 10:49 [Bug java/15474] New: " green at redhat dot com
` (2 preceding siblings ...)
2004-08-25 9:20 ` pinskia at gcc dot gnu dot org
@ 2004-08-25 12:58 ` mckinlay at redhat dot com
2004-08-25 16:17 ` green at redhat dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: mckinlay at redhat dot com @ 2004-08-25 12:58 UTC (permalink / raw)
To: java-prs
------- Additional Comments From mckinlay at redhat dot com 2004-08-25 12:57 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug java/15474] libgcj jar file should always be in classpath at runtime
2004-05-16 10:49 [Bug java/15474] New: " green at redhat dot com
` (3 preceding siblings ...)
2004-08-25 12:58 ` mckinlay at redhat dot com
@ 2004-08-25 16:17 ` green at redhat dot com
2004-08-25 17:47 ` mckinlay at redhat dot com
` (2 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: green at redhat dot com @ 2004-08-25 16:17 UTC (permalink / raw)
To: java-prs
------- Additional Comments From green at redhat dot com 2004-08-25 16:17 -------
(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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug java/15474] libgcj jar file should always be in classpath at runtime
2004-05-16 10:49 [Bug java/15474] New: " green at redhat dot com
` (4 preceding siblings ...)
2004-08-25 16:17 ` green at redhat dot com
@ 2004-08-25 17:47 ` mckinlay at redhat dot com
2004-08-25 17:52 ` mckinlay at redhat dot com
2004-08-25 18:01 ` green at redhat dot com
7 siblings, 0 replies; 10+ messages in thread
From: mckinlay at redhat dot com @ 2004-08-25 17:47 UTC (permalink / raw)
To: java-prs
------- Additional Comments From mckinlay at redhat dot com 2004-08-25 17:47 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug java/15474] libgcj jar file should always be in classpath at runtime
2004-05-16 10:49 [Bug java/15474] New: " green at redhat dot com
` (5 preceding siblings ...)
2004-08-25 17:47 ` mckinlay at redhat dot com
@ 2004-08-25 17:52 ` mckinlay at redhat dot com
2004-08-25 18:01 ` green at redhat dot com
7 siblings, 0 replies; 10+ messages in thread
From: mckinlay at redhat dot com @ 2004-08-25 17:52 UTC (permalink / raw)
To: java-prs
------- Additional Comments From mckinlay at redhat dot com 2004-08-25 17:52 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug java/15474] libgcj jar file should always be in classpath at runtime
2004-05-16 10:49 [Bug java/15474] New: " green at redhat dot com
` (6 preceding siblings ...)
2004-08-25 17:52 ` mckinlay at redhat dot com
@ 2004-08-25 18:01 ` green at redhat dot com
7 siblings, 0 replies; 10+ messages in thread
From: green at redhat dot com @ 2004-08-25 18:01 UTC (permalink / raw)
To: java-prs
------- Additional Comments From green at redhat dot com 2004-08-25 18:01 -------
(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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
^ permalink raw reply [flat|nested] 10+ messages in thread