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 3 days ago | parent [-]

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 3 days ago \| parent [-]
		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.