GCJ compiled SWT apps mysteriously rummaging the harddrive
Mon Feb 17 22:25:00 GMT 2003
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?
> 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:
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
It does this so precompiled classes can be loaded automatically from
shared libraries so the class byte code doesn't have to be (slowly)
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:
More information about the Java