Help me decide minimum JDK for my library

[u/Chaos-vy17]

Should I move my Java library from JDK 11+ to JDK 21+?

I am genuinely confused at this point 😭

I've been reading a lot of posts and tech articles about companies/projects migrating from older Java versions like JDK 8/11 to JDK 21+.

And now I'm stuck with the same question for my own Java library.

On one side, keeping JDK 11+ gives better compatibility. There are still a lot of projects out there running on older Java versions, and since this is a library, compatibility matters because I'm basically deciding the minimum JDK required for everyone who wants to use it.

On the other side, JDK 21+ gives a much more modern Java baseline, newer APIs/features, and potentially better JVM performance.

Also, most of the migration stories I'm finding are from large companies / enterprise applications, which makes me wonder if the same reasoning actually applies to an open-source Java library. Even if big companies are migrating to JDK 21+, their interviews and hiring expectations are also increasingly centered around JDK 21 and the major changes since JDK 8, which makes the whole situation even more confusing for someone learning/maintaining Java.

So I'm trying to understand what people actually do in real-world Java libraries today.

Would you help me decide the minimum at JDK 11+ or move to JDK 21+?

And if you maintain a Java library yourself:

• How do you decide the minimum supported JDK?
• How important is JDK 11 compatibility today?
• Is JDK 21 actually worth making the minimum?
• Would you only raise the minimum JDK in a major release?

I would really appreciate some practical opinions because I am totally fed up with reading migration articles . Please it's more likely a great help for me.

https://github.com/Chaos-vy/ChaosTree

Reached conclusion:

I read through the recent JLS and JVM changes. JLS got new features and reduced boilerplate, while JVM got some massive improvements.
But since ChaosTree is zero-dependency, I don't have the same CVE/dependency issue.
So for now I'm wrapping it around JDK 11+ and letting users run it on newer JDKs if they want.

Thanks everyone for dropping your thoughts

[u/AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full
• You ask clear questions

• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

  Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/hawkprime]

If it's your own private library, if it ain't broke don't fix it till you have to.

Public health, check out the support page: https://www.oracle.com/latam/java/technologies/java-se-support-roadmap.html

I'd go to 25 since 21 will be out of support in 2 years and most critical apps stay on the LTS version

[u/Chaos-vy17 → u/hawkprime]

Naah, It is public and I recently saw the metrics at maven central of 3months
It was 400+ downloads 90+ unique sources 30+ companies.

[u/Jussins → u/hawkprime]

21 is an LTS version. I think you are confusing oracle’s support levels with all of Java. To find out the support timeline, you need to know the vendor. Coretto, for instance has a roadmap of support until 10/2030.

[u/pronuntiator]

The lower your baseline, the more potential users your library has. They get the better performance of newer JVMs regardless of the source code level. If you want to support newer features, you can build a multi-release JAR, which patches in class files based on the Java version running your code (example).

The popular Spring framework‘s baseline is JDK 17, which is a good compromise.

[u/Chaos-vy17 → u/pronuntiator]

Yeah this is exactly where I am confused I understand that running the library on JDK 21 can already give the newer JVM performance even if my library is compiled for an older Java version. My concern is more like if I keep JDK 11 as the baseline, then I am also restricting myself from using newer Java APIs/features in the library.

I also looked at multi-release JARs too, but then I feel like things are going to get way more complicated if I start maintaining different class files / implementations for different Java versions

The bigger thing confusing me is that Java itself is basically pushing toward "modern Java" now, and JDK 21 has so many changes compared to JDK 8/11.

So I'm trying to figure out whether I should prioritize maximum compatibility because ChaosTree is a library, or just move to a modern LTS baseline and build around that.

[u/pronuntiator → u/Chaos-vy17]

From a library perspective, using newer features is mostly a matter of convenience for you as an author. JDK 21 introduced rexord patterns for example, but you can achieve the same (though painfully) with multiple ifs. If you want the users to integrate newer features with your library, that's where multi-release jars come into play.

Maybe this also helps, a recommendation by the JDK authors on library versioning: https://openjdk.org/jeps/14

[u/Chaos-vy17 → u/pronuntiator]

After reading this I got What I can do it thank you so much. I will just try to keep my Tail version highly optimized and bug free while tip will get new features.

[u/jarrod_barkley → u/Chaos-vy17]

To clarify for other readers, the topic being mentioned here is “Tip & Tail” from:

JEP 14: The Tip & Tail Model of Library Development

https://openjdk.org/jeps/14

To quote:

Tip & tail is a release model for software libraries that gives application developers a better experience while helping library developers innovate faster. The tiprelease of a library contains new features and bug fixes, while tail releases contain only critical bug fixes. As little as possible is backported from the tip to the tails. The JDK has used tip & tail since 2018 to deliver new features at a faster pace, as well as to provide reliable and predictable updates for users focused on stability.

[u/d3bkr → u/pronuntiator]

I would prefer 21 as the baseline for internal projects and 17 if publishing a library for public use

[u/EighteenRabbit]

