2012/7/30 Artem Ananiev <artem.anan...@oracle.com>:
> 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.
Hi Artem,
While I share *some* of your concerns and I'm sympathetic with your
point of view regarding backward compatibility, I have to play for
once the role that you guys have played for many years: many, many
applications are simply not fixable...
Removing the jawt.so library seems to be problematic for those
applications (even if I think I for first wanted to see this library
be linked just on demand), and to be honest, I don't see a big issue
here with the proposed patch, it looks ok to me.
Maybe there is some other reason why this is not acceptable than a
couple millisecond delay (trade backward compatibility for a couple
millisecond start up time doesn't seem right, though)?
I also believe that Omair proposed another approach on the build-dev
(Omair, please correct me if I'm wrong), based on changing the LDFLAGS
rather than explicitly load the library in the awt initialisation
code, this may be a better solution for you.
In either case, I would love to see this sorted out, since we're
getting real world applications involved in that, and it would be
unfortunate if we would only fix this issue in IcedTea distributions
and not get this upstream instead.
I would really appreciate if you could either suggest an alternative
fix that would work for you, or sync with us and the Build team for a
better approach if possible?
Thanks for your input,
Mario
--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/
Please, support open standards:
http://endsoftpatents.org/
