4 ms·

Java 8 -> anything 11+ wasn't great at scale. It's been smooth sailing for a long time again though.

by jameslars 1y ago

ffsm8 1y ago
Uh, wasn't the only breaking change a rename/changed path in some standard lib path?
- cess11 1y ago
  Deprecations, which also affects libraries, i.e. the dusty one you were chugging along on top of might need to be replaced or adopted because the original maintainer gave up years ago.
- pjmlp 1y ago
  Introduction of modules, closing down of APIs that no one should be using, since Java 9 deprecated methods actually get removed a few versions later. Also breaking changes do happen, see list of removed methods https://docs.oracle.com/en/java/javase/17/migrate/removed-apis.html#GUID-44E8E37A-3000-47C6-B851-CDEB3FB50495 https://docs.oracle.com/en/java/javase/17/migrate/removed-ap...
  - cesarb 1y ago
    On top of that, there was the removal of built-in J2EE; you needed to add external copies of the J2EE pieces, and some of them (like CORBA) weren't available as separate packages. And later versions of these external J2EE packages changed the namespace of all their classes, which is especially painful in Java due to its common use of dynamic loading of classes by name and lazy linking (and lazy linking errors do not inherit from Exception, which allows them to escape from catch-all "catch (Exception e)" clauses). The rest of the ecosystem is starting to depend on these new versions, so staying with old versions of these J2EE packages is not an option.
  - hinkley 1y ago
    The fact that Sun never removed any deprecated methods even after they were proven dangerous was a sticking point that generated friction between coworkers over new code using deprecated functionality.
patates 1y ago
What started as a "this should be just a few namespace changes" might have cost thousands of person days in my current job. So many tests red, the whole CI/CD broken, and when all "fixed" and done, there were still some uncaught production bugs haunting us for many months... Simply horrible. On paper, it really was just a few changes. In practice, it forced a massive transitive dependency and technical debt cleanup for many companies.
pandemic_region 1y ago
I don't remember anything significantly bumpy for about 30 large-ish applications we migrated from 8 to 11, guess the mileage varied. JDK is serious stable stuff.
hinkley 1y ago
Java 4 to 5 was very rough. Sun kept trying to defer major changes, sort of how Elixir claims it is mostly done. But something changed in 5 and the floodgates opened. They made too many changes at once, and so out in the field you would bump into projects stuck on Java 4 even as 6 was in beta. And then 7, and a few past that.
motbus3 1y ago
Honest question. Is java whatever version today worth learning again? Java is something I shoved of my life together with the MS stuff and never looked back, but there is still plenty of market for it anyway

Java 8 -> anything 11+ wasn't great at scale. It's been smooth sailing for a long time again though.

ffsm8 1y ago

Uh, wasn't the only breaking change a rename/changed path in some standard lib path?

cess11 1y ago
Deprecations, which also affects libraries, i.e. the dusty one you were chugging along on top of might need to be replaced or adopted because the original maintainer gave up years ago.
pjmlp 1y ago
Introduction of modules, closing down of APIs that no one should be using, since Java 9 deprecated methods actually get removed a few versions later. Also breaking changes do happen, see list of removed methods https://docs.oracle.com/en/java/javase/17/migrate/removed-apis.html#GUID-44E8E37A-3000-47C6-B851-CDEB3FB50495 https://docs.oracle.com/en/java/javase/17/migrate/removed-ap...
- cesarb 1y ago
  On top of that, there was the removal of built-in J2EE; you needed to add external copies of the J2EE pieces, and some of them (like CORBA) weren't available as separate packages. And later versions of these external J2EE packages changed the namespace of all their classes, which is especially painful in Java due to its common use of dynamic loading of classes by name and lazy linking (and lazy linking errors do not inherit from Exception, which allows them to escape from catch-all "catch (Exception e)" clauses). The rest of the ecosystem is starting to depend on these new versions, so staying with old versions of these J2EE packages is not an option.
- hinkley 1y ago
  The fact that Sun never removed any deprecated methods even after they were proven dangerous was a sticking point that generated friction between coworkers over new code using deprecated functionality.

patates 1y ago

What started as a "this should be just a few namespace changes" might have cost thousands of person days in my current job. So many tests red, the whole CI/CD broken, and when all "fixed" and done, there were still some uncaught production bugs haunting us for many months... Simply horrible. On paper, it really was just a few changes. In practice, it forced a massive transitive dependency and technical debt cleanup for many companies.

pandemic_region 1y ago

I don't remember anything significantly bumpy for about 30 large-ish applications we migrated from 8 to 11, guess the mileage varied. JDK is serious stable stuff.

hinkley 1y ago

Java 4 to 5 was very rough. Sun kept trying to defer major changes, sort of how Elixir claims it is mostly done. But something changed in 5 and the floodgates opened. They made too many changes at once, and so out in the field you would bump into projects stuck on Java 4 even as 6 was in beta. And then 7, and a few past that.

motbus3 1y ago

Honest question. Is java whatever version today worth learning again? Java is something I shoved of my life together with the MS stuff and never looked back, but there is still plenty of market for it anyway