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:
>
>
> 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...
>>
> [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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam, report it:
>
https://pagure.io/fedora-infrastructure/new_issue