On 24/09/15 11:56, Florian Weimer wrote:
Some time ago, I started an effort to track API (and ABI) breakages in
OpenJDK releases:
https://bugzilla.redhat.com/show_bug.cgi?id=1094780
https://bugzilla.redhat.com/show_bug.cgi?id=1095309
https://bugzilla.redhat.com/show_bug.cgi?id=1095328
Is something like this useful?
These reports were based on a database which contains all Java
method/class/field references from Java class files contained in Fedora
RPMs. This means that once we know about a removal and have written the
required query, reports can be automated.
I like the idea and I do not want to discourage you, but I see 2 issues
with that:
1. With current overuse of reflection, there is no compile-time safety
any more, and this approach can miss multiple API-level breaks.
2. There are some libraries that may cause huge amount of false
positives, for example pretty much all logging toolkits, which find the
implementation by reflection or by analysing some runtime configuration,
they may have special implementations for outdated backends or for
backends not on the classpath that you'll see as error, while they are
not loaded and not used in runtime.
There is also a weird form of static linking (copying of JAR files into
other JAR files):
https://bugzilla.redhat.com/show_bug.cgi?id=1098237
I think we discussed this before, but the discussion never came to a
real conclusion.
Ouch... Is there some concrete projects to blame? And instead of finding
tricky workarounds and encouraging developers to continue with that
approach, will it not be better to add some build options not to do that
and use normal classpath?
--
Regards,
Stas
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
