On 25. 4. 2024 17:46, Michel Lind wrote:
On 4/24/24 11:14 AM, Aoife Moloney wrote:
Wiki -
https://fedoraproject.org/wiki/Changes/Drop_Mandatory_Requires_on_JRE
Announced -
https://discussion.fedoraproject.org/t/f41-change-proposal-drop-mandatory-requires-on-jre-system-wide/114186
[snip]
=== Context ===
Java packages are compiled using `javac` into `.class` files and
composed into `.jar` archives. Jar archives can be used as compile or
runtime dependencies for other packages or can be directly executed
with the java command provided by a JRE.
Jar archives can be executed using the command: `java -jar ${FILE}`.
This command executes the `main` method either specified via CLI or
specified within the Jar manifest file.
Java packages, which serve as libraries only, lack the `main` method
and are not executable. Therefore, there is no requirement on any
specific JRE imposed by the library implicitly.
Sort of... bytecodes do get introduced over time, right? While in
practice I expect nobody will try and running, say, anything older
than Java 7 (JSR 7 introduced invokedynamic), should there be a way to
specify a generic minimum runtime version? I guess the tricky thing
here is that different JDKs might not be packaged in a way where they
all implement a common virtual provide that can be targeted
$ fedrq pkgs -P java-headless
java-21-openjdk-headless-1:21.0.2.0.13-3.fc41.x86_64
$ fedrq pkgs -P java-headless -F provides
libjsvml.so()(64bit)
libsyslookup.so()(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
lible.so()(64bit)
libjava.so()(64bit)
libjsig.so()(64bit)
libverify.so()(64bit)
java-21-openjdk-headless(x86-64) = 1:21.0.2.0.13-3.fc41
config(java-21-openjdk-headless) = 1:21.0.2.0.13-3.fc41
java-21-headless = 1:21.0.2.0.13-3.fc41
java-21-openjdk-headless = 1:21.0.2.0.13-3.fc41
java-headless = 1:21.0.2.0.13-3.fc41
java-openjdk-headless = 1:21.0.2.0.13-3.fc41
jre-21-headless = 1:21.0.2.0.13-3.fc41
jre-21-openjdk-headless = 1:21.0.2.0.13-3.fc41
jre-headless = 1:21.0.2.0.13-3.fc41
jre-openjdk-headless = 1:21.0.2.0.13-3.fc41
Every major JDK version introduces a new bytecode version. The bytecode
version number is part of the .class file format. If an older JVM is
attempting to load a .class with a higher bytecode version than it
supports, it fails without attempting to load it.
What you propose makes some sense but I am not completely convinced it
is a good idea. First of all we need to agree on the meaning of the
Requires field and what it means to install a package.
* Does one install a package just to look at the files / contents /
bytecode of the classes? In that case there is no strict requirement on
the bytecode interpreter (= JVM).
* Does one install a package to **use** it? To load the bytecode using
some JVM? In that case adding a requirement to the package turns a
runtime failure (to load the class) into an RPM transaction.
Even if we would agree on the second option, there is another problem:
an .rpm archive can contain multiple .jar files. a .jar archive consists
of multiple .class files. Bytecode version is specified for each .class
file. While a generator that walks over the whole contents and extracts
the bytecode version numbers could be implemented, should it simply
reduce the numbers to a maximum? That would possibly prevent the users
from some valid use cases. Should the packaging guidelines specify that
an .rpm package may install at most one .jar archive? Although rare,
there are cases when even .class files in a single .jar have different
versions. Most notable case: module-info.jar with bytecode version for
Java 9 and the rest of the source files with version for Java < 9.
Looking at it, I see many questions and potential problems but I also
find this idea intriguing, to have a generated `Requires: java-bytecode
>= 55` or something like that.
This would also require all the JVMs to Provide such a field.
The spirit of this proposal, however, is to allow more freedom for the
package users at the cost of disabling some implicit behaviours.
=== Different JDKs ===
This proposal is also related to the topic of different JDKs.
Developers may want to use or build packages which use a JDK different
than the one provided by the `java-<N>-openjdk` package. After this
proposal was implemented, they would be able to depend on Java library
packages with no introduction of the OpenJDK package.
=== Rationale ===
Java libraries are more similar to native libraries than to libraries
written in dynamic scripting languages. They are compiled to a
bytecode and are not executable. Java libraries can be used as
dependencies for any Java application and there is no implicit
dependency on the system default JDK.
Java applications, on the other hand, are expected to be tested and to
work with the system JDK and from the user's perspective: after
installing an application they must be able to simply run the binary.
Therefore the `Requires` on the system JDK is kept for Java
applications.
Would this be clearer if it says "the JRE from the system JDK"? Since
the apps are not actually pulling in the full JDK itself.
You are right, throughout these sections I was talking mostly about the
runtime environment rather than the development kit.
Best regards,
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Marián Konček
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
