GCJ compiled SWT apps mysteriously rummaging the harddrive

Mon Feb 17 22:25:00 GMT 2003

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