On 6/1/23 07: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,
> bloating its size, and likely reducing system integration (there have been
> concerns about, e.g., worse fontconfig integration in the discussion of your
> 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.
>
> 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.
>
> 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.
I haven’t written Java in years, but my understanding is
that AOT compilation has three major advantages:
1. It reduces the size of total deliverables because the
final executable only includes the libraries it needs.
2. It is the _only_ way to have decent performance on
platforms where JIT compilation is forbidden.
3. AOT-compiled apps start up faster and use less memory.
In short, an AOT-compiled application behaves much more
like one that is written in a native language like C++,
Rust, or Swift. Additionally, AOT-compiled applications
are likely significantly harder to reverse engineer. That
is a bad thing from my perspective, but in the corporate
world it might be desirable.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
