Re: Re-Launching the Java SIG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> On Fri, 15 May 2020 08:02:34 +0200
> Michal Srb <msrb@xxxxxxxxxx> wrote:
>
> An aside, just to clarify for myself.  That means that all Java apps
> are
> the equivalent of statically linked, right?  And are related to
> things
> like flatpaks and modules?

No, that’s similar to venv everywhere. The language has bytecode-
sharing objects. Java upstreams just got used not to share those
executable objects between projects, not to version them properly, not
to manage their ABI breaks, and to change things in the local copy
instead of contributing changes to the original project.

Well... Java upstreams share their JARs by uploading them to a public Maven repository (Maven Central most of the time). And in the vast majority of cases there are also "source-JARs" (containing source code) uploaded alongside the bytecode JARs. I am simplifying things here a bit, but basically when Java open source projects want to ship their apps, they fetch pre-built dependencies from Maven Central, compile their apps, and bundle everything (app bytecode + pre-built deps) in a tarball. And that's what they ship.
JARs in Maven Central are always versioned, and people who want to use them pick specific versions, so no version ranges... (although technically possible of course) And JARs in Maven Central are immutable, so if you want to use such pre-built JAR, you pick a specific version for your app and it will never change.

What you're describing sounds like the 2005-ish way of developing Java applications :) The Java open source world has evolved since then.


That’s non-free software open source to its extreme. The code is
available for a dev to copy and resell at his next work, but everything
is organised (at the human not technical level) so it’s not possible to
reuse the bytecode directly without paying someone to copy and fork the
original code that this bytecode was generated from in the next
project.

I'd like to know more about this if you don't mind. This is definitely not how open source Java apps are developed.

Thanks,
Michal
 

The practical effect is technical stagnation and market capture by deep
pocket companies.

--
Nicolas Mailhot
_______________________________________________
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
_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux