Alan Bateman said the following on 04/20/11 23:10:
David Holmes wrote:
:
The only glitch I see with that is that the
GraphicsEnvironment.getHeadlessProperty code is Java code while to
check for the native lib we'd need native code.
The VM code is just stat'ing the library to check that it exists. It
looks like we could do the equivalent in
GraphicsEnvironment.getHeadlessProperty without needing any native code.
But the file to be stat'd is OS dependent is it not?
It's doable I guess, but is it worthwhile? What problem are we trying
to solve?
In the modules build today then the JDK's native libraries still go into
lib/<arch> but this may change so that a module's native libs go into
the module's tree. Any re-organization or changes to the layout of
native libraries is going to expose dependencies and other issues but
hopefully that we can't overcome.
Not sure how this use of sub-directories impacts that at all. Surely
within the AWT module (assuming such a beast exists) it can organize its
files how it wants?
Cheers,
David
