Marián,I echo your concerns, however, regarding jars with multiple bytecode versions, aren't java rpm expected to build their sources with one specific JDK? (per the guidelines) how can multiple bytecode version end up in the JAR in that scenario?
Regarding the proposal as a whole, I think the proposal idea makes a lot of sense, but for apps depending on system jar libraries, there should be a way to specify that the app depends on a specific java bytecode version range. System libraries packages could provide compatibility packages, so couldn't those apps just depend on those compatibility packages instead? That can become a maintenance burden for those libs, though.
Thank you, Carlos. On 4/30/24 07:56, Marián Konček wrote:
On 25. 4. 2024 17:46, Michel Lind wrote: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.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]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=== 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.$ 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.fc41What 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.You are right, throughout these sections I was talking mostly about the runtime environment rather than the development kit.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.=== 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.Best regards, -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
