7 ms·
breaking changes? hardly.
by roegerle 7mo ago
breaking changes? hardly.
- hu3 7mo agoYes, breaking changes. And many ways to do the same thing because the language kept evolving (thankfully).
- nitwit005 7mo agoThere is a decently long list of breaking changes now. Removing JavaEE modules from the JDK, and restricting sun.misc.Unsafe, are the ones people usually run into.
- gf000 7mo agoThese are relatively small-scoped library changes only though. Meanwhile Go already had a language change, while being less than half its age (loop variable capture).
- nitwit005 7mo agoA long enough list of small changes eventually equates to a big change. People generally can't update applications from Java 8 or below to a new one without code updates.
- gf000 7mo agoMostly an automatic updater call (for javax->jakarta) and a few dependency bumps away in the majority of cases. Plain vanilla java code is really backwards compatible, on both a syntax, and on a binary level. You can often find decades old jars on some random university site, working with JDK 25 with no issue.
- waynesonfire 7mo agoIf hadoop did it, so can you. I'm talking about a project that stretched Java 8 to, and arguably beyond, its intended operational boundaries. Unlikely that you’re leaning on this boundary. It's Spring Boot upgrades that will be giving you troubles.
- nitwit005 7mo agoThey clearly did have Java version issues, as the different Hadoop versions list ranges of JDKs they're compatible with.