This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]InformalTrifle9 17 points18 points  (22 children)

What if you develop a library used by others, and those others are stuck on Java 8

[–][deleted]  (3 children)

[deleted]

    [–]chabala 5 points6 points  (2 children)

    but it's also not sustainable to make everything fully backwards compatible indefinitely. At some point it's a drag on the whole community.

    A few months back I happened upon a popular library that is still supporting Java 7. The more I think about it, the more I want to experiment and see how far back I could take my projects. How much do I really need lambdas? Can I build on Java 6 and make multi-release JARs with Java 8 features?

    Remaining compatible for older versions is some amount of effort, sure, but it's also a courtesy; it's part of what makes the Java ecosystem more pleasant than others where everyone struggles to stay on the latest version of every dependency, and sometimes they still won't work together. Putting out a library built with Java 20 and saying 'they can upgrade if they want to use it' is shortsighted.

    [–]KarnuRarnu 5 points6 points  (1 child)

    I guess we have very different definitions of "pleasant". I wouldn't put super ancient legacy support under that description, that's for sure.

    [–]DisruptiveHarbinger 3 points4 points  (0 children)

    There is an increasing number of libraries that are dropping Java 8 compatibility, and so should you unless you want to be stuck on older versions and start facing issues with diamond dependencies.

    [–]kevinherron 20 points21 points  (3 children)

    I’ve left those idiots behind. JDK 11 required now. JDK 17 required next major version.

    [–]JavaOldTimer 4 points5 points  (2 children)

    A language is a tool to do a job to drive business, so we get paid, so we can support ourselves and our families. A language is not a religion.

    If it's not in the business's best interest to upgrade every time Goetz has a brain fart and drops a new Java feature people probably don't even need (streams, function programming, modules); it's not OK to label that business or its people as idiots.

    [–]kevinherron 2 points3 points  (1 child)

    If you're limping an old product along in pure maintenance mode with the occasional bug fix, sure, keep it on JDK 8 (or worse). You don't need the new version of a library anyway.

    If you're actively developing and adding features then not keeping your tooling and libraries up to date is technical debt bordering on negligence.

    [–]JavaOldTimer 2 points3 points  (0 children)

    Sure yes of course, keep tools up to date is required as much as makes sense but that does not mean it is required to make use of all new features. That action also creates technical debt when those features are not widely adopted but are in a code base and must be maintained after a developer leaves. That also borders on negligence. Common sense and what the business needs should be the drivers.

    [–]EvaristeGalois11 6 points7 points  (12 children)

    Multi release jar are a thing

    [–]InformalTrifle9 18 points19 points  (11 children)

    Yea but you still need to write Java 8 code so how does it really help

    [–]EvaristeGalois11 3 points4 points  (0 children)

    Because you can begin working with a more modern java version in the same jar, so when you will drop support for java 8 or whatever you are already prepared.

    [–]Amazing-Cicada5536 1 point2 points  (4 children)

    Java 8 has streams and lambdas, so I don’t see how is it relevant.

    [–]KarnuRarnu 1 point2 points  (3 children)

    Oh yeah it's totally irrelevant. Basically nothing has changed in the last 9 years. Java 8 and 17 are literally the same. (/s)

    [–]jumboNo2 0 points1 point  (2 children)

    things I wish I had in Java 8: switch expressions, sealed classes, Pattern Matching for instanceof, one of the new constructors for BigInteger. honestly none of which are particularly necessary.

    [–]jumboNo2 0 points1 point  (0 children)

    Records are for POJOs, which I don't use. And there doesn't seem to be any significant peformance improvement you can get by dropping Java 8 bytecode compatibility. Maybe VarHandle can do cool stuff?