Linking against the JVM

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

 



Hi,

I recently ran across a few bugs having to do with packages linking
against the JVM. Basically, packages are trying to link directly against
a JVM (libjvm.so) and are filing bugs when appropriate LD_FLAGS to do
that are not obvious:

- https://bugzilla.redhat.com/show_bug.cgi?id=449456
- https://bugzilla.redhat.com/show_bug.cgi?id=740762
- https://bugzilla.redhat.com/show_bug.cgi?id=1112012

Fedora (and JPackage) guidelines try to makes it easy for users to use
alternate JVMs. They can use alternatives and/or environment variables
to control which JVM is used. This linking directly against a libjvm.so
runs counter to that.

I talked to Mikolaj who thinks that ignoring the user-specified JVM
(either through alternatives or JAVA_HOME) is a bug and can lead to
surprises where an application is not using the JVM you may think it's
using.

This linking will also cause things to break when Java versions are
bumped and we go from java-1.x.0-openjdk to java-1.y.0-openjdk or even
if the OpenJDK directory changes name.

However, others, including Andrew Haley have suggested that it may lead
to broken programs (and other surprises) when applications end up with a
JVM that's different from what they expected.

Mikolaj thinks it would be better if the packages did one of the
following (in order of preference):
1. Fix upstream - convince them to respect $JAVA_HOME and use dlopen(3)
2. Maintain Fedora-specific patch for dlopen(3)
3. App should use its own linker magic depending on java home (eg, shell
   script checks $JAVA_HOME and sets LD_PRELOAD)
4. Fail if $JAVA_HOME is set

And he prefers to avoid:
1. Java .so in default linker paths
2. Linker tricks to avoid depending on Java home (these are just
   workarounds for Java .so not being in default linker paths)
3. rpath

What do others think about this? If there is some sort of consensus
about this, should the packaging guidelines be amended to make this
explicit?

I also talked to Mikolaj about making some sort of mini-library to make
it easier to implement fedora-specific patch to make it easier to
dlopen(3) and use a libjvm.so. Is this something that others will find
useful?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
--
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