Re: GCJ's URLClassloader and 'core' protocol

[Sal <gcj at svf dot dreamhost dot com>]

Andrew Haley wrote:

> Sal writes:
>  > Andrew Haley wrote:
>  > 
>  > >  > > You want to load statically compiled classes that are already linked
>  > >  > > into an executable, but into a different class loader context?
>  > >  > 
>  > >  > Yes, is this currently possible?
>  > > 
>  > > I doubt it.  
>  > 
>  > Are there any plans to implement it?  Or will it get taken care of under 
>  > the new ABI?
>
> I've never thought about it, to tell you the truth.  It would be
> troublesome to use, because the linker automatcially discards
> unreferenced classes when building an executable. 

Is there a compile flag to force GCJ to compile and link a given set of 
.java files?  Or, I thought if you manually passed the objects in to gcj 
on the command line it would forcibly link them.

> You might as well
> put stuff into a shared library.

I wouldn't mind this... there is just a small problem that arises if I 
go this route.  Let me give an example.

Lets say, I make a custom classloader that allows you to set permissions 
on which classes are loadable.  So I wanted to block all of 
java.util.HashMap, but allow java.util.Vector.  The list of permissions 
of classes which are accessible is defined at _runtime_, say via some 
configuration file.  I want to put this in a library that anyone can use 
in their existing apps.  You would load the main object for your 
application via this custom classloader, and then it would do the rest 
of the work (its transparent to the application).  This is just a 
made-up example, but I'm hoping to do pretty similair stuff.

So, without static linking available every user will then have to build 
all of their applications as shared objects in order to use the 
library... I was hoping to find or develop a way around this.

I hope I'm not being too persistent on this, thanks for your help/input.

- Sal