8 ms·

I wonder if it's a better idea to drop reverse compatibility and simply have a Java2. Given how well the language is defined, they could almost certainly compi

I wonder if it's a better idea to drop reverse compatibility and simply have a Java2. Given how well the language is defined, they could almost certainly compile Jv1 classes to Jv2 classes anyhow with minimal impact probably. They could fix a couple other things along the way.

MBCook 5y ago
The Java ecosystem is HUGE. It took python what, over a decade to get people to switch from 2 to 3 didn’t it? I’m just not sure you could ever pull it off. It seems way harder than that. Even with some sort of compatibility layer. I think you’d really end up in more of a perl 6 situation where it’s a different language that would eventually have to be renamed due to confusion.
- jollybean 5y ago
  They may not have a choice, because J1 has problems evolving and it takes a decade (or never) to make major improvements. Just leave it and support it for another 20 years on the side. A lot of isolated Java could remain V1 no problem. Allow new starts, separate modules, and those that want to port a J2. Python 3 was a disaster because they never bothered to think about it, provided no facility for it, didn't care about collisions at the platform level. Oracle could literally pay for the most important OSS modules to be ported, give architectural guidance scripts to transform old codebases, special test units, training. Python and Javascript are ironically two of the biggest messed in all of tech, that gain popularity and drag everything into the mud with them.
  - kinjba11 5y ago
    "Java 2" is already out - it's Kotlin (or Scala if you're so inclined) ;) Unfortunately the more compatible you are with "V1" the more compromises you have to make. See: Kotlin, F#, TypeScript bending over backwards to maintain compatibility with the dominant language of their respective platforms. Not to mention C++. You have to admire the hutzpah of Python 3 level of changes. Some software should simply have a "sell by" date and be thrown out when it starts to stink. That said I'm surprised more languages haven't attempted the approach of Rust with 'editions'. > There are times, however, when it is useful to be able to make small changes to the language that are not backwards compatible. The most obvious example is introducing a new keyword... Editions are the mechanism we use to solve this problem. When we want to release a feature that would otherwise be backwards incompatible, we do so as part of a new Rust edition. [https://doc.rust-lang.org/edition-guide/editions/index.html https://doc.rust-lang.org/edition-guide/editions/index.html]
    - kaba0 5y ago
      As mentioned in the article, “A growable language” shows us that a programming language has to evolve. I think Java does an excellent job of not including everything and the kitchen sink right away, but wait a bit for the hype to die off and usually implements new features when they are worthy, often in a superior way. This “last mover advantage” was even part of the initial ideas behind Java.
      - kinjba11 5y ago
        The last movers advantage is a tradeoff. It becomes increasingly difficult to make major paradigm shifting changes the further you go. Being conversative increases the length of the runway and Java has benefited from that. Though, the superiority of Java's version when it finally gets some feature is often debatable. Two major initiatives for many years in Java have been Loom and Valhalla. A cynical take on that is that Java is attempting to copy something that Go and C# (and others) have had and excelled at for a decade or more, and were designed to do from the start. Sometimes, at some point the expense and complexity of dragging decades of code forward (with all accumulated mistakes, design assumptions made based on now obsolete hardware, backwards compat constraints, etc.) outweighs the cost of going back to the drawing board to start again.
        kaba0 5y ago
        But Java attempts to “copy” those with an order of magnitude larger ecosystem, with the benefit of all the other optimizations/state of the art GCs that went into the OpenJDK project, and with true backwards compatibility of the billions of lines of code out there. I don’t think that reinventing the wheel would really put us forward. According to the ‘No silver bullets’ article, there is no significant (that is, order of magnitude) productivity improvement in language design since high level languages. The only such bullet is reusing existing libraries. (Also, do note that we still rely heavily on numerical libraries written in fortran)
        kinjba11 5y ago
        I agree the order of magnitude improvement is no more. Programming in C is much the same as Java. Both are high level curly brace languages. But there is room for improvement still, quite a bit. The fact that Kotlin, Go, etc. were created and became popular supports the fact that large numbers of folks believed that Java's design direction has run it's course to some degree. I may be proven wrong, Valhalla and Loom could be smashing successes and everyone will flock back to Java. But more likely it will take a decade to reap the benefits of the features Valhalla and Loom would provide, benefits already being reaped by other ecosystems right now. State of the art GCs are incredible - but there is a reason you see Java pioneering the GC area, that being that Java has the most to gain because of its tendency to create enormous amounts of garbage, which is a problem other language designs do not suffer from nearly as much, letting them get away with simpler GC while maintaining high performance. And Fortran isn't the only game in town for high performance numerical libraries ;) There is large incentive to reinvent there, as legacy doesn't matter if the new thing has more performance - Eigen, cuBLAS/CUDA, and others are in C++, not Fortran as far as I'm aware. Fortran has momentum no doubt, but it has been on its way out for a long time.
