----- Original Message ----- > > Won't this change break systems which don't have libpcsclite.so.1? > Changes like this need to be thought through. What happens when > libpcsclite.so.2 comes out? > As for API changes, shouldn't there be some compatibility requirement on > APIs as libpcsclite.so evolves? > Valerie > > On 04/24/13 04:05, Florian Weimer wrote: > > On 03/01/2013 11:30 AM, Severin Gehwolf wrote: > >> Hi, > >> > >> The bug for this review request is at: > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142 > >> > >> In PlatformPCSC.java unversioned native libraries are loaded by default > >> if no system property is specified. This could lead to a JVM crash if > >> the API of the native library changes, but the Java code still relies on > >> old API. The fix is to load versioned shared libraries instead. > > > > Hmm. Why doesn't the "j2pcsc" library link against the right version > > of libpcsclite.so? > > > >
We've just shipped the patch in IcedTea 2.4.5 [0] but I see the attempt to upstream it seems to have died out. As has already been mentioned on this thread, libraries should have their version increased when the ABI changes. Thus, a libpcsclite.so.2 or later would indicate a different ABI to what the JDK PCSC code was written for. Now, it may be that the code also works fine with .2, but from my perspective, I'd rather the JDK fail with an error message and someone manually points it at a working .2 (and hopefully gives feedback that it's all good), than the JDK grabs any old version of the library and then crashes when the ABI doesn't match. That not only looks worse, but it's potentially harder to debug as well. Are there further issues with this patch or am I ok to push it upstream? Severin works for Red Hat, so the corporate OCA applies. [0] http://bitly.com/1d7AJHj Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
