On 24/09/15 13:00, Florian Weimer wrote:
I don't think this can happen with Fedora because classes must be
compiled from source, and the sources will no longer compile.
Ah yes, that is true.
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.
Well that is still error-prone approach. Classpath scanning goes with
"first found wins", which means that the version of your jar will not be
loaded if there is similar class earlier on the classpath. BEA WebLogic
used to do updated based on this principle. So I do not believe this
approach helps anyone. As we can see on bigger projects, proper
applications are just packaging everything they need with them under
single root, or into some specific osgi bundles, and then using *
classpathes.
I think it would be amazing to create some new type of container for
Java apps, but I know I'll get beaten for saying that on any
distribution packaging mailing list.
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.
Just tested that, I'm little surprised that they are actually loaded
recursively. Thinking of possible corner-cases, again taking logging
toolkits as example, there may be lots of compile-time dependencies, but
most of them may not be needed in run-time (or even not wanted), how
will it behave then if all of them will be declared in manifest? Or even
how will it be handled by RPM?
--
Regards,
Stas
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
