Announcement

Collapse
No announcement yet.

Some Early Tests Of The Eclipse OpenJ9 Java Virtual Machine

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

  • #21
    Originally posted by duby229 View Post
    Also worth a mention here is that Python is highly useful to automate stuff. It can actually be a half decent scripting language. I've never used it to write a "program", I don't have the skill for that, but I use it almost constantly to write scripts.
    If you learn how to use classes, you'll be surprised to find how easy it is to write full-blown programs. That being said, you don't have to learn classes - I've written ~1000 line applications (even with a GUI) without creating a single class myself. But, understanding classes makes it much easier to use more complex libraries. So I'd say give it a shot, if you find the need to write something bigger.

    Comment


    • #22
      Originally posted by schmidtbag View Post
      If you learn how to use classes, you'll be surprised to find how easy it is to write full-blown programs. That being said, you don't have to learn classes - I've written ~1000 line applications (even with a GUI) without creating a single class myself. But, understanding classes makes it much easier to use more complex libraries. So I'd say give it a shot, if you find the need to write something bigger.
      I've got nothing against Python, and use it myself for various scripting projects, but the day job for me is working on a Java backend for a web-app which is well over the million line mark. Strongly typed objects and documentation make it a lot easier to keep that code straight.

      With regards to the people that think that dropping JRE plugin support is a sign of the death of java, that's just silly. All in-browser plugins are on their way out, but that doesn't mean that standalone java programs or java on the server as a back-end language are going anywhere any time soon

      Comment


      • #23
        Originally posted by Veerappan View Post
        I've got nothing against Python, and use it myself for various scripting projects, but the day job for me is working on a Java backend for a web-app which is well over the million line mark. Strongly typed objects and documentation make it a lot easier to keep that code straight.
        That there is exactly why I feel Java isn't going to die any time soon. To reiterate, I'm aware Java has specific uses, and I believe it will live for a long time. I don't hate Java as much as others seem to think. I actually like it, in theory. I just don't like Oracle's involvement with it.
        With regards to the people that think that dropping JRE plugin support is a sign of the death of java, that's just silly. All in-browser plugins are on their way out, but that doesn't mean that standalone java programs or java on the server as a back-end language are going anywhere any time soon
        It isn't so much a sign of death but rather a reflection of how its health is dwindling. The plugins being removed are broken in some way, for reasons such as not being properly kept up-to-spec or because of security flaws. Java's web plugin is both (as is Flash).
        I'm aware standalone Java programs aren't going away any time soon. I never implied otherwise.

        Comment


        • #24
          Java is far from dying. It's design is great for long-term applications:
          • provides "secure" memory access (no stack/memory corruption bugs, buffer overflows,... ),
          • suitable long-term maintenance and improvement (static typing is big win, if couple of developers exchange/cooperate on same project),
          • moving to newer library version is less painful (static typing helps to easily fix call/API inconsistencies),
          • simplicity of the language allows less skilled developers to be included and cooperate on the project,
          • and so on,...
          • BUT, especially eco-system around Java is BIG!
          Yes, it's far from good, regarding performance. But, the performance is a second priority of Java. The first priority is to provide great language for development of software with long-term support and easy cooperation of project workers.

          Comment


          • #25
            There is some misinformation on the thread.

            Java as a web browser plugin is almost dead. But it's dying because it was always awful and rarely used. Far, far less than 0.1% of all worldwide Java use is in browser plugins.

            Next, Java is in Android, the most poular operating system in the world. And Google is not getting rid of it. Google added Kotlin support to Android, but Kotlin runs on the same runtime on Android as Java (and on other operating systems Kotlin runs on the Java Virtual Machine). Kotlin has excellent interoperability with Java too.

            Third, I hate Oracle but the GraalVM project to support many more languages on the JVM is awesome.

            Most of us have terrible memories of Java from early days. Most of us hate Oracle. Most of us remember the barrage of Java security flaws a few years back. Most of us remember how awful and slow early Android was. And if you ever used Java for work, you might have special ate for XML hell, EJBs, JSP, JSF. But Java is widely used and one of the most popular languages in the world. It is *not* in decline.

            Comment


            • #26
              Originally posted by Michael_S View Post
              ... Most of us have terrible memories of Java from early days. Most of us hate Oracle. Most of us remember the barrage of Java security flaws a few years back. Most of us remember how awful and slow early Android was. And if you ever used Java for work, you might have special ate for XML hell, EJBs, JSP, JSF. But Java is widely used and one of the most popular languages in the world. It is *not* in decline.
              The biggest security flaw with Java is tied to usage of native libraries. But, regarding this problem, no native (C,C++,...) application is any safer, but the opposite. Native applications are more prone to errors.

              Actually, things, which I hated the most about Java, show up to be greatly beneficial in contributing and maintaining a long-term application. Most of conventions in Java world are slowing down development, but at the same time, they help making order within the code.

              Comment


              • #27
                A lot of the j-haters here are too emotionally-biased against it and don't really look a cold-hard-facts.
                So here are some cold hard 2017 stats from stackoverflow...
                Get insights on the world’s developers from the largest and most comprehensive survey ever. Demographics. Technologies. Salaries. Career satisfaction.

                Comment


                • #28
                  I think Microsoft wishes there were as many CLRs as there are JVMs. Now if Azul would open source their AMD64 Zing VM we would really have something to compare against.

                  It'll be interesting to see who ends up adopting Open J9, apart from eclipse in some way. I guess the libraries will end up being used in many ways and places.

                  Comment


                  • #29
                    Hi,

                    I work on the OpenJ9 project, many thanks for taking the time to publish these results.

                    I've done some initial investigation to see how OpenJ9 is reacting to the benchmarks. The machine I used was a 32 core Xeon(R) CPU E7-8867 so I focused on the results on page 3 of the report as the more similar compare. While I haven't looked at every benchmark yet, I have discovered some of the reasons behind the results, and have been opening issues at our github project to track them.

                    Here's the (current as of October 3rd) set of links:

                    The SunFlow benchmark performed poorly with the initial release of OpenJ9 (slower than HotSpot by a factor of about 5x). A large part of the problem was solved by the fix for #42 (available in curr...

                    Analysis of the Bork file encryption benchmark indicates a large number of calls to /usr/lib64/libz for calculating crc32. The relatively expensive native method call sequence suggests that this ma...

                    The hot loop of the LU matrix factorization kernel of the SciMark benchmark is suitable for auto-SIMD, but currently isn't converted because it uses multiply-subtract. The current auto-SIMD optimis...

                    Performance of the Sparse Matrix Multiply kernel of the SciMark benchmark is significantly less with OpenJ9 compared to HotSpot. Results on 32 core Xeon(R) CPU E7-8867: OpenJ9 615 Mflops vs HotSpot...

                    Performance of the Monte Carlo kernel of the SciMark benchmark is reduced by the presence of locking on a local object inside the hot loop. When run with HCR disabled the object is recognised as no...


                    Like any project, we will be trying to address these problems and you can track what is happening in those issues. My feeling right now is that we can make some large improvements already if we address the problems I have found so far.

                    If you're interested in some of the background on why OpenJ9 sometimes has different strengths and weaknesses compared to other JVMs, there's an entry on the OpenJ9 FAQ page under "Why does my Java application perform worse with Eclipse OpenJ9?" (http://www.eclipse.org/openj9/oj9_faq.html). There's also a section showcasing OpenJ9's strengths, rather hidden behind the "Learn more" link on the OpenJ9 home page at http://www.eclipse.org/openj9/

                    Thanks again for taking the time to measure OpenJ9. I would like to invite you to directly open issues at our github site in future if you find discrepancies of this magnitude. While we won’t always be the best JVM on all metrics, we are keenly interested to find and fix problems that unnecessarily affect our performance in negative ways.

                    Comment

                    Working...
                    X