This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GCJ's URLClassloader and 'core' protocol
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