<AWT Dev> JAWT Breakage in OpenJDK 7/8

[Anthony Petrov]

Hi Omair,

On 7/30/2012 8:40 PM, Omair Majid wrote:
> Hi Artem,
> 
> Thanks for your thoughts and comments.
> 
> On 07/30/2012 08:54 AM, Artem Ananiev wrote:
>> 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.
> 
> Good point. Do you have any suggestion on how to measure the impact on
> startup? Obviously, I cant run this code in a loop and average it out.
> Would a delay of a few milliseconds (let's say 5, as an example) or of a
> few percentage (say, startup of a no-op awt program slowed down by 1%)
> be acceptable?
> 
>>>> 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.
> 
> Fair enough.
> 
> But looking around the OpenJDK mailing lists, I see that many developers
> go to great lengths to ensure programs remain working, even if the
> programs are using unspecified and undocumented behaviour:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401
> 
> Please consider this fix in the same spirit - it keeps third-party
> programs working. In fact, this keeps the behaviour that's documented
> (if not very clearly) working.
> 
>> As for formal JDK specification, is there anything broken in JDK7/8
>> version of JAWT?
> 
> I can't actually seem to find a specification for this. All I see is
> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html
> which is not so much a spec as it is a guide for developers. My concern
> is that, even if i were to write a new application that follows
> everything listed in that guide today, the application would be broken.
> 
>> Is there any wording about loadLibrary("jawt") in the
>> spec?
> 
> There's nothing in the developer guide about loadLibrary("jawt"). I am
> not sure about 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.)?
> 
> This is a great question. Something I don't a good answer to, unfortunately.
> 
> That said, I think some factors are important to consider when trying to
> come up with the answer:
> 
> 1. All the developer docs talk about is linking the native library
> against "libjawt.so". Nothing about a System.loadLibrary("jawt") is
> mentioned in the example. The demo is normally an ideal program, so this
> (to me, at least) says developers should not use System.loadLibrary("jawt").
> 
> 2. The JDK/JRE directory is designed to be relocatable. And applications
> aren't supposed to be installed into it. Together, I think that means
> that programs aren't located inside the JDK/JRE and don't know the path
> to it. The only way linking to a library inside would work would be
> either if the library was already loaded or the JRE would be able to
> find it.
> 
> Together, I take this to mean that what the existing applications are
> not responsible for invoking either System.loadLibrary("jawt") or
> linking to the exact path of the libjawt.so.
> 
>> I'm even not sure that
>> there is a specification that declares System.loadLibrary("jawt") to
>> work everywhere.
> 
> Well, the developer docs explicitly talk about linking against the
> native awt library (and provide the name as "libjawt.so").
> System.loadLibrary is the java-version of that.
> 
> If you still think preloading libjawt.so is a non-starter, then I
> believe the next best option would be to modify the java launcher so it
> can find libjawt.so. The only problem is the "fix" will be far from the
> problem, and may get ignored if, say, libjawt.so is moved around.
> 
> What do you think is the best option?

I agree with Artem that pre-loading the jawt library unconditionally is 
a bad thing to do, because even tiny milliseconds matter. Besides, a 
fair amount of Java GUI applications simply don't require jawt, so this 
pre-loading looks unnecessary.

I also agree with Omair and Mario on that old applications cannot be 
modified sometimes, and therefore, whilst it makes some sense to update 
the doc and suggest developers to System.loadLibrary("jawt") in their 
app, we should still make sure old applications work as expected.

I've also read the discussion that took place on build-dev@ regarding 
this issue, and it seems to me that adding an RPATH entry to launchers 
is the right solution for this issue. We may want to also add a comment 
there and state that this entry is added specifically to address the 
jawt use case. Perhaps it makes sense to also add a comment somewhere in 
a jawt makefile to state that we rely on this RPATH entry in the 
launcher. This way we can ensure that even if the jawt library is moved 
around, the relevant RPATH entry gets updated accordingly as well.

--
best regards,
Anthony