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
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.
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
> other JAR files):
> 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
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:
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
Florian Weimer / Red Hat Product Security