Announcement

Collapse
No announcement yet.

Java JDK 9 Sees Its First Release Candidate

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

  • #31
    Originally posted by bug77 View Post
    Android games are not written in Java, but don't let that stop you from spewing BS.
    There are many Android java games, just google: android java games. Also C++ is used, but android user level is implemented with java, so it could be faster if everything is written with c++, Sure you hope that that touch screen would react faster in action games and wish that games do have same graphics quality and story that pc games do have. Compare Final Fantasy pc and android versions to get the idea.

    Originally posted by bug77 View Post
    Also, how did you manage to bring your Debian+Xfce crap into a discussion about Java and Android?
    It would much wiser to use Debian testing Xfce instead of Android where java plays a big role. You can update Debian testing every day, android phone can be non functional because of incompatible os, like my kid has problems with android 5.1 and google services. My kid needs to buy a new phone, because of android. With Debian testing you can use same hardware forever.
    Last edited by debianxfce; 08-11-2017, 07:03 AM.

    Comment


    • #32
      Originally posted by debianxfce View Post

      There are many Android java games, just google: android java games. Also C++ is used, but android user level is implemented with java, so it could be faster if everything is written with c++, Sure you hope that that touch screen would react faster in action games and wish that games do have same graphics quality and story that pc games do have. Compare Final Fantasy pc and android versions to get the idea.
      Facepalm.



      Originally posted by debianxfce View Post
      It would much wiser to use Debian testing Xfce instead of Android where java plays a big role. You can update Debian testing every day, android phone can be non functional because of incompatible os, like my kid has problems with android 5.1 and google services. My kid needs to buy a new phone, because of android. With Debian testing you can use same hardware forever.
      You tried bringing that up with Google? You might help them save a ton of money.

      Comment


      • #33
        Originally posted by debianxfce View Post
        There are many Android java games, just google: android java games. Also C++ is used, but android user level is implemented with java, so it could be faster if everything is written with c++, Sure you hope that that touch screen would react faster in action games and wish that games do have same graphics quality and story that pc games do have. Compare Final Fantasy pc and android versions to get the idea.
        I am wondering if are a troll or an idiot. Sorry, this is not a personal attack, it is how you describe yourself.

        Let me explain some mistakes you miss:
        - C++ (and "native" languages) tend to be better in latency (so to answer in a number of milliseconds) than on throughput. I found very often implementing throughput algorithms in Java, do run faster (especially if there are GC-free algorithms) than C++.
        - comparing a PC version to an Android version is very silly. For example on the next link you see that a typical PC runs (using kind of unreliable, where iPhone was optimized a lot for) runs circles around iPhone 7 (for instance). Most Android phones are not 100% matching iPhone 7.

        https://browser.geekbench.com/v4/cpu...aseline=387526

        - let's say Java would run slower than C++, so what? There are cases when it runs better. Will you throw C++ out of the window, maybe KDE or XFCE (yeah, you know, it has many things written in C++) because Java runs it faster? One good example: Java 9 as we discuss will beat most string related coding like string concatenation doing with almost GC-free algorithms. I am ready any day to compare a STL based coding to a Java 9 based coding into processing a lot of text...

        Originally posted by debianxfce View Post
        It would much wiser to use Debian testing Xfce instead of Android where java plays a big role. You can update Debian testing every day, android phone can be non functional because of incompatible os, like my kid has problems with android 5.1 and google services. My kid needs to buy a new phone, because of android. With Debian testing you can use same hardware forever.
        Last but not least: let's say Android has problems, what it has to do with their (Google's) Java compatible implementation? Out of curiosity, do you have any phone for your child which is from a major vendor which runs Debian XFCE?

        Comment


        • #34
          Originally posted by debianxfce View Post
          Java is like a virus and for idiots that do memory leaks etc. When it came in 90s, it took markets from C++ and we had slowly working software. Today we have android with its java implementation and do have poor games although mobile phone hardware is very powerful. Android is a big mistake, Debian testing Xfce does have better software architecture with its debian packaging and rolling release nature. With Android you need to flash a new firmware or buy a new phone to get newer os.
          I think you live in 90s.

          Take two projects that do the same stuff: take Visual Studio, add Resharper (a standard tool in .Net's world) and compare it with Rider, the IDE from JetBrains whic is written with Java and embeds Resharper. Write to me after you test which starts and runs faster...

          To me there is no comparison, Java runs better on the JetBrain's IDEs than C++ on Microsoft's IDEs.

          Also, the more you run real software, I tend to see that if I ignore the startup cost (yes, I know it exists) and memory (yes, memory matteers, but not that much), Java applications tend to run faster than C++. By a big margin in fact, in my experience it is more than 10% for high volume computations, somewhere in between GCC O2 and GCC O3.

          Comment


          • #35
            Originally posted by bug77 View Post

            Never, because I haven't been involved in Scala projects as much as I would have liked. But it has bitten others: http://underscore.io/blog/posts/2016...wenty-two.html
            FWIW, some languages don't provide tuples at all. I'd claim this is more of a problem with program/framework design and/or DB data models. Relational data isn't the only way to go. Limiting the size of builtin tuples isn't some Scala related unique limitation. Many previous functional languages did the same thing. There's really nothing wrong with nested data if you have 100 fields in a record.

            Comment


            • #36
              Originally posted by ciplogic View Post
              if I ignore the startup cost (yes, I know it exists) and memory (yes, memory matteers, but not that much), Java applications tend to run faster than C++. By a big margin in fact, in my experience it is more than 10% for high volume computations, somewhere in between GCC O2 and GCC O3.
              One main point of new Java 9 is the modularization of the std lib. The JVM runtime spends significant time loading the standard classes every time. You can already achieve faster startup by using Avian or slicing the jars with proguard. I guess the Java experts here already knew all this.

              Comment


              • #37
                Originally posted by starshipeleven View Post
                In other words: "well-written code is easy to understand".

                I've seen way too many Java programs written like shit or using frameworks where the method names meant little to anyone that wasn't the framework developer. I can assure you that forcing people to be wordy is not a sure way to get decent code.
                https://stackoverflow.com/questions/...erfactoryproxy

                Comment


                • #38
                  Originally posted by caligula View Post
                  One main point of new Java 9 is the modularization of the std lib. The JVM runtime spends significant time loading the standard classes every time. You can already achieve faster startup by using Avian or slicing the jars with proguard. I guess the Java experts here already knew all this.
                  Java 9 has a linker which improves startup times. JLink.
                  http://mail.openjdk.java.net/piperma...er/004806.html

                  But my comment it is that Java is understood that it starts slow but it generates at the end quick code by most measures.

                  An unbiased benchmark shows how Java is basically in the same league (maybe at worst with a 2X slowdown) as C/C++. In my experience, Java beats C++ in my most real kind of software. I know how to saturate an SSD using Java (like processing hundreds of megabytes per second) and it is very hard to beat it with C++. It could be possible, of course, but I found it very seldom to run C++ much quicker.
                  http://www.stefankrause.net/wp/?p=9#more-9
                  Last edited by ciplogic; 08-14-2017, 02:48 AM.

                  Comment


                  • #39
                    Originally posted by ciplogic View Post
                    Java 9 has a linker which improves startup times. JLink.
                    http://mail.openjdk.java.net/piperma...er/004806.html

                    But my comment it is that Java is understood that it starts slow but it generates at the end quick code by most measures.

                    An unbiased benchmark shows how Java is basically in the same league (maybe at worst with a 2X slowdown) as C/C++. In my experience, Java beats C++ in my most real kind of software. I know how to saturate an SSD using Java (like processing hundreds of megabytes per second) and it is very hard to beat it with C++. It could be possible, of course, but I found it very seldom to run C++ much quicker.
                    http://www.stefankrause.net/wp/?p=9#more-9
                    Sure, won't disagree with any of that. I had the impression that stdlib modularization is the main achievement in jdk9, but probably jlink is also needed. Avian and proguard basically do the same, a static linking step which also discards unused parts. Still, even with jlink & modularization, I think proguard can optimize things further. The previous results were quite impressive. One thing people also don't realize is that machines have improved quite a bit since the early Java days. A modern PC cold boots the OpenJDK jvm in 90 ms, all class loading included. If Java 9 can improve this further, the startup cost is similar to large C++ apps.

                    Comment


                    • #40
                      Originally posted by caligula View Post

                      FWIW, some languages don't provide tuples at all. I'd claim this is more of a problem with program/framework design and/or DB data models. Relational data isn't the only way to go. Limiting the size of builtin tuples isn't some Scala related unique limitation. Many previous functional languages did the same thing. There's really nothing wrong with nested data if you have 100 fields in a record.
                      Maybe so, but a seemingly artificial limitation like this flies straight in the face of the elegance functional languages are capable of. And yes, I know Scala isn't a pure functional language.

                      Comment

                      Working...
                      X