Announcement

Collapse
No announcement yet.

Fedora's Java Packages Have Fallen Into Rough Shape

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by kpedersen View Post

    That was the plan in theory but in practice it doesn't quite work. For example a large amount of dependencies are not pure Java and provide some native JNI "glue" code to link it to the C libraries.

    Java programs would need to bundle Windows (x86, amd64), macOS (amd64, aarch64), Linux (x86, amd64, aarch74, armv7), FreeBSD (x86, amd64, aarch74, armv7) glue libs and that would still only be a tiny fraction of platforms. It doesn't even consider versions, different libc, etc.
    I guess the other reason is, they also want to conserve disk space by reusing even pure java libraries.

    Comment


    • #12
      Originally posted by RahulSundaram View Post

      OpenJDK is actually very well maintained in Fedora and has a dedicated Red Hat team with upstream contributors. The problems are with packages outside of those core ones. Also, I don't think OpenJDK is installed by default in Fedora.
      This is my "java --version" output on Fedora 34 workstation:

      openjdk 11.0.12 2021-07-20
      OpenJDK Runtime Environment 18.9 (build 11.0.12+7)
      OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7, mixed mode, sharing)

      If it gives this output, that means it's preinstalled on the distribution. I can also see it enabled in Libreoffice.

      Comment


      • #13
        Originally posted by user1 View Post

        This is my "java --version" output on Fedora 34 workstation:

        openjdk 11.0.12 2021-07-20
        OpenJDK Runtime Environment 18.9 (build 11.0.12+7)
        OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7, mixed mode, sharing)

        If it gives this output, that means it's preinstalled on the distribution. I can also see it enabled in Libreoffice.
        OpenJDK 11 is bloody ancient. For a bleeding edge distribution this is an embarassment.

        Comment


        • #14
          Originally posted by Sonadow View Post

          OpenJDK 11 is bloody ancient. For a bleeding edge distribution this is an embarassment.
          Well, it was the latest LTS version up until recently. Other distributions also ship version 11, including bleeding edge ones like Opensuse Tumbleweed. Even on Ubuntu, where OpenJDK is not preinstalled, version 11 is considered the only one officially supported by Canonical. OpenJDK 17 is now the latest LTS version, but it was released only a few days ago.
          Last edited by user1; 28 September 2021, 08:27 AM.

          Comment


          • #15
            Originally posted by user1 View Post

            Well, it is currently the latest LTS version. Other distributions also ship version 11, including bleeding edge ones like Opensuse Tumbleweed. Even on Ubuntu, where OpenJDK is not preinstalled, version 11 is considered the only one officially supported by Canonical.
            Actually.. 17 is the latest LTS version.

            Comment


            • #16
              Originally posted by caligula View Post

              Actually.. 17 is the latest LTS version.
              Yeah, already fixed my comment

              Comment


              • #17
                I don't think there's much point packaging up something like Maven as an RPM. Java developers typically download their own Maven version. And the need to have it in the Fedora repo diminishes even further with the increased adoption of the Maven Wrapper, which is inspired by the Gradle Wrapper, and planned to be mainlined into Maven soon. With the Maven Wrapper, a project will download the required Maven version on-demand (and install it somewhere in the `$HOME/.m2` folder) and as-needed during build.

                And honestly, Java developers typically download the JDK versions that they need for their projects themselves from sites such as https://adoptopenjdk.net.

                Also, IntelliJ IDEA, the most popular Java IDE as far as I know, includes a JDK of its own.

                So there's no real need to have any of the Java stuff managed in the Fedora repo, especially since the stuff in the repo tends to get outdated quickly. Also, the opposite is sometimes true: for certain legacy projects, an older JDK such as JDK7 might be needed, which might not be in the repo of newer Fedora versions anymore.

                My advice to the Fedora maintainers: leave all the Java stuff out and save yourselves the maintenance burden. Java developers know how to download and install the parts of their development toolchains themselves.

                And the exact same goes for Ubuntu and every other Linux distro, to be honest.

                Comment


                • #18
                  Originally posted by kpedersen View Post

                  That was the plan in theory but in practice it doesn't quite work. For example a large amount of dependencies are not pure Java and provide some native JNI "glue" code to link it to the C libraries.

                  Java programs would need to bundle Windows (x86, amd64), macOS (amd64, aarch64), Linux (x86, amd64, aarch74, armv7), FreeBSD (x86, amd64, aarch74, armv7) glue libs and that would still only be a tiny fraction of platforms. It doesn't even consider versions, different libc, etc.

                  You then have weird things like generating the native glue code on the fly but then you need an entire C toolchain and development libs (I think the OpenGL bindings, JOGL gluegen does this).

                  Honestly, all this crap with bindings is not unique to Java either and is why C is still one of the most popular languages, warts and all.
                  Can you please show me just one Java app, that doesn't bundle its own [native] dependencies? I've been working as a Java developer for at least 7 years and I've never seen a java app (be it a server webapp, or a thick swing/jfx client) that doesn't bundle them. And if such a badly written app exists, burden should be placed on the developer of the app, not distro maintainers, that's crazy.

                  Plus, the problem they are discussing goes much further than the native bindings. Distros package things like guava, apache commons.... libraries like these do not depend on any native code whatsoever. No JNI, no JNA, no libffa, nothing. Again this whole thing is ridiculous.

                  As an anecdotal evidence - I've built apps previously that relied on various libraries, and native bindings, like for example OpenCV, and I've always included everything including the native-built artifacts in the final distributed binaries. That's just how Java works. Yes, Java invented flatpak before it was cool.

                  Comment


                  • #19
                    Originally posted by Sonadow View Post

                    OpenJDK 11 is bloody ancient. For a bleeding edge distribution this is an embarassment.
                    That doesn't make any sense. OpenJDK 17 is LTS only since 14th of September, it is perfectly reasonable to have 11 as the default. If you want the latest version, you can install the package called conveniently enough openjdk-latest-openjdk. Also Fedora doesn't claim to be a bleeding edge distribution.

                    Comment


                    • #20
                      Supporting Java at times turns into a pure nightmare. Please note debian does not provide a Eclipse package any more. If you want to use Eclipse on debian its either the flatpak or the upstream cross distribution package(that only sometimes works).

                      https://wiki.eclipse.org/Eclipse/Ins...#Install_a_JVM
                      A Java 11 or newer JRE/JDK is required, LTS release are preferred to run all Eclipse 2021-09 packages based on Eclipse 4.21, with certain packages choosing to provide one by default. The Installer now also includes a JRE--consider using the Installer. Please see 5 Steps to Install Eclipse

                      https://www.eclipse.org/downloads/
                      The Eclipse Installer 2021‑09 R now includes a JRE for macOS, Windows and Linux.

                      That right eclipse project maintains its own version of java runtime. that all it code it tested with. Eclipse is not tested up stream that it works with general openjdks any more. Yes the automated testing of Eclipse has reduced to 3 platforms one version of java.

                      ep421I-unit-mac64-java11 macosx.cocoa.x86_64
                      ep421I-unit-win32-java11 win32.win32.x86_64
                      ep421I-unit-cen64-gtk3-java11 linux.gtk.x86_64

                      Yes where these are all the same Java11 they are the bundled JRE not the system provide one. Yes the bundle JRE can have some of Eclipse projects own patches.

                      Yes you look at the automated testing you see a few extras like the following
                      ep421I-unit-cen64-gtk3-java16 linux.gtk.x86_64
                      ep422I-unit-macM1-java17 macosx.cocoa.aarch64
                      ep422I-unit-cen64-gtk3-java17 linux.gtk.x86_64
                      But failures with these don't prevent eclipse package release. Of course those failures are going to drive you nuts as you attempt to use eclipse.

                      There are a lot of packages fedora includes that debain has dropped for this reason that the upstream now only support 1 particular version of Java and the application has a flatpak or other installer that makes sure application installed with its matching JRE.

                      You know something is wrong when in a particular area fedora has more packages than Debian and arch combind this is the true case with Java libraries and applications include in Fedora. Both debian and arch have pruned a lot of the trouble java packages to maintain. Yes Eclipse is one of those troubled packages another trouble package is android studio both have been pruned from the debian and arch distributions so they are no longer distribution maintainer problem.

                      There quite a lot of java applications/libraries that due to upstream that only testing against a limited JRE come a pure time consuming nightmare causing burn out for maintainers if they are asked to maintain them. Debian and Arch and even Ubuntu on a lot of these applications to users are like flatpak/snap/own installer it we are not providing those any more and will not be dealing with the failures because we don't provide it.

                      So fedora is a little behind the times here.

                      The idea of one binary that runs everywhere using independently provided runtime the hard reality this has mostly not worked out be it .net or java or many other options.

                      Comment

                      Working...
                      X