<AWT Dev> JAWT Breakage in OpenJDK 7/8

Artem Ananiev artem.ananiev at oracle.com
Mon Jul 30 05:54:01 PDT 2012

On 7/25/2012 6:40 PM, Omair Majid wrote:
> On 07/25/2012 05:33 AM, Artem Ananiev wrote:
>> Hi, Omair,
>> I don't remember the exact reason for LD_LIBRARY_PATH changes, but it's
>> very unlikely they can be reverted. Your proposed patch will probably
>> solve the problem (I haven't checked, though), but it has major
>> side-effect: increased startup time.
> I am not sure how significant that would be. It's a tiny library after
> all - only 0.5KB on my machine.

I would be really surprised if it takes 1 sec to load, but even few 
milliseconds matter during startup.

>> That's why I vote for just updating JAWT documentation to include
>> System.loadLibrary() call in the application code.
> While I agree that the docs should be updated, I dont think it's
> sufficient: existing applications that rely on this are currently
> broken. If the applications can not be modified (third-party or
> read-only) then this (for all intents and purposes) breaks the promised
> "binary compatibility" of OpenJDK :(

What is "binary compatibility"? It's impossible to make any change in 
JDK and don't break someone's code, that relies on unspecified behavior. 
My personal attitude to "binary compatibility" is the same as to "bug to 
bug compatibility", which was never supported by JDK.

As for formal JDK specification, is there anything broken in JDK7/8 
version of JAWT? Is there any wording about loadLibrary("jawt") in the spec?

If an application developer creates an application and links it to a 
library, who is responsible for the library to be accessible by the 
native loader (PATH, LD_LIBRARY_PATH, etc.)? I'm even not sure that 
there is a specification that declares System.loadLibrary("jawt") to 
work everywhere.



> Thanks,
> Omair

More information about the awt-dev mailing list