Announcement

Collapse
No announcement yet.

OpenJDK 14 Has Some Performance Improvements But OpenJDK 8 Still Strong

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

  • #41
    Originally posted by Michael_S View Post
    The languages Haskell, Go, Rust, Julia, and Zig, among others, were designed with the conscious choice to omit inheritance. Granted, the industry is dominated by languages that do have inheritance: C++, Java, Python, C#.
    You don't need to use inheritance in OOP code nearly as often as people think they do. Especially in Kotlin the default is to have 'closed' classes. Also in Scala when you have records/data/case classes, they assume you're not extending the leaf classes. Traits also allow extending classes with features without forming a strict class hierarchy. Then there are implicits. Many classical design patterns also prefer composition over inheritance.

    The obvious problem in Haskell like languages is, you can't extend a data definition. If you do, you might do it via composition which makes handling the structure ugly even if you use lenses. Or some OOP like extensions (existential types). Just changing the data type back-propagates API/ABI changes and might break stuff. I'm not arguing one needs to develop in this contrived way, but random extensions often happen in long life enterprise software.

    Comment


    • #42
      Originally posted by Delgarde View Post
      As to modules, I think that's been a total failure. The concept was compelling when they first announced it, but nobody seems to actually be using it... e.g. libraries may support it, but they rarely mention modules in their documentation... project-templates like Spring Initializr don't create module-info files, development tutorials never use it. Pretty sure that long-term, everyone is staying with the Maven/Gradle approach, nobody using the platform support....
      You probably don't realize that C++ is also making a similar switch to modules and others are also considering. There are module (backpack) plans even for Haskell. There's a backward compatibility mode in JVM that makes it possible to use modular libraries in a non-modular legacy project. It's perfectly fine for end user apps, but modules are recommended when doing libraries. The modules are extremely handy for eliminating wrong kind of backwards and circular dependencies that will later introduce issues. They also can speed up development tools since you don't need to scan everything for changes.

      Comment


      • #43
        Originally posted by caligula View Post

        You don't need to use inheritance in OOP code nearly as often as people think they do. Especially in Kotlin the default is to have 'closed' classes. Also in Scala when you have records/data/case classes, they assume you're not extending the leaf classes. Traits also allow extending classes with features without forming a strict class hierarchy. Then there are implicits. Many classical design patterns also prefer composition over inheritance.
        I knew some of that already, but thanks for the rest (no sarcasm). Maybe Java use in the wild will evolve in sane directions thanks to the features introduced in the last few years. I'm just frustrated because up until now all of my professional encounters with the code use composition less often than inheritance, or don't use composition at all. And currently I'm in a bit of a worst-of-both situation, with a project that uses composition extensively but also has deep inheritance hierarchies in the types being composed.

        Originally posted by caligula View Post
        The obvious problem in Haskell like languages is, you can't extend a data definition. If you do, you might do it via composition which makes handling the structure ugly even if you use lenses. Or some OOP like extensions (existential types). Just changing the data type back-propagates API/ABI changes and might break stuff. I'm not arguing one needs to develop in this contrived way, but random extensions often happen in long life enterprise software.
        I've seen references to Haskell lenses before but I've only ever gotten a handful of steps past "Hello World!" with the language. I'm having a hard time conceptualizing what you're saying. I'll try my own interpretation: because languages like Haskell don't have inheritance, to extend a type later you either have to modify every single one of the callers or else use some really tricky language features.

        So again, I haven't worked in that kind of environment before. But from where I'm standing, that kind of headache seems preferable. Changing all of the references (as in code coupling, not variable references in memory) to something because you made a change sounds tedious but also straightforward to understand. I prefer that to inheritance because it can affect other sections of the code in ways that are difficult to reason about and that can catch people working on other parts of the code by surprise.

        Comment


        • #44
          Originally posted by caligula View Post
          You probably don't realize that C++ is also making a similar switch to modules and others are also considering. There are module (backpack) plans even for Haskell. There's a backward compatibility mode in JVM that makes it possible to use modular libraries in a non-modular legacy project. It's perfectly fine for end user apps, but modules are recommended when doing libraries. The modules are extremely handy for eliminating wrong kind of backwards and circular dependencies that will later introduce issues. They also can speed up development tools since you don't need to scan everything for changes.
          I'm not arguing that modules are a bad idea — I'm arguing that their introduction into Java seems to have been a failure, because nobody is using it. People are happily moving to the versions of Java that support modules, using some of the nice new language features... they're just ignoring modules and continuing to use the traditional way of packaging...

          Comment


          • #45
            Originally posted by Delgarde View Post

            I'm not arguing that modules are a bad idea — I'm arguing that their introduction into Java seems to have been a failure, because nobody is using it. People are happily moving to the versions of Java that support modules, using some of the nice new language features... they're just ignoring modules and continuing to use the traditional way of packaging...
            Just for example — Spring, probably the more important Java framework out there, doesn't expect to drop Java 8 compatibility until the next Java RTS (17) is out... which won't be until next year. And without dropping compatibility, they can't really do much for modularity.

            Comment


            • #46
              Originally posted by Delgarde View Post

              Just for example — Spring, probably the more important Java framework out there, doesn't expect to drop Java 8 compatibility until the next Java RTS (17) is out... which won't be until next year. And without dropping compatibility, they can't really do much for modularity.
              Actually, there is. Including the module metadata won't make their JARs incompatible with Java 8. They just need to keep using 8 as target for the bytecode. Spring's biggest problem these days is that it's more reflection/cglib than it is Java. And that makes it woefully inadequate for microservices.

              But there are other high profile libraries that don't support modules without a good reason for doing that. Like Jackson.

              Comment

              Working...
              X