Re: Re-Launching the Java SIG

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

 




On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote:
Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit :
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.
If Java finally left the stone age, there should be no problem building
the same artefacts in rpm, installing them in a central place like
%{_datadir}/java or %{_libdir}/java, and making it a package other java
software can buildrequire. We managed it in Go, and we did not even
have a language versionning infra to build upon.

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.
Free software is end user not dev oriented. Stallman wanted his printer
driver to work. The GPL gives rights to the recipient. As long as the
toolchain is broken enouth even huge downstreams like distros are
unable to rebuild the source easily, you have something that may be
open source, but does not function as effective free software.


The "toolchain" isn't broken, other than Gradle developers not caring about backwards compatibility but... It works for them, just as constantly breaking internal kernel APIs works for the Linux kernel or running X. Org as user does for Fedora. No-one involved with the Linux kernel or the distros has a right to complain, y'all do it to other people all the time.


The only thing I remember Gradle downloading when I built it locally is a previous beta build in order to build the end final release. Maybe there were a few other things I'm forgetting, someone else can correct me.



And when downstreaming is broken upstreaming is broken too (who will
bother contributing to an upstream when things do not flow the other
way?).


Yeah, no.


My software didn't magically break just for Fedora because of some bug in my software. It broke because Fedora decided they wanted to do something nearly no Linux distro does... something that has been the defacto standard for many years.


Willing to bet money Gnome has received a great many bug reports because of extensions Linux distros ship by default as well.


...and there are plenty of Open Source projects that don't have packages yet people contribute to them. This isn't the early 2000 when barely anyone has internet and sites like Github didn't exist. Sure, a distro package increases visibility still, but it isn't all that matters. Heck, the Windows 10 calculator app is sitting at over 1100 contributors right now on Github.


The point here is not that upstream should be blindly trusted, but rather that downstream's poo **does*** stink and affect other people, even those that don't specifically package for your distro.


As spot wrote a long time ago, the only useful form of open source for
Fedora (and a lot of other entities) is free software.

_______________________________________________
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