Announcement

Collapse
No announcement yet.

Java 14 Reaches General Availability With Garbage Collection Improvements

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

  • #21
    The Heck are you guys talking about "Java AOT" not be with us??
    It already exists when you use GraalVM.
    With GraalVM you can compile Java programs into native binaries.

    Its slowly becoming a thing in backend development with Java, see quarkus.io , a backend framework advertising native binary support.

    Comment


    • #22
      Originally posted by bug77 View Post

      Guest I'm with you, Java AoT will not be with us anytime soon. And I also like Go better. Some of the things Go didn't implement (or enforces by default) actually force me to rethink some of the (bad) practices I picked up during my years with Java. Java still pays the bills, tho
      Java pays my bills too. One of the things I wonder is whether inheritance was a mistake. Everyone says inheritance is fine if used properly. But every Java project I've used at work or encountered in open source projects that has grown past a very tiny size has started accumulating inheritance hierarchy hell. (Edit: For anyone that doesn't know, Go has interfaces but not inheritance.)

      Originally posted by Degra View Post
      The Heck are you guys talking about "Java AOT" not be with us??
      It already exists when you use GraalVM.
      With GraalVM you can compile Java programs into native binaries.

      Its slowly becoming a thing in backend development with Java, see quarkus.io , a backend framework advertising native binary support.
      GraalVM is a significant feature, but:

      1. It does not offer dynamic class loading.
      2. It does not offer use of reflection APIs.
      3. Because it does AOT instead of JIT, in long-running tasks the throughput is often less than running the regular JVM. GraalVM gives you easier packaging, faster startup, and lower memory footprint at the cost of a performance hit. See https://youtu.be/o8Sir1cFhDc?t=2532 ( A Youtube video from an Oracle GraalVM developer on GraalVM from September 2019 )

      So GraalVM is great for making Java command-line tools and (maybe?) fast-starting GUI applications and such. Maybe someone could write a Minecraft clone that uses it, or get it to compile one of the existing Minecraft Java clones like Terasology.

      But as far as I understand it, the places where Java is most popular are Android and on web servers. I doubt Oracle is in a hurry to help Google with Android performance ( ) and for most web servers throughput matters more than memory overhead and fast startup.

      Comment


      • #23
        Originally posted by royce View Post

        I would also like to know. GUI apps work like arse in Wayland.
        Does this include Android Studio?

        Comment


        • #24
          It does, anything based on Jetbrains' IntelliJ platform doesn't work right on some wayland compositors, for instance Sway.

          Comment


          • #25
            Originally posted by Michael_S View Post

            But as far as I understand it, the places where Java is most popular are Android and on web servers. I doubt Oracle is in a hurry to help Google with Android performance ( ) and for most web servers throughput matters more than memory overhead and fast startup.
            I think Google has moved towards Kotlin with java more as a legacy. Android is already AOT since Android 5. Finally, they do not use their hotspot, Google has written their own vm.

            They were still sued for copying APIs, not code.

            Comment


            • #26
              Originally posted by Degra View Post
              The Heck are you guys talking about "Java AOT" not be with us??
              It already exists when you use GraalVM.
              With GraalVM you can compile Java programs into native binaries.

              Its slowly becoming a thing in backend development with Java, see quarkus.io , a backend framework advertising native binary support.
              Keyword: slowly.
              It's only available for x86_64 Linux. And even if that's enough for you, it still comes with caveats/limitations.
              Libraries making use of reflection and a major hurdle for AoT becoming more than a toy.
              Originally posted by Michael_S View Post

              Java pays my bills too. One of the things I wonder is whether inheritance was a mistake. Everyone says inheritance is fine if used properly. But every Java project I've used at work or encountered in open source projects that has grown past a very tiny size has started accumulating inheritance hierarchy hell. (Edit: For anyone that doesn't know, Go has interfaces but not inheritance.)
              I've never has a problem with inheritance. (Actually, I did, once, but that was more on JPA and its default strategy for persisting hierarchies.) In fact, to this day I cannot understand "composition over inheritance", since inheritance is done by composition to begin with. That said, I never missed inheritance in Go. But I'd love to see a way to embed structures (i.e. embed type A into type B in a way that makes the existence of type A "invisible").

              Comment


              • #27
                Originally posted by bug77 View Post
                Guest I'm with you, Java AoT will not be with us anytime soon. And I also like Go better. Some of the things Go didn't implement (or enforces by default) actually force me to rethink some of the (bad) practices I picked up during my years with Java. Java still pays the bills, tho
                It's similar for me... Mainly, go helped me to see lots of coupling, which Java easily allows,...

                Go's enforcement of acyclic dependencies, makes coupling very visible,... As, everything inter-coupled with each other, must go together into same package... (there are ways to "hack" it using templates, but this moves it closer to ports and adapter pattern, as implementation of interfaces can be swapped).

                Go's errors (instead of exceptions) make errors to be visible part of flow, when programming. Where (runtime) exceptions are easy to ignore, and therefore programmers tend to focus on happy path only,... Though, currently, error inspection is quite complicated (rust handles it a bit better).

                Not having inheritance and polymorphism also helps to eliminate harder to spot coupling (via extended classes, overridden methods) and fragile base class issue,...

                However, generics is very missing...

                Comment


                • #28
                  Originally posted by kravemir View Post

                  It's similar for me... Mainly, go helped me to see lots of coupling, which Java easily allows,...

                  Go's enforcement of acyclic dependencies, makes coupling very visible,... As, everything inter-coupled with each other, must go together into same package... (there are ways to "hack" it using templates, but this moves it closer to ports and adapter pattern, as implementation of interfaces can be swapped).

                  Go's errors (instead of exceptions) make errors to be visible part of flow, when programming. Where (runtime) exceptions are easy to ignore, and therefore programmers tend to focus on happy path only,... Though, currently, error inspection is quite complicated (rust handles it a bit better).

                  Not having inheritance and polymorphism also helps to eliminate harder to spot coupling (via extended classes, overridden methods) and fragile base class issue,...

                  However, generics is very missing...
                  Generics are coming in 2.0, afaik. We don't know when 2.0 is coming though

                  Comment


                  • #29
                    Originally posted by bug77 View Post
                    I've never has a problem with inheritance. (Actually, I did, once, but that was more on JPA and its default strategy for persisting hierarchies.) In fact, to this day I cannot understand "composition over inheritance", since inheritance is done by composition to begin with. That said, I never missed inheritance in Go. But I'd love to see a way to embed structures (i.e. embed type A into type B in a way that makes the existence of type A "invisible").
                    If you look in a lot of the Apache projects that involve Java, you have classes that extend Foo, Foo extends Bar, Bar extends Baz, Baz extends Quux, and then Foo has an instance variable of type Abc, and type Abc extends type Def, and Def extends type Ghi... and then Bar has an instance variable of type Qrs and another of type Xyz. Before you know it, you have sixteen .java files open just to understand what one line of code does.

                    And again, most senior engineers you talk to will tell you that if you have your classes all mangled together in an inheritance hierarchy spaghetti mess like that, the problem is your engineers, not the language. I used to believe that. But I keep stumbling over spaghetti messes in Java code, all over. I have become convinced that it's rare for a large Java project not to evolve into that kind of mess, so either all Java engineers everywhere suck or else the problem is core to the language design.

                    Sometimes stripping a core feature out of a language design is useful for making the code easier to understand. I'm not aware of any high level language created in the last 25 years that includes 'goto'. The huge list of implicit variables in Perl are considered a mistake even by the language creator Larry Wall, and the ground up redesign of the language that is Perl 6 (now renamed to Raku) has only a few implicit variables.

                    Maybe inheritance needs to go away too.

                    I'm paid handsomely to wrestle with Java spaghetti, and while it's wonderful to have a decent income it's also stressful and frustrating to spend most of your time solving problems that shouldn't have existed in the first place.

                    Comment


                    • #30
                      Originally posted by Britoid View Post
                      #MakeJavaGreatAgain
                      #LetJavaDieInPeace

                      Comment

                      Working...
                      X