Re: Tracking OpenJDK API breakages, static linking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/24/2015 12:08 PM, Stanislav Baiduzhyi wrote:

> 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.

Understood.

> 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.

I don't think this can happen with Fedora because classes must be
compiled from source, and the sources will no longer compile.

>> 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?

The issue is complex.  Today, if you package a Java application, you
have to collect the list of JAR files which need to be on the class path
manually, and put that into the wrapper script which launches the JVM.
If any of your dependent JARs changes and introduces a new dependency,
your application will break.  Copying class files avoids this problem
and can even be automated with tools, so it is very attractive from a
packager perspective.

I think this should be fixed with the Class-Path manifest attribute.
People have claimed that it prevents overriding JAR files using the
-classpath argument, but my tests show that this is not true at all:

  https://github.com/fweimer/classpath-manifest-override

I would like to see Fedora to revisit its stance on the Class-Path
attribute and eventually require that all JAR files in /usr/share/java
have one.

-- 
Florian Weimer / Red Hat Product Security
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel




[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux