Announcement

Collapse
No announcement yet.

Java JDK 9 Finally Reaches General Availability

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

  • #11
    Originally posted by bug77 View Post
    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.
    AOT is an awesome feature. I hope Java AOT becomes stable soon.

    Comment


    • #12
      +1 for AOT
      This should already be the norm.

      Comment


      • #13
        Originally posted by plonoma View Post
        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).
        This would be a much better way to handle language and runtime changes. A much better Java versioning system.
        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?
        Not everyone thinks this is a great idea. Also you don't necessarily have a multi-purpose computer running multiple java apps. Most Java deployments I've seen are based on one app per container so it's pretty self contained. I hate when Linux apps pull millions of different versions of dependencies. They should just use the latest.

        Comment


        • #14
          Originally posted by bug77 View Post

          For embedded, there was a dedicated, slim, runtime environment already.
          Yet the embedded solutions such as OpenHAB didn't use or didn't even work with such slim environments.

          Comment


          • #15
            Originally posted by caligula View Post
            Yet the embedded solutions such as OpenHAB didn't use or didn't even work with such slim environments.
            Doesn't matter now, with modules you can create your own runtime and include only what you use (more or less).
            Also, the idea of making Java like .Net is dumb. First because I already need to keep a handful of .net runtimes (and countless more Visual C runtimes), I don't need Java to join them. Second, because of modules, it's clear this issue has just been resolved in another way.

            Comment


            • #16
              Originally posted by nomadewolf View Post
              +1 for AOT
              This should already be the norm.
              Not sure about you but there are solutions which work-around very well the Java's JIT. As for me I see very little advantage into a real full AOT and as far as the presentation of 1 year ago went, the AOT will be broken for many years to come.

              If I would put my eggs in a basket I would assume that first the value types would make applications feel "more native" as they will use less memory.

              Also, Java 9 has two very sweet optimizations around code generation (it generates methods in compact blocks which are defined around types, making the generate code more i-cache data friendly) and one that it can generate startup module bindings (if I understood right) which both improve how "native" (meaning in the sense of starting fast an after this running fast) Java feels.

              I don't know any reason why people cannot write for instance a game in Java because Java "is not AOT" and "the interpreter is slow".

              This is the JEP with better icache interaction:
              Last edited by ciplogic; 23 September 2017, 05:37 PM.

              Comment


              • #17
                Originally posted by ciplogic View Post

                Not sure about you but there are solutions which work-around very well the Java's JIT. As for me I see very little advantage into a real full AOT and as far as the presentation of 1 year ago went, the AOT will be broken for many years to come.
                Using AOT means you're circumventing JIT and you're getting full-speed from the beginning. Having an executable makes your app a little easier to approach, as you don't need to deal with 'java -cp xxxx run.my.Class' or 'java -jar yyyy' anymore.
                On the server, this doesn't mean much, but it can give a boost to Java usage for client apps.

                Comment


                • #18
                  Originally posted by bug77 View Post

                  Doesn't matter now, with modules you can create your own runtime and include only what you use (more or less).
                  Also, the idea of making Java like .Net is dumb. First because I already need to keep a handful of .net runtimes (and countless more Visual C runtimes), I don't need Java to join them. Second, because of modules, it's clear this issue has just been resolved in another way.
                  The system can be adapted to include modules if that's what you want.
                  With containers alone, you still have to package all those runtimes. You saved nothing.
                  You only increased overhead compared to having the launcher take care of this.
                  Note that the launcher, or whatever application would manage the connection between apps, version request and runtimes would be able to minimize the amount of runtimes and modules. By both trying to use only minor and major version bundling to the latest version and choose to use a different runtime by user configuration as well. This achieves a minimal amount of runtimes with the added benefit of no container overhead.
                  I'm also not suggesting making Java into .NET only using a similar but not identical way of managing runtime versions like .NET.
                  Last edited by plonoma; 24 September 2017, 02:37 PM.

                  Comment


                  • #19
                    Originally posted by ciplogic View Post

                    Not sure about you but there are solutions which work-around very well the Java's JIT. As for me I see very little advantage into a real full AOT and as far as the presentation of 1 year ago went, the AOT will be broken for many years to come.

                    If I would put my eggs in a basket I would assume that first the value types would make applications feel "more native" as they will use less memory.

                    Also, Java 9 has two very sweet optimizations around code generation (it generates methods in compact blocks which are defined around types, making the generate code more i-cache data friendly) and one that it can generate startup module bindings (if I understood right) which both improve how "native" (meaning in the sense of starting fast an after this running fast) Java feels.

                    I don't know any reason why people cannot write for instance a game in Java because Java "is not AOT" and "the interpreter is slow".

                    This is the JEP with better icache interaction:
                    http://openjdk.java.net/jeps/197
                    If I remember correctly, the big problem for games is that JIT causes stuttering.
                    For games and GUIs we want smoothness, fast response time, not only high performance.
                    But for games, we really want all the performance we can get. The more performance, the better.
                    Last edited by plonoma; 24 September 2017, 02:01 PM.

                    Comment


                    • #20
                      Originally posted by caligula View Post

                      Not everyone thinks this is a great idea. Also you don't necessarily have a multi-purpose computer running multiple java apps. Most Java deployments I've seen are based on one app per container so it's pretty self contained. I hate when Linux apps pull millions of different versions of dependencies. They should just use the latest.
                      Hence the version system allowing apps to only specify major or major and minor version.
                      And able to override app requested specific versions with launcher configurations.
                      Allowing you to minimize the number of runtimes to at least the same number that you would end up with on containers.
                      I also want to mention adding other query-able information in a standardized form that contains the version or versions the app has been tested and, or developed with, with each version entry having it's own string message, would be useful to have.
                      Last edited by plonoma; 24 September 2017, 02:42 PM.

                      Comment

                      Working...
                      X