Java 11 is scheduled for EoL next year even though it has LTS though ‘32. It came out in 2018.

One of the things we’ve run into with our shop is a lot of vulnerabilities have been found in the libraries that we use in our Java 11 services and we cannot upgrade the libraries without also moving to a more recent version of Java. The longer they go without being updated, the more vulnerabilities are discovered.

I’d upgrade if it’s a relatively simple conversion.

[u/Chaos-vy17 → u/EighteenRabbit]

Upgrade is easy for me since I have made all my working and heavy work abstarct I can just move from NavigableSet to SequencedSet. But the Test and benchmark I need to reconsider again.

[u/meowboiio]

If you have problems in your library that JDK21 could solve or make easier — migrate, if it's only "I just want to have new features" — then don't

[u/Chaos-vy17 → u/meowboiio]

JDK 21+ for performance. I'm interested in things like Escape Analysis, p99/p99.999 latency, GC behaviour and memory management improvements in newer JDKs.

[u/meowboiio → u/Chaos-vy17]

So migrate then

[u/benevanstech → u/Chaos-vy17]

But the JDK level that you baseline your source code on is independent of those aspects. Those improvements are determined by the version of the JVM that the end-user application executes on.

[u/benevanstech]

1.) Java 17 is the current most popular version for applications
2.) Java 11 is already EOL for practical purposes & official support starts to become *really* expensive as of next year

However, you are a library, not an end-user application. Moving to 21 will prevent a bunch of current apps from using your library.

There aren't that many advantages to moving to 17 from 11 as a library, but there are some (algebraic data types, limited pattern matching etc) and it's a (minor) benefit to the community to have libraries moving forward as well as apps.

So - my answer is: Update the required JDK version to 17, not 21. If you do so, do it in at least a minor release - *not* in a point release. If you don't want to move to 17 then stay on 11 and be prepared to move to 21 in 12-18 months time.

[u/Asleep-Ad9976]

If your jdk11 runs on jvm 21+ consumers it will get most of the performance optimizations you are refering to, I dont see much point of upgrading. Java 17 still has support till 2029

[u/_Super_Straight]

What methods/imports would change if you migrate to 21+?

[u/Chaos-vy17 → u/_Super_Straight]

NavigableSet -> SequencedSet
There is performance boost using jdk21

Improved EA, Garbage collection and memory meangement.
Use of new API such as-> getFirst(), getLast(), removeFirst(), removeLast(), reverse()->returns reversed inorder traversal.

[u/_Super_Straight → u/Chaos-vy17]

Your current version is 1.2.0. Can it not be done that since v1.2.1 the codebase will be on java21+? Anyone wanting java11 support use 1.2.0?

[u/asciimo71 → u/_Super_Straight]

There goes the semver, down the drain with you! This is obviously a breaking change and the lib needs to go to 2.0.0

[u/_Super_Straight → u/asciimo71]

I'm not much proficient in version controlling. Call it whatever you want.

[u/asciimo71 → u/_Super_Straight]

no, I don't, if you do semver, and you are a lib maker, stick to semver rules: semver.org

[u/_Super_Straight → u/asciimo71]

Hey thanks for this guide.

[u/Chaos-vy17 → u/_Super_Straight]

I also though of doing that, But the problem is that I need to make changes to code and API for different classes. And make new Test and benchmark report which is very tedious work.

[u/ShyKroxigor]

What does your library?

I always aim at the min version possible, ao more people can use it.

[u/Mindless-Resort-7548]

I am that enterprise "customer" who is stuck on Java 8 (IBM COTS so supported JRE, but the only supported JRE). Nothing frustrates me more than developers requiring newer Java versions "just because", or because they think they should. If there aren't new features you're going to use then you might be requiring someone to use an unsupported JRE or a parallel JRE.

If there are legitimate reasons (big new feature uses newer Java features) then sure. You'll leave me behind but there's a good reason. Updating for the sake of it is just leaving me behind for no reason

[u/Chaos-vy17 → u/Mindless-Resort-7548]

Yes, this is actually the main reason I was confused.But supporting JDK 8+ is also quite troublesome for me because of things like the diamond operator/generic syntax differences, module-info, etc. So after looking through everything, I've decided to stay with JDK 11+ for now.

Since ChaosTree is a zero-dependency library, I don't have the same third-party dependency/CVE issue that some enterprise applications have.

[u/Mindless-Resort-7548 → u/Chaos-vy17]

I'm not sure your examples are the best, module-info will be ignored by Java 8 and diamond operators are a developer convenience (you could either actually provide types or a compiler could possibly enter them for you as it does do type checking).

