This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GCJ's URLClassloader and 'core' protocol
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: Sal <gcj at svf dot dreamhost dot com>, Andrew Haley <aph at redhat dot com>
- Cc: java at gcc dot gnu dot org
- Date: Mon, 28 Jun 2004 11:15:57 -0500
- Subject: Re: GCJ's URLClassloader and 'core' protocol
- Reply-to: gnustuff at thisiscool dot com
Hi People,
>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. You might as well
>put stuff into a shared library.
That approach won't currently work on Windows.
Here's a hare-brained brainstorm which might not be based in reality - I don't know
whether this will work in real life:
- compile the classe(s) in question into .class files
- compile the .class files into the executable as <i>resources</i> rather
than executable code
- at runtime, get the byte array for the classfile data for these
compiled-in resources / classes and use ClassLoader.defineClass() to create
them
Of course this would mean that they would be run under the interpreter
rather than as machine code, but it might be a quick and dirty way to
accomplish what you want, provided the functionality exists and works
and that I'm not completely off the mark.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/