> On 5/17/22 08:33, Stephen Smoogen wrote: > If I understand correctly, the main problem > with the Java ecosystem > is that it is based on redistribution of binaries, not source code. > The focus is on building binaries that can be run on as many > systems as possible, rather than on providing source code that > users compile themselves. This makes a huge amount of sense in > the enterprise software world, but is diametrically opposed to > the open source distribution model. Nowadays, the problem of well said! ty! > redistributing Linux binaries is solved via containers (including > Flatpak/Snap/AppImage/etc), but those both predate Java and are not > useful for those targeting Windows (as many enterprise projects do). We really do not want ending with java in Flatpak. But growing number of projects embedding whole jdk wit project is alarming. > > The result is a culture clash. Rebuilding from source isn’t a matter Correct > of reusing the upstream release tarball or Cargo/pip/etc package, > but of finding whatever VCS commit upstream used and building that > manually. OpenJDK is designed to produce native images that can be > redistributed, rather than be a system-wide installation that other > software depends on. Packaging Java software for any distribution > (not just Fedora) means going against the grain of various upstreams, > and that is a significant amount of work. > > That said, I don’t think the answer is “give up”. A much better > approach would be for the work to be shared between Fedora, Debian, and > other distributions. I believe that this is both doable and necessary. > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! There is an effort of identical reproducible binaries in openjdk usptream. That says, that you build on several systems identical binaries, and thus you can TCK onl one of them. That was created by cowork of Red hat, Debian and others, to solve the TCK issue. Still I'm afraid it will never work properly with dynamic linking. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > This isn’t specific to Java, by the way. JavaScript has similar > problems, and I believe .NET does as well. In the case of JavaScript, > the problem is hidden by the heavy use of transpilers, which result > in the shipping of JavaScript that isn’t actually source code > (in the sense of “preferred form for making modifications”). > > > I would be fine with either dropping TCK certification or only > certifying a subset of the packages. Fedora users almost certainly > do not need it, and the trademark problems can be worked around. You really cant. Ownere of TCK is quite benevolent, but possibel breaking of this agreement will lead to lost of OpenJDK in Fedora > AdoptOpenJDK did so a while back, so there is precedent. Nope. They run full TCK. And before they proeprly passed, they hard hard times wit OpenJDK owner. _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
