3 ms·

I'm always amazed by how much thinking and work the Java leads put in rolling out changes that move the language forward, but make it backward compatible as muc

I'm always amazed by how much thinking and work the Java leads put in rolling out changes that move the language forward, but make it backward compatible as much as possible.

germandiago 2mo ago
Rhis is the correct way to do it in enterprise environments. C++ gets a lotof rage for doing the same thing. The last thing you want in an enterprise environment is that your working code breaks and you have to commit more time to things that were working before.
- cogman10 2mo ago
  What I do like about java is that when breaking changes must happen (and they do occasionally), they are almost always small and the java authors signpost it WELL in advance of making the break. For example, this is technically legal in Java and will probably work today. Both foo and bar will synchronize on the same referenced object due to the integer cache. This is something that will break when value types land for real. void foo() { Integer i = 1; synchronized(i) { doEvil(); } } void bar() { Integer i = 1; synchronized(i) { doEvil(); } }
  - germandiago 2mo ago
    Yes. Having a strong spec helps also in general. I think that, with all things on the table, backwards compatibility, a spec and, where things are broken things are signaled should be the standard for enterprise grade non-toy apps. Of course, breaking something should be kept to the minimum. That is why I keep using C++ and, if I have to do backend in the future for webs, I will probably choose Java over C#: stable, multi-vendor, will work in 10 years, stable.
    - cogman10 2mo ago
      Agreed. I'm just happy that Java is willing to make a break when necessary. They do an excellent job of avoiding it at all costs but they won't nuke a very needed feature (like value types) if they can't deliver it without making some small breaks. You can be pretty sure that a jar compiled for Java 1.0 will work on a Java 25 VM, and that's pretty great.
- groundzeros2015 2mo ago
  Whatever Java is doing seems a few orders of magnitude smoother and saner than C++ (and I like C++).
  - germandiago 2mo ago
    It depends on how you look at it. C++ is very different since it is native. Java is a VM. This affects lots of decisions in weird ways. But in essence both commit to backwards stability at the end. C++ goes for performance, JVM for a more full-featured bytecode vm, etc. but still.
    - groundzeros2015 2mo ago
      None of that prevents Java from blowing up their language with complex features. They are somehow able to sit back and work on proposals for years and end up with what makes sense for the language.
      - cogman10 2mo ago
        One thing the Java architects have said is they let most of the complex feature development happen outside of Java, which is pretty nice. They let the likes of Kotlin, C#, C++, Scala, Haskell, etc all explore their own little features then they figure out if it could be integrated with Java and what it'd look like. I really like that approach because it's slow, methodical, and the features typically are very well aligned with Java. None of them feel particularly out of place. Java's preview system also works pretty well to get these features refined over time.
    - pron 2mo ago
      The JVM goes for performance, too, only with an emphasis on the performance of larger programs. It's designed to address some of the serious performance issues that large C++ programs tend to suffer from (I originally made the switch to Java because it was getting hard to keep the large C++ applications we were working on fast enough; Java does some optimisations that are hard for a C++ compiler).

I'm always amazed by how much thinking and work the Java leads put in rolling out changes that move the language forward, but make it backward compatible as much as possible.

germandiago 2mo ago

Rhis is the correct way to do it in enterprise environments. C++ gets a lotof rage for doing the same thing. The last thing you want in an enterprise environment is that your working code breaks and you have to commit more time to things that were working before.

cogman10 2mo ago
What I do like about java is that when breaking changes must happen (and they do occasionally), they are almost always small and the java authors signpost it WELL in advance of making the break. For example, this is technically legal in Java and will probably work today. Both foo and bar will synchronize on the same referenced object due to the integer cache. This is something that will break when value types land for real. void foo() { Integer i = 1; synchronized(i) { doEvil(); } } void bar() { Integer i = 1; synchronized(i) { doEvil(); } }
- germandiago 2mo ago
  Yes. Having a strong spec helps also in general. I think that, with all things on the table, backwards compatibility, a spec and, where things are broken things are signaled should be the standard for enterprise grade non-toy apps. Of course, breaking something should be kept to the minimum. That is why I keep using C++ and, if I have to do backend in the future for webs, I will probably choose Java over C#: stable, multi-vendor, will work in 10 years, stable.
  - cogman10 2mo ago
    Agreed. I'm just happy that Java is willing to make a break when necessary. They do an excellent job of avoiding it at all costs but they won't nuke a very needed feature (like value types) if they can't deliver it without making some small breaks. You can be pretty sure that a jar compiled for Java 1.0 will work on a Java 25 VM, and that's pretty great.
groundzeros2015 2mo ago
Whatever Java is doing seems a few orders of magnitude smoother and saner than C++ (and I like C++).
- germandiago 2mo ago
  It depends on how you look at it. C++ is very different since it is native. Java is a VM. This affects lots of decisions in weird ways. But in essence both commit to backwards stability at the end. C++ goes for performance, JVM for a more full-featured bytecode vm, etc. but still.
  - groundzeros2015 2mo ago
    None of that prevents Java from blowing up their language with complex features. They are somehow able to sit back and work on proposals for years and end up with what makes sense for the language.
    - cogman10 2mo ago
      One thing the Java architects have said is they let most of the complex feature development happen outside of Java, which is pretty nice. They let the likes of Kotlin, C#, C++, Scala, Haskell, etc all explore their own little features then they figure out if it could be integrated with Java and what it'd look like. I really like that approach because it's slow, methodical, and the features typically are very well aligned with Java. None of them feel particularly out of place. Java's preview system also works pretty well to get these features refined over time.
  - pron 2mo ago
    The JVM goes for performance, too, only with an emphasis on the performance of larger programs. It's designed to address some of the serious performance issues that large C++ programs tend to suffer from (I originally made the switch to Java because it was getting hard to keep the large C++ applications we were working on fast enough; Java does some optimisations that are hard for a C++ compiler).