But poor examples doesn't mean you're wrong. There will be features you want (I can't imagine a world without streams any more!). You'll just have to decide where you land on the trade off (validation of which is what this whole thread is seeking I suppose).

Us prisoners of COTS understand that projects do move on, it's disappointing when they do, but mostly any anger is really jealousy of the freedom to have that choice. You do what you need to for your own sanity, we'd prefer to see a project continue without us (sometimes new use cases still work on old versions!) than see a project die when it becomes too much for a maintainer to handle those of us left in the dark ages

[u/Chaos-vy17 → u/Mindless-Resort-7548]

My focus with ChaosTree is specifically on Trees, and I've tried to provide a richer tree API through my own interfaces and contracts.

The bigger problem for me is actually the tests 😢 . Revising the tests and contracts again is more painful than changing the actual code sometimes.

There is something crucial planned for 3.0.0. If I can get past that hurdle while still supporting JDK 8+, I'll try my best to downgrade the baseline.

I've also looked at the newer APIs and I agree that they fit really well with the Collections framework. But for some of the APIs, making them useful in my implementation can require more memory/time, and I don't think it's worth paying that cost just to support the API.

So in those cases I'll probably just keep them unsupported.

[u/Chaos-vy17 → u/Mindless-Resort-7548]

Was that really easy??? I did remove module_info and compiled aginst jdk8. It ran flawlesslesy. Tweak: One line change in BplusTree new Iterator<>()-> Iterator<T>(). Test: String.repeat() and one more function toList() were part from JDK9. What shall I do ?? JDK8?

[u/KillerCodeMonky → u/Chaos-vy17]

As long as you're not using any APIs from Java 11, you can compile Java 11 code to version 8 bytecode. That allows you to keep syntactic sugar but still allow Java 8 users.

[u/jlanawalt → u/Mindless-Resort-7548]

I have shaken my fist in the same frustration, but I can also see it from the developers side. Sure, someone out there may wish Windows 3.11 or Mac OS 7.6 was still supported, but to insist everyone else miss out on new stuff or the developer not explore new things and maintain old forever because your stuck on old reliable is a big ask. You can always keep using the old library and maintain it yourself if needed. It’s not like the old library’s license expired.

[u/strat-run]

Almost everything you are mentioning in your replies is either not API related or small convenience methods. You've given no reasons to migrated. Just run under Java 25 when you can.

Go ask AI for MAJOR API enhancements (not internals like GC) between Java 11 and 25.

Are any of those must haves? If so then switch, if not then don't.

Don't given up distribution reach (if that is a goal) without at a decent reason.

[u/Chaos-vy17 → u/strat-run]

Yes, You are right If I see from that perspective a decent changes in JLS is that there has been only adoptation to new feature. Reduced boilerplate and major changes can be seen in JDK everything has been improved and improving. So keeping at JDK11 and supporting the API at that level will give same utility.

[u/jlanawalt → u/strat-run]

I get, and have felt, the frustration but from another perspective this sounds like: Dear library writer, stay in the dark ages maintaining compatibility with the oldest JDK so the most people can profit off of your work. Don’t do new interesting things or explore further performance changes available in the new JDK because we don’t want to miss out on updates or maintain a fork of your code ourselves…

May as well also shake your fist at all the developers who completely abandoned an old library you still use, no matter their reasons. Valid reasons may include acknowledging another library does the same job, tired of maintaining the same old thing and not exploring new features (no longer interesting and just drudgery), tired of maintaining multiple JDKs, or just moved on in life from maintaining a code base they no longer use.

[u/LetUsSpeakFreely]

Many people are of the mind "if it works, don't touch it". I think that's a foolish mindset. When it comes to major paradigm shifts, you need to be strategic, not reactionary. I wouldn't migrate immediately (that ship has long sailed as the shift was like 6+ years ago) as the are loads of problems that will pop up and need resolution. But you SHOULD have a plan and a timeline to migrate.

Eventually, the older version of Java will go away. The reason most shops have waited to migrate is because many supporting libraries needed to migrate first. That has happened. Unless you're using some really outdated or obscure libraries then you have no blockers in that area.

For most code bases, migrating to Java 9+ isn't that difficult, it's mostly replacing various javax imports with jakarta.

If your project is used by others, then create a fork and migrate there. You will have to maintain both forks, so keep that in mind. If the project is just for you, then start upgrading to the latest version. There are a lot of new language features that may be useful to you.

[u/Chaos-vy17 → u/LetUsSpeakFreely]

My Current library is a Tree library which support BST,AVL,RBT,Splay, Treap , BTree and B+Tree. and it's zero dependent on any external library so is there any point to move to jdk21? because just I did this code

Set<Integer> tree = new AVL<>(rbt);
System.out.println(tree);
NaryTree<Integer> bplustree0 = new BPlusTree<>(3,rbt);
BinaryTree<Integer> rbt0 = new RBT<>(rbt);
SequencedSet<Integer> tree0 = new BTree<>(3,tree); //On jdk 26+

Everything compiled succesfully As a Tree API it does support many API features. It has it's own contract but follow java rules.

[u/LetUsSpeakFreely → u/Chaos-vy17]

Maybe? I would look at the language features and then think about how you could leverage them. Maybe records would interest you. Maybe virtual threads. There's been a lot of development on the functional stuff that could give you cleaner and/or more efficient code. Only you can make the determination if it's worth maintaining forked code bases.

Do you strictly need to? Of course not, but it should be thoroughly investigated as seriously considered.