<AWT Dev> xawt/libmawt.so and headless/libmawt.so

David Holmes David.Holmes at oracle.com
Wed Apr 20 17:29:37 PDT 2011

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?


More information about the awt-dev mailing list