- fnord77 5y ago
  yeah, people/projects are clinging to java 1.8 even though there's been huge improvements in the newest VMs
hashmash 5y ago
When new Java features like this are added, it also includes new features and optimizations in the JVM itself. Other languages that compile to the JVM can take advantage of these new features as well, either with no effort, or incrementally.
- jollybean 5y ago
  They can do just the same for a non-backwards compatible jump.
- pjmlp 5y ago
  Only partially, for example whatever Kotlin code you would write to take advantage of those features won't be portable to Android thanks Google, which sucks for library writers.
pulse7 5y ago
Backwards compatibility is GOLD. I hope they will NEVER break it (too much) for Java...
sandGorgon 5y ago
It's already here. It's called Kotlin. And the community loves it so much that even the mighty Google had to adopt it. It's production tested in the largest and hardest java ecosystem out there - android apps.
- kaba0 5y ago
  Android is tiny compared to the Java ecosystem. Also, Google embraces kotlin mostly because they can’t keep up with JavaTM’s development. OpenJDK is at version 17 with many important changes, terrific performance improvements, etc. Not long ago android didn’t have lambdas, but it is still around Java 8. Kotlin is just syntactic sugar of some newer java features on top of older java.
  - jollybean 5y ago
    Google embraces Kotlin because of IP issues with Oracle.
    - kaba0 5y ago
      No, Google no longer uses anything that could have an issue with Oracle and haven’t been using for a long time. The lawsuit was about an older state of Java and Android.
  - The_rationalist 5y ago
    > Kotlin is just syntactic sugar of some newer java features on top of older java. Looks like someone hasn't actually spent time discovering how amazing Kotlin is.
    - zokula 5y ago
      Kotlin is a PITA to work with and code compared to modern Java.
      - The_rationalist 5y ago

MBCook 5y ago

The Java ecosystem is HUGE. It took python what, over a decade to get people to switch from 2 to 3 didn’t it? I’m just not sure you could ever pull it off. It seems way harder than that. Even with some sort of compatibility layer. I think you’d really end up in more of a perl 6 situation where it’s a different language that would eventually have to be renamed due to confusion.

