1. 40
  1. 21

    I can’t wait for universities to completely ignore this release and still only allow usage of Java 8.

    1. 4

      I can’t wait to upgrade past java 8 update 192 for critical services at work…

      1. 7

        I can’t wait for universities to ignore Java.

        1. 2

          What would you like them to teach / use instead?

          1. 0

            I would prefer them to teach fundamental principles while exposing students to a wide variety of technologies that embody a wide spectrum of paradigms. From assembly, to C, to Lisp, to Haskell, etc.

            While some small exposure to Java might be useful (at least as a negative example), basing entire curriculums on a proprietary language that rots your mind is not.

        2. 3

          I switched jobs in April and I could finally leave 8 behind. We are on 11, let’s see when we can go to 17.

          1. 1

            Eh, I’m stuck supporting C++14. The pain is universal…

            1. 3

              Python 3.5 here…

        3. 2

          I can’t wait to try Shenandoah and ZGC in production (one of my services does over 1.5K RPS with G1). I’ve moved over to Kotlin long time ago seeing same features land in Java, and more JVM improvements get me excited and confident in future of JVM ecosystem.

          1. 12

            It really is an exciting time to be working in a JVM language. I too moved over to Kotlin a while back, but I still closely follow what’s going on in Java.

            My hunch is that a lot of people who currently dismiss Java and the JVM as slow bulky dinosaur tech are going to be shocked when some of the major upcoming changes get released. Loom (virtual threads) in particular should drive a stake through the heart of async/await or reactive-style programming outside a small set of niche use cases, without sacrificing any of the scalability wins. Valhalla (user-defined types with the low overhead of primitive types) and Panama (lightweight interaction between Java and native code) will, I suspect, make JVM languages a competitive option for a lot of applications where people currently turn to Python with C extensions.

            1. 2

              My hunch is that a lot of people who currently dismiss Java and the JVM as slow bulky dinosaur tech are going to be shocked when some of the major upcoming changes get released

              I agree with this re the JVM, but isn’t Java mostly releasing language-level changes that are just catch-up with things that have been commonplace elsewhere for years?

              1. 4

                That’s a fair point, sure.

                Maybe a better way to frame it is that as language changes roll out, it’ll get harder to point to Java and say, “That’s such an obsolete, behind-the-times language. It doesn’t even have thing X like the other 9 of the top 10 languages have had for years.”

                Of course, Java will never (and should never, IMO) be on the bleeding edge of language design; its designers have made a deliberate choice to let other languages prove, or fail to prove, the value of new language features. By design, you’ll pretty much always be able to point to existing precedent for anything new in Java, and it’ll never look as modern as brand-new languages. My point is more that I think the perception will shift from, “Java is obsolete and stagnant” to, “Java is conservative but modern.”

              2. 1

                my Android client app shares code with backend (both are in Java).
                The android’s Java is at about JDK 8+ level (https://developer.android.com/studio/write/java8-support-table ) The backend is currently using JDK 11.

                So sharing the code between client and backend is becoming more challenging.

                I think, if I am to move backend to JDK 17, then it will be harder to share code (if take advantage of JDK 17 features on the backend).

                I guess the solution is to move both backend and frontend to Kotlin… but that’s a lot of work without significant business value.

                1. 3

                  Nothing prevents you from using JDK 17 with Java 8 language features level, essentially marking any use of new features a compile errors and making sure your compiler produces Java 1.8 compatible bytecode. That’s what we do in our library that needs to be JDK 8+ (but we use JDK 8 on the CI side to compile the final JARs to be on the safe side). Then you can run that code on JVM 17 on the server and take advantage of the JVM improvements (but not the new language features). We have decided to add Kotlin where it makes sense gradually instead of a full rewrite (e.g. when we’d want to use coroutines).

                  1. 2

                    You could also just stick to 11. It’ll be supported for years.