Strange issue with getResourceAsStream()
Erik Poupaert
erik.poupaert@skynet.be
Wed Jul 2 18:10:00 GMT 2003
> - What all patches HAVE you applied to your SWT codebase, to facilitate
> compilation and static linking? ... Are there any other issues you've run across
> yet and patched yourself?
Not that I remember. I just fix them when I run into them. I'm otherwise a very
disorganized person. I wouldn't know what I'd be doing tomorrow, if you asked me
today.
> - Would the 5 lines added to FileFormat.java have any negative effect on
> non-static linking?
No. They actually don't *do* anything. They just create a few dummy variables that
get initialized with an address that won't be used. The linker, however, will not
know this. He just thinks that he needs to drag the class utilized into the linked
output.
In case of dynamic linking, the linker must link all classes anyway; because there is
no information possibly available of what he can safely kick out; or information on
what classes will or will not be used after deployment of the dll. So everything must
be included. These dummy initializations won't obviously affect anything.
Note that you could force the linker to include everything from SWT without linking
dynamically. You just need to wrap swt.a in a whole-archive linker option.
Your executable would become needlessly bigger, however.
If you looked at the exception thrown, you knew exactly which class the linker
had "forgotten". The dump usually mumbles in C++ style about something missing. Next,
you can go and fiddle with the source, to trick the linker into dragging the missing
class along anyway.
> I'm wondering if it would be safe to sumbit this as
> a patch to the Eclipse folks, or if it is something very static-specific
> like those "System.loadLibrary(...)" calls.
It is very static-specific and very native-specific. They are rather bytecode-wise
people. Why would they be interested?
More information about the Java
mailing list