jollybean 5y ago
They may not have a choice, because J1 has problems evolving and it takes a decade (or never) to make major improvements. Just leave it and support it for another 20 years on the side. A lot of isolated Java could remain V1 no problem. Allow new starts, separate modules, and those that want to port a J2. Python 3 was a disaster because they never bothered to think about it, provided no facility for it, didn't care about collisions at the platform level. Oracle could literally pay for the most important OSS modules to be ported, give architectural guidance scripts to transform old codebases, special test units, training. Python and Javascript are ironically two of the biggest messed in all of tech, that gain popularity and drag everything into the mud with them.
- kinjba11 5y ago
  "Java 2" is already out - it's Kotlin (or Scala if you're so inclined) ;) Unfortunately the more compatible you are with "V1" the more compromises you have to make. See: Kotlin, F#, TypeScript bending over backwards to maintain compatibility with the dominant language of their respective platforms. Not to mention C++. You have to admire the hutzpah of Python 3 level of changes. Some software should simply have a "sell by" date and be thrown out when it starts to stink. That said I'm surprised more languages haven't attempted the approach of Rust with 'editions'. > There are times, however, when it is useful to be able to make small changes to the language that are not backwards compatible. The most obvious example is introducing a new keyword... Editions are the mechanism we use to solve this problem. When we want to release a feature that would otherwise be backwards incompatible, we do so as part of a new Rust edition. [https://doc.rust-lang.org/edition-guide/editions/index.html https://doc.rust-lang.org/edition-guide/editions/index.html]
  - kaba0 5y ago
    As mentioned in the article, “A growable language” shows us that a programming language has to evolve. I think Java does an excellent job of not including everything and the kitchen sink right away, but wait a bit for the hype to die off and usually implements new features when they are worthy, often in a superior way. This “last mover advantage” was even part of the initial ideas behind Java.
    - kinjba11 5y ago
      The last movers advantage is a tradeoff. It becomes increasingly difficult to make major paradigm shifting changes the further you go. Being conversative increases the length of the runway and Java has benefited from that. Though, the superiority of Java's version when it finally gets some feature is often debatable. Two major initiatives for many years in Java have been Loom and Valhalla. A cynical take on that is that Java is attempting to copy something that Go and C# (and others) have had and excelled at for a decade or more, and were designed to do from the start. Sometimes, at some point the expense and complexity of dragging decades of code forward (with all accumulated mistakes, design assumptions made based on now obsolete hardware, backwards compat constraints, etc.) outweighs the cost of going back to the drawing board to start again.
      - kaba0 5y ago
        But Java attempts to “copy” those with an order of magnitude larger ecosystem, with the benefit of all the other optimizations/state of the art GCs that went into the OpenJDK project, and with true backwards compatibility of the billions of lines of code out there. I don’t think that reinventing the wheel would really put us forward. According to the ‘No silver bullets’ article, there is no significant (that is, order of magnitude) productivity improvement in language design since high level languages. The only such bullet is reusing existing libraries. (Also, do note that we still rely heavily on numerical libraries written in fortran)
        kinjba11 5y ago
        I agree the order of magnitude improvement is no more. Programming in C is much the same as Java. Both are high level curly brace languages. But there is room for improvement still, quite a bit. The fact that Kotlin, Go, etc. were created and became popular supports the fact that large numbers of folks believed that Java's design direction has run it's course to some degree. I may be proven wrong, Valhalla and Loom could be smashing successes and everyone will flock back to Java. But more likely it will take a decade to reap the benefits of the features Valhalla and Loom would provide, benefits already being reaped by other ecosystems right now. State of the art GCs are incredible - but there is a reason you see Java pioneering the GC area, that being that Java has the most to gain because of its tendency to create enormous amounts of garbage, which is a problem other language designs do not suffer from nearly as much, letting them get away with simpler GC while maintaining high performance. And Fortran isn't the only game in town for high performance numerical libraries ;) There is large incentive to reinvent there, as legacy doesn't matter if the new thing has more performance - Eigen, cuBLAS/CUDA, and others are in C++, not Fortran as far as I'm aware. Fortran has momentum no doubt, but it has been on its way out for a long time.
fnord77 5y ago
yeah, people/projects are clinging to java 1.8 even though there's been huge improvements in the newest VMs

hashmash 5y ago

When new Java features like this are added, it also includes new features and optimizations in the JVM itself. Other languages that compile to the JVM can take advantage of these new features as well, either with no effort, or incrementally.

jollybean 5y ago
They can do just the same for a non-backwards compatible jump.
pjmlp 5y ago
Only partially, for example whatever Kotlin code you would write to take advantage of those features won't be portable to Android thanks Google, which sucks for library writers.

pulse7 5y ago

Backwards compatibility is GOLD. I hope they will NEVER break it (too much) for Java...

sandGorgon 5y ago

It's already here. It's called Kotlin. And the community loves it so much that even the mighty Google had to adopt it. It's production tested in the largest and hardest java ecosystem out there - android apps.

kaba0 5y ago
Android is tiny compared to the Java ecosystem. Also, Google embraces kotlin mostly because they can’t keep up with JavaTM’s development. OpenJDK is at version 17 with many important changes, terrific performance improvements, etc. Not long ago android didn’t have lambdas, but it is still around Java 8. Kotlin is just syntactic sugar of some newer java features on top of older java.
- jollybean 5y ago
  Google embraces Kotlin because of IP issues with Oracle.
  - kaba0 5y ago
    No, Google no longer uses anything that could have an issue with Oracle and haven’t been using for a long time. The lawsuit was about an older state of Java and Android.
- The_rationalist 5y ago
  > Kotlin is just syntactic sugar of some newer java features on top of older java. Looks like someone hasn't actually spent time discovering how amazing Kotlin is.
  - zokula 5y ago
    Kotlin is a PITA to work with and code compared to modern Java.
    - The_rationalist 5y ago