This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCJ's URLClassloader and 'core' protocol


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/





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]