Announcement

Collapse
No announcement yet.

Java JDK 9 Finally Reaches General Availability

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

  • Java JDK 9 Finally Reaches General Availability

    Phoronix: Java JDK 9 Finally Reaches General Availability

    Java 9 (JDK 9) has finally reached general availability! Following setbacks, Java 9 is officially available as well as Java EE 8...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I'm a little sad AoT was relegated to experimental status, if would have been a killer feature.
    Also, no more Java embedded for ARM, which is puzzling.

    Edit: It seems everything ARM related has been moved to OpenJDK. I'm not sure if that's good enough, you usually need Oracle's implementation for proper encryption and other goodies.
    Last edited by bug77; 23 September 2017, 10:46 AM.

    Comment


    • #3
      Tested it with a relatively simple (but important) Java Web Start application that I need to use for work and.... the application runs but breaks silently. I don't know (or really care) if the bug is in the new JRE or in the application, but back to Java 8 until it's fixed.

      Comment


      • #4
        Jay!!

        Comment


        • #5
          Originally posted by chuckula View Post
          Tested it with a relatively simple (but important) Java Web Start application that I need to use for work and.... the application runs but breaks silently. I don't know (or really care) if the bug is in the new JRE or in the application, but back to Java 8 until it's fixed.
          A lot of internal APIs that should have never been exposed are now properly stashed away. Many applications will break because of that, but this had to be done at some point.
          I feel your pain if you get bitten, but in your case, you only need a JRE and as long as the application you're running doesn't require Java 9, JRE8 will do just fine.

          Comment


          • #6
            Originally posted by bug77 View Post

            A lot of internal APIs that should have never been exposed are now properly stashed away. Many applications will break because of that, but this had to be done at some point.
            I feel your pain if you get bitten, but in your case, you only need a JRE and as long as the application you're running doesn't require Java 9, JRE8 will do just fine.
            Indeed. This modularization is really excellent news for people relying on Java apps. For example OpenHAB might start up faster now. It's really big for embedded and servers to shave off few seconds from boot time.

            Comment


            • #7
              Originally posted by caligula View Post

              Indeed. This modularization is really excellent news for people relying on Java apps. For example OpenHAB might start up faster now. It's really big for embedded and servers to shave off few seconds from boot time.
              Modularization is great for dependency management, startup time isn't a primary concern here. For embedded, there was a dedicated, slim, runtime environment already and for server you almost always trade longer startup for better response time and more consistent performance.

              Comment


              • #8
                Java9 is the first version that is supposed to support HiDPI displays, older versions are often illegible on a HiDPI display.

                Comment


                • #9
                  Originally posted by Rob72 View Post
                  Java9 is the first version that is supposed to support HiDPI displays, older versions are often illegible on a HiDPI display.
                  Java has supported HiDPI just fine till now. JavaFX is themed using CSS so it can match whatever you need. You're probably thinking Swing applications, but those are on their way out (not that JavaFX, or desktop development in general, is winning popularity contests).

                  Comment


                  • #10
                    Originally posted by bug77 View Post

                    A lot of internal APIs that should have never been exposed are now properly stashed away. Many applications will break because of that, but this had to be done at some point.
                    I feel your pain if you get bitten, but in your case, you only need a JRE and as long as the application you're running doesn't require Java 9, JRE8 will do just fine.
                    If only Java apps are made in such a way they request a specific main version (with optional minor and bugfix version and SE/EE/ME/other as well). Maybe with some sort of Java JRE Semantic Versioning (SemVer): http://semver.org/.
                    And if only the JRE was made in such a way you could install multiple main versions next to each other.
                    And if only the updater would automatically then keep all those JRE's to their newest minor and bugfix version and extra versions for applications that request a specific version explicitly (which can always be overriden by the user of course). Allowing auto-updating while guaranteeing no applications break.
                    This would be a much better way to handle language and runtime changes. A much better Java versioning system. This system can also be extended to modules.
                    Where Java can break backwards compatibility without breaking legacy and old applications.
                    Heck you could even run multiple applications depending on different versions of the JRE at the same time.
                    The .NET Framework does things more this way.
                    Why can't Java do the same?
                    Last edited by plonoma; 24 September 2017, 02:35 PM. Reason: Added auto-updating without breaking and modules mention.

                    Comment

                    Working...
                    X