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?
