Re: GCJ compiled SWT apps mysteriously rummaging the harddrive

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Mon, 2003-02-17 at 18:30, Øyvind Harboe wrote:
> SWT apps compiled with GCJ will mysteriously rummage the harddrive.
> 
> I thought I'd post a bit of information about this for posterity. 
> 
> Theory: Could it be that SWT is looking for classes? 

Yes!

> Class.forName("org.eclipse.swt.internal."+names[i]+".OS");
> [...]
> 18:22:01	HelloSWT.exe:112	IRP_MJ_CREATE	C:\temp\test\lib-org-eclipse-swt-internal-motif-OS	FILE NOT FOUND	Attributes: Any Options: Open 	
> 18:22:01	HelloSWT.exe:112	IRP_MJ_CREATE	C:\WINDOWS\System32\lib-org-eclipse-swt-internal-motif-OS	FILE NOT FOUND	Attributes: Any Options: Open 	
> 18:22:01	HelloSWT.exe:112	IRP_MJ_CREATE	C:\WINDOWS\system\lib-org-eclipse-swt-internal-motif-OS	FILE NOT FOUND	Attributes: Any Options: Open 	
> 
> ... lots more ...

This is a feature explained here:
http://gcc.gnu.org/onlinedocs/gcj/Extensions.html

        When trying to load a class gnu.pkg.SomeClass the system
        classloader will first try to load the shared library
        lib-gnu-pkg-SomeClass.so, if that fails to load the class then
        it will try to load lib-gnu-pkg.so and finally when the class is
        still not loaded it will try to load lib-gnu.so. Note that all
        .s will be transformed into -s and that searching for inner
        classes starts with their outermost outer class. If the class
        cannot be found this way the system classloader tries to use the
        libgcj bytecode interpreter to load the class from the standard
        classpath.

It does this so precompiled classes can be loaded automatically from
shared libraries so the class byte code doesn't have to be (slowly)
interpreted.

Maybe it would be good to make this into an option someone could disable
if they know there won't be any precompiled shared libraries.

For the code that does this look into:
gnu/gcj/runtime/natVMClassLoader.cc

Cheers,

Mark