Announcement

Collapse
No announcement yet.

Eclipse OpenJ9 v0.21 Released With Many Fixes, Big Performance Improvements For AArch64

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

  • Eclipse OpenJ9 v0.21 Released With Many Fixes, Big Performance Improvements For AArch64

    Phoronix: Eclipse OpenJ9 v0.21 Released With Many Fixes, Big Performance Improvements For AArch64

    A new version of the Eclipse OpenJ9 JVM implementation was released last week with many fixes and other improvements over its prior release...

    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 think most programming language ecosystems benefit by having multiple implementations - I think GCC and LLVM spur each other on through friendly competition, for example. So in that sense, OpenJ9 is great.

    On the other hand, I wonder what percentage of the world is using non-OpenJDK for Java these days? My wild guess is that it's incredibly small.

    Comment


    • #3
      Originally posted by Michael_S View Post
      I think most programming language ecosystems benefit by having multiple implementations - I think GCC and LLVM spur each other on through friendly competition, for example. So in that sense, OpenJ9 is great.

      On the other hand, I wonder what percentage of the world is using non-OpenJDK for Java these days? My wild guess is that it's incredibly small.
      There's a sizable chunk of the market that pays Azul and such because they won't move their asses off Java8.

      That said, I don't think Java needs more JVMs to secure a future, I think it needs to get AoT compilation in good shape instead. Besides having a huge selection of libraries, there's pretty much nothing that's appealing about Java when choosing the language for your next project. Need pure performance? C/C++ or Rust. Need to move fast, but without a huge runtime holding you back? Go. You just need to prototype something quickly? Python. You just want Java? C# offers a cleaner experience overall.

      If it doesn't get out of its comfort zone, in a couple of decades Java will become the new Cobol, imho.

      Comment


      • #4
        You might be right. As a minor counter point, I'm not aware of any languages aside from C# on the .NET ecosystem with any popularity. The JVM has Scala, Clojure, Groovy, and most notably Kotlin and even if the JVM stagnates it seems likely one of them will keep gaining ground - right now Kotlin seems to be the hot one.

        On the other hand, I think WebAssembly could be huge going forward and .NET has, as far as I understand it, a big lead there.

        And from a personal perspective, I haven't made up my mind but I might want Go to win ownership of the space between C/C++/Rust on one side and scripting languages on the other. I sometimes think that multiple levels of inheritance is the biggest cause of unnecessary complexity and inflexible code in modern software, and even if Go's designers got everything else wrong the fact that they dodged that bullet might be enough for them to eat Java and even C#'s lunch eventually.

        Comment


        • #5
          Originally posted by Michael_S View Post
          You might be right. As a minor counter point, I'm not aware of any languages aside from C# on the .NET ecosystem with any popularity. The JVM has Scala, Clojure, Groovy, and most notably Kotlin and even if the JVM stagnates it seems likely one of them will keep gaining ground - right now Kotlin seems to be the hot one.
          Kotlin is nice, but all of these are still encumbered by the runtime environment, slow startup and huge application images. Kind of a no-no in a microservices world.

          Originally posted by Michael_S View Post
          On the other hand, I think WebAssembly could be huge going forward and .NET has, as far as I understand it, a big lead there.
          Might be. I've given it a whirl and found it hard to work with. The potential is there though.

          Originally posted by Michael_S View Post
          And from a personal perspective, I haven't made up my mind but I might want Go to win ownership of the space between C/C++/Rust on one side and scripting languages on the other. I sometimes think that multiple levels of inheritance is the biggest cause of unnecessary complexity and inflexible code in modern software, and even if Go's designers got everything else wrong the fact that they dodged that bullet might be enough for them to eat Java and even C#'s lunch eventually.
          For the life of me I don't understand why people find inheritance a problem. In literally every case I came across or heard of, it was just developers using it wrong.
          That said, I like Go a lot, I found it very productive to work with. I keep hearing people pointing out its flaws (like other languages are close to perfection or something), yet the damn thing works.

          Comment


          • #6
            Originally posted by bug77 View Post
            Kotlin is nice, but all of these are still encumbered by the runtime environment, slow startup and huge application images. Kind of a no-no in a microservices world.
            Granted, but microservices are not the end-all-be-all of software development.

            Originally posted by bug77 View Post
            Might be. I've given it a whirl and found it hard to work with. The potential is there though.
            I found the "Hello World" examples easy enough to get working, but maybe it gets uglier as you go.

            Originally posted by bug77 View Post
            For the life of me I don't understand why people find inheritance a problem. In literally every case I came across or heard of, it was just developers using it wrong.
            That said, I like Go a lot, I found it very productive to work with. I keep hearing people pointing out its flaws (like other languages are close to perfection or something), yet the damn thing works.
            Let's see how big this rant gets. My whole career has been in C++ and Java, with a smattering of other stuff. I've seen deep inheritance hierarchies with all kinds of shenanigans in lots of different proprietary applications, and in the source code to Jenkins (open source continuous integration server), Hibernate (object-relational mapping), Stripes (a wildly popular Java framework), Play Framework (a Java/Scala web framework), and countless other projects. In my experience, the only Java projects I've seen that don't use inheritance badly are brand new ones. If it's more than three years old and more than trivially tiny, it's probably in inheritance hell.

            When some users of a tech do something stupid, the users are the problem. When it's unusual to find users of a tech avoiding something stupid, the tech itself is the problem.

            At my day job they pay me handsomely to maintain an 18 year old set of Java web applications that are quite profitable but have half a million lines of code and inheritance hierarchies 10 levels deep. If it wasn't for the paycheck, I'd have jumped ship years ago. But at this point if I switched to Python, or Go, or anything but Java it would probably carry a 40% pay cut, and I can't accept that until my youngest kid is out of college/tech school/cosmetology school/whatever in about 2035. So I sure hope the JVM and Java improve, because I'm stuck here for a while.

            The core problem with inheritance is that for any single problem, subclass-and-override is probably the most direct route to a solution. You get maximum code reuse, minimum effort, minimum risk of breaking anything else in the application. Something in the code does most of what you want, inherit and tweak, and you're done. But as a strategic move, rewriting behavior to be altered by decorators, or composition, or to use well-defined interfaces between different modules will make future work easier at the cost of making the current task harder. So you are always in the situation where the fastest solution to the current problem may be the worst possible choice for managing the flexibility and complexity of the code for the next five problems. You can't escape that conflict, and if your project lasts long enough you end in the profitable but irritating mess that I deal with all day.

            I've seen this with C++ too, but that was in the early 2000s. I don't know how widespread it is in C++. In Java, it seems to be everywhere. If your experience has been better, I envy you.

            Comment


            • #7
              Originally posted by Michael_S View Post
              Granted, but microservices are not the end-all-be-all of software development.
              True, but they are a hot new thing right now.
              My feeling is everything you do in JVM-based language you can do faster in Python (if you don't care much about performance) or Go (if you do).

              Originally posted by Michael_S View Post
              I found the "Hello World" examples easy enough to get working, but maybe it gets uglier as you go.
              Yeah, the "Hello world" is pretty much the only thing you can do without a world of pain. But support/tooling is improving.

              Originally posted by Michael_S View Post
              Let's see how big this rant gets. My whole career has been in C++ and Java, with a smattering of other stuff. I've seen deep inheritance hierarchies with all kinds of shenanigans in lots of different proprietary applications, and in the source code to Jenkins (open source continuous integration server), Hibernate (object-relational mapping), Stripes (a wildly popular Java framework), Play Framework (a Java/Scala web framework), and countless other projects. In my experience, the only Java projects I've seen that don't use inheritance badly are brand new ones. If it's more than three years old and more than trivially tiny, it's probably in inheritance hell.

              When some users of a tech do something stupid, the users are the problem. When it's unusual to find users of a tech avoiding something stupid, the tech itself is the problem.

              At my day job they pay me handsomely to maintain an 18 year old set of Java web applications that are quite profitable but have half a million lines of code and inheritance hierarchies 10 levels deep. If it wasn't for the paycheck, I'd have jumped ship years ago. But at this point if I switched to Python, or Go, or anything but Java it would probably carry a 40% pay cut, and I can't accept that until my youngest kid is out of college/tech school/cosmetology school/whatever in about 2035. So I sure hope the JVM and Java improve, because I'm stuck here for a while.

              The core problem with inheritance is that for any single problem, subclass-and-override is probably the most direct route to a solution. You get maximum code reuse, minimum effort, minimum risk of breaking anything else in the application. Something in the code does most of what you want, inherit and tweak, and you're done. But as a strategic move, rewriting behavior to be altered by decorators, or composition, or to use well-defined interfaces between different modules will make future work easier at the cost of making the current task harder. So you are always in the situation where the fastest solution to the current problem may be the worst possible choice for managing the flexibility and complexity of the code for the next five problems. You can't escape that conflict, and if your project lasts long enough you end in the profitable but irritating mess that I deal with all day.

              I've seen this with C++ too, but that was in the early 2000s. I don't know how widespread it is in C++. In Java, it seems to be everywhere. If your experience has been better, I envy you.
              I get where you're coming from, but I'm not ready to blame the tech just because people are using it wrong. The implementor may be a rookie, but when the reviewer doesn't point out instead of dumb inheritance, a combination of single responsibility principle with composition over inheritance would be the better choice, I'd say you've got bigger problems than the tech

              Also, I'll your stories and I'll raise you mine: define a few entities having 4-5 levels of inheritance, use Hibernate's default persistence strategy (because you don't know any better) and try to join those entities together, see how that works out for you :P

              Comment


              • #8
                No mention of IBM? Any chance of some bench marks of these, vs IBM proprietary JVM, Oracle, OpenJDK and GraalVM

                Comment


                • #9
                  Originally posted by FireBurn View Post
                  No mention of IBM? Any chance of some bench marks of these, vs IBM proprietary JVM, Oracle, OpenJDK and GraalVM
                  Isn't OpenJ9 IBM's JVM, they donated it to the Eclipse Foundation?

                  Comment


                  • #10
                    Originally posted by bug77 View Post
                    If it doesn't get out of its comfort zone, in a couple of decades Java will become the new Cobol, imho.
                    Where does your idea that java lives in a comfort zone come from?

                    Java exited its own comfort zone starting with Java 8 and accelerating since Java 9.
                    From that point the language itself got A LOT of evolution making it more modern and less verbose.

                    The new short release cycles also contributed to this process and now we have language changes every 6 months.
                    I'd rather say that Java is a rather fast evolving language right now!

                    Yes, enterprise is somewhat stuck into java 8, but that's not Java fault

                    Comment

                    Working...
                    X