On 6/1/23 13:33, Kevin Kofler via devel wrote:
Jiri Vanek wrote:
At elast providing ofjava/openjdk is definitley out of scope.
I do not think a Provides would be a trademark violation. It is a part of
the standard procedure for renaming a package. But you would have to ask Red
Hat Legal for a definite answer. I am not a lawyer.
That said, there might not even be a trademark issue at all, at least for
"OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing
to:
https://openjdk.org/legal/openjdk-trademark-notice.html
As you wrote about the liberty of choice between temurins and fdeoara ona
- can you be a bit more specific? Afaik if the builds are similar, we have
mcuh less possibility of some fedora-specific bug.
But it also means that I no longer have the option to use a Java that does
not bundle several libraries, possibly including security vulnerabilities,
Nope. That is actually somehting what should get better. Java is good security issues handling.
bloating its size, and likely reducing system integration (there have been
concerns about, e.g., worse fontconfig integration in the discussion of your
And have it proven to be true? I doubt.
previous Change proposal). There is now just the "choice" between a Fedora
package with everything bundled and third-party packages with also
everything bundled.
I once wrote,m that wworked 10years to enable dynamic linking, and yes,
all is upstream, but there are limitations which can not be overtaken -
major is ahead of tie comilation. If you can do it right, you cnanot have
dyanmic linking.
Wait, Java does real AOT compilation now? Or are we talking about that
strange "feature" you already brought up in the old discussion, where you
basically just prepend a JRE to a JAR and ship that as a "compiled"
executable? That "feature", to be honest, I had never heard of before you
folks brought it up.
It started with jlink, and then javaaot had shown the way, and now this lives in graal and madrel/quarkus projects. And even spring boot is working on theirs AOTcompiler.
I'm only observer for Mandrel project, but it seems to be working, although still quite a lot of work is ahead.
As far as I can tell, nobody in the Java world uses it. It breaks the "write
once, run anywhere" promise and brings us no real advantage over having the
JRE and the JAR separate.
I agree with you, adn I dont like the aot of java. However business seems to be going there, otherwise several big companyes would not invest so heavily to graal, mandrel, quarkus and springboot.
The benefits and reasoning are disputable. As I'm on your side on this I can not defend them.
Still, meas casual javadevloper, am delivering all - jars, wars, apks, jlinked iamges and also aot compiled binaries as needed,a s each is usefull for different customer cases. Untill static build was introduced to fedora, I had to use 33rd
party java for jlinked and aot compiled images.
It is definitely not useful for me because our customers all run Windows,
not Fedora or any other GNU/Linux. So really it makes no difference for me
whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking)
or on all GNU/Linux (static linking), they will not run on our customers'
computers anyway, making that "feature" entirely useless either way.
We have a few ways to deploy our JARs to our customers, but none of them
involves turning them into native executables through (either real or fake
as described above) AOT compilation.
The goal should still be to have fedora rpms properly integrated in
fedora, and usable, as any other java onthe world, without hacks.
Sorry, but I believe that the old packaging was exactly that, "properly
integrated" and "without hacks", whereas I have to politely disagree about
the new packaging having those properties.
The integration wll remain intact. But I gusess we disagree on definition on integration.
The "only" take away are static linkings of java-crucial libraries (and my opinion as JDK developer is still that it is better), and now older build chain will be added. Except the new flags and gcc - which were sometimes hard to adapt, and
we excluded most of them - I do no see much lost.
J.
_______________________________________________
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
