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,
Artem
Thanks,
Omair
