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


Mohan Embar wrote:

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.

By that you mean... the limitation is with loading static objects or shared ones? Or both types?

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.

I think this would work for the most part... the only problem is that as soon as one class references a class that is statically linked, then from that point on, all classes loaded from that class will bypass my custom classloader.


The only way around it is to put every class in the entire application into a .class file... but then it defeats the purpose of using gcj :)

Practically speaking though, one of the applications I am trying to work with is a mathematically intensive raytracer. The performance under native compilation is orders of magnitude better than under a VM... if it was not the case I think your solution would work fine.

Thanks for your help, though.

- Sal


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