[Bug java/15474] libgcj jar file should always be in classpath at runtime

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[green at redhat dot com]

------- Comment #9 from green at redhat dot com  2006-07-14 18:35 -------
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)?


-- 

green at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |green at redhat dot com
   Last reconfirmed|2005-02-23 01:37:18         |2006-07-14 18:35:00
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[mark at gcc dot gnu dot org]

------- Comment #10 from mark at gcc dot gnu dot org  2007-04-13 20:44 -------
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474

[Bug java/15474] New: libgcj jar file should always be in classpath at runtime

[green at redhat dot com]

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:/

-- 
           Summary: libgcj jar file should always be in classpath at runtime
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: green at redhat dot com
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[pinskia at gcc dot gnu dot org]

------- 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

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[mark at gcc dot gnu dot org]

------- 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

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[pinskia at gcc dot gnu dot org]

------- 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

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[mckinlay at redhat dot com]

------- 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

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[green at redhat dot com]

------- 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

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[mckinlay at redhat dot com]

------- 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

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[mckinlay at redhat dot com]

------- 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

[Bug java/15474] libgcj jar file should always be in classpath at runtime

[green at redhat dot com]

------- 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