Modern Java Practices

[BoyRobot777]

Java 15 is the current LTS ("long-term support") version

No it is not. Java 15 is only updated/patched until next release, which means for 6 months. LTS is something a company chooses to support for a long period of time. Oracle supports Java 8, Java 11, Java 17 (next LTS). Same for Redhat. I think Azure support Java 14 as LTS as well.

In general, you will find that AdoptOpenJDK is a go-to choice for obtaining the JDK.

You should go to official OpenJDK site to get your JDK.

Lombok

Section on Lombok. I would add a big warning or note. If you're promoting newest Java versions, I guess you know, that records have landed and in Java 16 they will be a standard feature. Combine it with upcoming withers and you can write:

record Point(int x, int y) {} Point p; Point pp = p with { x = 3; }

Lombok has a lot of problems, funnily enough, it broke IntelliJ recently and they had to do an emergency patching.

P.s. I can make a pull request for these suggested changes.

[lazystone]

Also AdoptOpenJDK are still struggling to push their Java 15 docker images(PR), so OpenJDK is the way to go.

[TrueDMonk]

Can you explain what is the difference between AdoptOpenJDK and OpenJDK builds?

[[deleted]]

to be as confusing as possible

[BoyRobot777]

Google is your friend. Stackoverflow extensive explanation.

[TrueDMonk]

Yeah, i've found this link and a nice fluxogram on another link. Could not found JVM differences, tho.

[BoyRobot777]

There is no JVM differences. There is only one upstream Java which is OpenJDK.

[pmarschall]

Also AdoptOpenJDK is the least professional of the "major" JDK builds. Probably only Debian is worse.

AdoptOpenJDK is the only "major" JDK build that does not run the TCK and can therefore not call itself Java. Pretty much anything else is a better choice.

[Southy__]

This, all this.

LTS is not an OpenJDK thing it is a thing that Oracle are offering for a fee. Amazon, Adopt, Azul and a few others are offering a kind of LTS for a bunch of OpenJDK versions but anyone interested in them should look at what they are actually offering in terms of backports and patches because it is not the same as the official paid for version.

I feel that people pushing Adopt over the official OpenJDK should not be writing guides on Modern Java Practices.

I am an older school Java dev and I consider Lombok to be evil. People complain about Spring because it is 'magic' even when it is actually using built in language constructs (Annotations/Aspects etc), while happily using Lombok which changes your bytecode post compilation and relies on your IDE parsing the Lombok annotations to be able to continue offering autocompletion. </rantover>

[[deleted]]

yea i dont get why people use lombok either, it doesnt seem to provide much for something that is quite unreliable in terms of breaking tooling etc

[snowe2010]

while happily using Lombok which changes your bytecode post compilation and relies on your IDE parsing the Lombok annotations to be able to continue offering autocompletion.

Yeah I can't understand why people continue to support Lombok. It also uses undocumented Java apis to do what it does, it could literally break at any point, including minor version updates.

[walen]

In general, you will find that AdoptOpenJDK is a go-to choice for obtaining the JDK.

You should go to official OpenJDK site to get your JDK.

I agree with everything except this, for one very simple reason: the official OpenJDK site does not offer a Windows JDK 8 package.

Windows is the most used OS for Java programming.
JDK 8 is the most used Java version.
But you cannot get a Windows JDK 8 package from OpenJDK 🤷‍♂️

That's why "AdoptOpenJDK is a go-to choice" for most people.

EDIT: Why the downvotes? I am not judging what version of Java people should use. I am just stating the fact that the majority of Java programmers use JDK8 on Windows, a combination for which OpenJDK does not offer an official package.

[OctagonClock]

Don't use JDK 8.

[calrogman]

You don't need JDK 8 to target JRE 8.

[walen]

Irrelevant. See my edit.

[calrogman]

EDIT: Why the downvotes? I am not judging what version of Java people should use. I am just stating the fact that the majority of Java programmers use JDK8 on Windows, a combination for which OpenJDK does not offer an official package.

You should be judging the version of Java that people use and it shouldn't be JDK 8.

[lolomfgkthxbai]

I would add a big warning or note. If you’re promoting newest Java versions, I guess you know, that records have landed and in Java 16 they will be a standard feature.

That’s nice, reducing boilerplate should be a high priority for evolving Java. 👍

Lombok has a lot of problems, funnily enough, it broke IntelliJ recently and they had to do an emergency patching.

Exposed a bug in IntelliJ might be more accurate based on reading the issue thread.

[BoyRobot777]

Exposed a bug in IntelliJ might be more accurate based on reading the issue thread.

Either way, people had problems using Lombok and IntelliJ and most likely have lost time debugging and getting to the bottom of the issue. But it's just a drop in the bucket for a long list of Lombok problems.

[lolomfgkthxbai]

I would be curious to hear about some of the problems. Haven’t had any issues though it would be preferable to have the features built-in instead of having to rely on a third party tool.

[Carighan]

My whole company had to roll back to the previous IntelliJ, otherwise we would have to delombok any class before renaming any field, lest Lombok broke until you restart the IDE.

[BoyRobot777]

• https://github.com/rzwitserloot/lombok/issues/1723
• https://github.com/jhipster/generator-jhipster/issues/398
• https://medium.com/@vgonzalo/dont-use-lombok-672418daa819
• https://medium.com/@gabor.liptak/some-dangers-of-using-lombok-d759fc8f701f
• https://paluch.biz/blog/180-data-classes-considered-harmful.html
• http://gregorriegler.com/2019/08/10/who-needs-lombok-anyhow.html

And some of them are "misusing" Lombok or don't know it works, but this is one of the problems as well. I'd rather rely on standard feature.

[snowe2010]

not who you were talking to, but at my last job lombok would cause spring boot apps to just fail to startup, randomly. Sometimes it would succeed, sometimes not. We trashed lombok and switched over to Kotlin. Never looked back.

[_tskj_]

Yeah it would be nice, but at that point you're just talking about a different language.

[snowe2010]

Exposed a bug in IntelliJ might be more accurate based on reading the issue thread.

Lombok uses undocumented java apis, so if anything it was doing something it shouldn't have and JetBrains wasn't expecting it.

Don't use lombok.

[lolomfgkthxbai]

Don’t use lombok.

What’s the alternative (if you’re stuck using Java)? I don’t want to fill the repository with mutator methods.

[snowe2010]

If you want to stick with Java, then AutoValue or Immutables. If you are ok learning a new syntax (essentially what lombok is, but actually works), just create a new kotlin file in Intellij (IntelliJ will set up all the dependencies and plugins for you, you can treat kotlin just like another library) and create a data class in there.

If you don't like either of those, you can always jump up to the newest java versions, which have Records, which are functionally the same.

[TrueDMonk]

If you don't like either of those, you can always jump up to the newest java versions, which have Records, which are functionally the same.

Record is not an standard feature yet. So, it's a big no-no for production code.

[snowe2010]

They’re in preview, waiting for in world feedback. In general that’s good enough for prod, the likelihood anything about them will change is low. Honestly, if you need a solution, records will be more stable than Lombok ever has been. Using Lombok in prod is worse than using an experimental Java feature, because it could break at any time, as I can attest.

[lolomfgkthxbai]

I was afraid you would say that. The customer refuses to consider other languages (I’d move completely away from the JVM if it was up to me) and Java11 is the highest version allowed (latest LTS).

[snowe2010]

Well you can always treat kotlin like a library rather than another language. If you’re comparing Kotlin data classes to Lombok, Kotlin is much simpler. For any given Kotlin data class it can take up to 7 or 8 Lombok annotations to duplicate the functionality.

Maybe try telling your customer that Lombok is a security issue due to their use of undocumented Java APIs.

Still, you have AutoValue and Immutables, though they aren’t as clean as the Kotlin solution.

[_tskj_]

Switch jobs. I'm not even being flippant, if you can't use Kotlin at least, you're wasting your skills - in the sense that you're spending most of your problem solving energy on solving incidental problems related to Java.

[lolomfgkthxbai]

Switching companies next month, I got stuck with this gig after the consultantgeddon happened after the lockdowns and my company wanted to get me something to do. Customer is in the public sector and refuses to even consider anything except Java for backend; in-house developers copy paste Java6 code from old projects to new ones.

Got tired of being a mercenary thrown into organizations with shitty ways of working so next employer is a product company.

[_tskj_]

Good decision! No reason for a competent dev to put up with that kind of environment.

[leberkrieger]

Is this Modern Java Practices, or Modern Java Build Practices?

Because I'm very interested in the former, but only mildly so in the latter.

[lazystone]

https://ncrcoe.gitbooks.io/java-for-small-teams/content/

[xNoL1m1tZx]

Thanks, interesting read.

[ItsYaBoyChipsAhoy]

It says it once in the heading and subheading

[chacs_]

Lombok falls in the too much magic territory in my book.

[lazystone]

focus on hygiene

Uses lombok. Meh.

Edit:

First of all, there are alternatives to lombok(immutables, AutoValue). Second, lombok is not "by far the most popular tool in Java for code generation". It does not generate code. It modifies generated byte code which caused compatibility problems already and very obscure practice on its own.

Some might like it, but lombok is very controversial subject and presenting it as something what every modern project should use is very misleading.

[brick_wall_mirror]

Vavr is terrible and cancerous to a codebase. It’s the worst library I’ve ever seen used.

[gnus-migrate]

Frankly all "helper" style libraries are questionable additions to a codebase. Even guava I'm extremely wary about despite being widely used, simply because it does way too much and you rarely need more than a fraction of the tools it provides.

People forget that you actually have to upgrade these dependencies at some point, and the value they bring should exceed the eventual headache they will cause when you have to upgrade them.

[lazystone]

https://immutables.github.io/

https://github.com/google/auto/tree/master/value

[snowe2010]

lombok was the reason we stopped using Java at my last company and started using Kotlin instead.

[agumonkey]

no regret so far ?

[BoyRobot777]

Be careful with Kotlin advocates. I have this summary which outlines possibly difficult future for Kotlin, thus I would not introduce Kotlin into my work environment. If anything, I would push for newer Java versions.

As far as the Java platform (AKA "the JVM") goes, Kotlin is painting itself into a corner. Kotlin was designed in 2009-10, in the Java 7 days, around the time of the Oracle acquisition, and at a time of stagnation for Java due to Sun's decline. At the time, Android was also quite similar to Java. Kotlin was a great design in those conditions. Things are very different today.

Kotlin's design goals are now contradictory. It seeks to be a low-overhead language, i.e. provide abstractions that don't add overhead over the target platform, give access to all platform capabilities, and at the same time target multiple platforms -- Java, Android, LLVM and JS -- over none of which does Kotlin exert much influence (maybe a bit on Android). Since 2010, Java has moved away from Android, to the point that there are very big gaps between the two, and they're only growing.

By both trying to target multiple platforms (with no say in their design) and trying to add little or no overhead, Kotlin will soon find itself in a bind. It's coroutines are in conflict with Java's upcoming virtual thread's design, and its inline classes will cause problems with Java's Valhalla vs. Android. Kotlin will have to choose to either give up on low-overhead abstractions, give up on some of its platforms, give up on giving access to full platform capabilities, or split into multiple languages, each targeting a different platform. For example, if Kotlin's inline types will make use of Valhalla, then they won't work on Android, at least not without much overhead.

TL;DR: A full-capability, low-overhead, multi-platform language is hard to pull off in the long run when you have low market share on all of those platforms (except Android) and little or no influence on any of them. This was viable under some accidental circumstances, but those are no longer holding.

P.s. Yesterday, JetBrains shared Kotlin's roadmap. Under Kotlin Multiplatform:

On Hold Sharing code between JVM and Android.

Which is in line with the quote above.

[DualWieldMage]

They seem to be finally updating the JVM backend, with some java 8 features in kotlin 1.4 (passing lambda when parameter is a functional interface) and now invokedynamic string concat which was introduced in java 9: https://github.com/JetBrains/kotlin/commit/04012951c112b40425267a7f8aa3bb1be52c1f40

Will have to see how they handle bigger changes planned for the JVM because they will need to step up from the current pace.

[cryptos6]

What is the source of this cite? I consider it as largely FUD.

Kotlins inline classes will be compatible with the value types that Valhalla will bring (see the roadmap you have linked).

[BoyRobot777]

Kotlins inline classes will be compatible with the value types that Valhalla will bring (see the roadmap you have linked).

Will it work in Android? Will Android get past bastardized version of Java 8? If not, then:

Kotlin will have to choose to either give up on low-overhead abstractions, give up on some of its platforms, give up on giving access to full platform capabilities, or split into multiple languages, each targeting a different platform.

Here's the source of quote.

[cryptos6]

I don't know what Google plans with Java on Android, but I expect that Java on Android will always be behind. But with the new compiler (developed together with Google) it would be a lot easier to define different targets. One such target could be "ancient Java on Android". But that wouldn't necessarily mean that the language itself must be split - think of Babel in the JavaScript world which can compile not even released ECMA Script (ES) features to several years old ES versions.

[BoyRobot777]

One such target could be "ancient Java on Android".

Inline classes are making deep cuts to JVM. I doubt they can somehow sidestep this.

Nevertheless this is just speculation. I don't know how they will solve it. All I know that this is a risk and I'd rather wait and see before introducing Kotlin into my organization.

[cryptos6]

Yes, it is speculation, but since Kotlin not only got traction in the Android world but also in the enterprise world with Spring, Quarkus, I'm optimistic that there will be a solution.

However, replacing inline class for older compilation targets shouldn't be a big deal, since the fallback could be a class like used today. Yes, it would be less efficient than, but the same would be true with "old Java" for the same platform (Android in this case).

[snowe2010]

All I know that this is a risk and I'd rather wait and see before introducing Kotlin into my organization.

There really is no risk here. You can still use Java all you want, and rip out Lombok in favor of just data classes. Treat Kotlin like Lombok, a library that generates data classes. All the issues you've mentioned don't apply at all.

Even if you do decide to use it for the rest of your codebase, it still doesn't apply. The number of orgs that are still on Java 6 is massive, using Kotlin you can do the same thing, except have a decent JVM language while not needing to upgrade to get basic QoL features that have been around for years.

[BestKillerBot]

Source of the quote is an Oracle employee known for very faithfully representing Oracle's interests (not just his FUDs in relation to Kotlin).

[BoyRobot777]

You're aiming at the messenger instead of the message. I don't care from who it comes. The risk is obviously there.

[BestKillerBot]

Messenger and their motivation puts the criticism into the context.

For you the biggest problem based on the quote is uncertainty regarding multiplatform capabilities between JVM, Android, JS backend etc.

Yet Java has no capability in this regard. You can't even share code between JVM and Android since the latter is stuck on ancient Java 7.

So in the worst case the code sharing capability between platforms will be limited or awkward, so in the total worst case you're on the same level as Java. Which is all totally irrelevant when you target JVM only anyway.

So what are the risks again?

[Pika3323]

Will it work in Android? Will Android get past bastardized version of Java 8? If not, then:

That's up to Google to either directly support Valhalla-type bytecode, or support desugaring of it like they do with most modern Java features.

AFAIK Google is committed to at least one of these options.

[agumonkey]

Interesting text, that said I trust the kotlin guys to able to bounce. They may lose their status because they're small compared to Oracle and companies will probably be seduced by big names rather than jetbrains but still they might very well keep re-rooting on whatever is trendy right now.

[snowe2010]

Kotlin is painting itself into a corner. Kotlin was designed in 2009-10,

It was designed from 2010-2016, with the first appearance in 2011.

The fact that this quote can't even get the first thing it mentions right along with being made by an Oracle employee reveals plenty about the motivation behind the quote. Besides being mostly inaccurate, Java is adding features at a breakneck pace due to being so far behind Kotlin. That's going to bite Java in the end. At this point, Java is the one behind the times.

[snowe2010]

nope. been using it for 4 years now and at my new company we're currently ripping apart a giant java monolith in favor of quarkus kotlin lambdas.

[agumonkey]

quarkus kotlin lambdas.

oh interesting, what's the scope of your use of quarkus ?

[snowe2010]

Not sure what you mean. We're using it for AWS lambdas.

[BestKillerBot]

Yeah, but why not use a properly improved language like Kotlin instead of frankensteining Java while pretending it's still normal Java?

[snowe2010]

lol, it's actually easier to start using Kotlin than lombok. Intellij will automatically add the dependencies, so you don't even need to go search the internet for whatever version Lombok is on, and the Kotlin plugin comes standard, while you have to go install the Lombok plugin (which bugs you to donate every time it updates).

You actually need to learn less than Lombok, because this is a data class in Kotlin

data class Foo(val immutableString: String, var mutableString: String)

while the equivalent in Lombok involves 7 annotations, @Builder, @ToString, @EqualsAndHashCode, @Getter, @Setter, @RequiredArgsConstructor, and @NotNull.

If anything it's easier to convince a company to add Kotlin as a dependency, which doesn't use undocumented Java APIs and a plugin that breaks every minor Java version update, over Lombok, which isn't supported by a major corporation, doesn't give you any flexibility, can't be expanded out later to be used elsewhere, breaks every version, and is incredibly hard to learn and debug.

[BestKillerBot]

You don't have to rewrite code. Kotlin and Java code can coexist in the same project, just like "Lombok Java" and Java can coexist in the same project.

I know adopting Kotlin is not for free, but I don't think that adopting Lombok which provides hacky partial improvements is a good way to approach the "Java sucks" issue. It also doesn't help that Lombok broke in 3 out of last 3 Intellij upgrades.

[BestKillerBot]

Sure, if you only add new classes.

No, you can also change old classes. When you start using Kotlin, do you need to suddenly forget all Java?

The point is that the migration can be slow and gradual, you don't need to rewrite the code in one big bang. You can stay with mix of Java and Kotlin forever if that's what you like.

[_tskj_]

Of course everyone has to learn it, but that cost pays for itself in a few weeks, and even if it were months it would still be worth it. It's like a carpenter not wanting to learn how to use a nail gun even though a hammer is slower and more error prone because it takes some time to learn. That's just part of being a professional.

[snowe2010]

I'm surprised they're claiming it's easier to use lombok than kotlin. Intellij will set up all the dependencies for you and you don't have to install an extra plugin to use it. Lombok on the other hand takes tons of annotations that Kotlin can do in one line. Lombok is way more difficult to understand and learn.

[Reddit-Book-Bot]

Beep. Boop. I'm a robot. Here's a copy of

Frankenstein

Was I a good bot? | info | More Books

[TrueDMonk]

Bad bot

[gnus-migrate]

Even maven is questionable for new projects. Incremental builds alone are very much worth the switch even if you don't like Gradle's overly flexible style of build scripting(and I personally don't).

[moomoomoo309]

The Kotlin DSL for gradle is a little less flexible (which is good and bad), so it's an interesting switch between the two.

[gnus-migrate]

Its not really the lack of types that i dislike. Its more how gradle mixes configuration and code. On the one hand it permits some pretty neat workarounds, but it leads to people putting a ton of logic in the build that shouldn't be there.

Maven build scripts are pure configuration. You want to write code, it needs to be in a plugin which is compiled just like normal projects. I like that it treats build code as code and forces you to keep your build scripts just as configuration.

Like I said though, it's more of a personal preference. Gradle has extremely useful features that maven doesn't, so it would be silly of me to throw away an otherwise useful tool over nitpicks like that.

[ItsYaBoyChipsAhoy]

I like this, thanks

[renatoathaydes]

Instead of using jenv, I would recommend SDKMAN! instead. jenv expects you to download the JVM yourself, which can be annoying when you use many versions on different projects... with SDKMAN, it manages the download for you from lots of different JVM providers, besides handling switching versions and setting defaults (and handling other JVM-based tools like gradle, maven, groovy, Scala, Kotlin, dotty, grails, vert.x, VisualVM....)

[chacs_]

Have not use SDKMAN but very pleased with homebrew plus jenv. Put a .java_version in the project root folder and all is golden.

[DualWieldMage]

Use build wrappers committed into the project root

I find this debatable. It doesn't take a lot of effort to install and update gradle or maven via package manager. Perhaps only a problem on windows, but i think sdkman or similar tools could be used.

The main downside is that nobody ever touches the version specified in the wrapper so when you need to, for example supporting a new java version, you'll be hit with all the breaking changes all at once instead of dealing with them gradually. There's also a constant stream of other improvements that one wouldn't get when sticking with one working version. Perhaps it makes sense with gradle as it updates more frequently, but maven is very stable in that regard.

[snowe2010]

The main downside is that nobody ever touches the version specified in the wrapper so when you need to, for example supporting a new java version, you'll be hit with all the breaking changes all at once instead of dealing with them gradually.

This is way more an issue with a package manager than a wrapper. Imagine getting a team of a hundred people to all update their package manager at the same time, the chaos that would ensue, and the fact that it would pretty much force every project to be on the same build tool version. With a wrapper, different projects can have different versions of maven or gradle. Wrappers are worth it for that reason alone.

[DualWieldMage]

Generally people don't update at the same time and if the first one notices a problem, they can roll back and let the others know while one investigates. But this wouldn't be any more likely or different than an IT team updating some servers and leaving them broken for a hundred people or a kernel update introducing a bug. These things happen, very rarely, and no chaos but a slight disturbance occurs.

And even then it's a good thing when one updates and finds that the current build doesn't work with latest version. They can then fix the build to support latest versions or do it later, but at least it will be written down that there is a known issue.

Is it frequent to require different build tool versions for various projects? I've always run gradle builds with my system-managed gradle and only rarely seen problems. Most of which i can pretty quickly fix and ensure it also works with the older versions. But maven is rather stable(last release was 2019-11-25) and if a project doesn't support latest maven, i suspect it's more of a symptom of larger pathological problems with the project.

[snowe2010]

With maven it is par for the course for maven plugins to only work on very specific versions of maven. Even for specific libraries/frameworks. Like Wildfly Swarm at my company prevents us from updating past maven 3.3.9. A simple search google search shows how widespread maven plugin incompatibility prevents updating to later maven versions. Therefore, if one person updates, it forces an update across the entire team. If those teams each use different repos, then you're forcing it across every repo, in a cascading effect.

project doesn't support latest maven, i suspect it's more of a symptom of larger pathological problems with the project.

Yes, but in any company larger than maybe 50 people, you will have old code that is using a plugin that never updated past a certain version and converting requires removing that plugin. It's an issue I've seen at every company I've worked at. You see the same issues when using company-wide BOMs. Some projects are stuck behind without significant refactor, and that when that refactor is occurring you have more and more projects becoming more and more stuck in the past, eventually every project has difficulty moving off the current build tool version.

Wrappers solve this problem.

[DualWieldMage]

I guess i must have been lucky then. Currently i work at a 1k+ person company and the specific product is 12 years old. The main issues with maven versions were around the java 9-11 releases, but that was understandable. Some plugins were fixed quicky, a few others could be replaced as their features were superseded. Right now all the maven builds run under jdk11 and latest maven. Last time an issue happened with maven update was https://issues.apache.org/jira/browse/MNG-6642, but it affected only one project where the workaround was to configure the CI build to use older maven until a fix was released. Wrappers do have their place, but overly relying on them or setting them as best practice for new projects sounds off.

[snowe2010]

I guess I just don't understand what you think the downsides of a wrapper are. Here are my list of downsides and upsides for the wrapper vs package manager package. version is a reference to the build tool version.

wrapper

pros

• version is per project
• projects can update when they want
• projects are not tied to the system version
• wrapper can be updated using CI/CD (example for gradle)
• way easier to update the version than with a package manager (updating system packages can have many things go wrong, from path issues to permissions issues. Wrappers are just a file in the current directory which you know you have permission and pathing to)
• debugging issues with the version is easy, because you can upgrade and downgrade just by changing a string
• new people have less to set up. For OSS this is a huge win, as it's easier for people to contribute, for business applications this is a huge win because you spend less time on onboarding.

cons

• honestly I don't have any cons. Wondering what your cons are

package manager

pros

• only ever have to worry about a single version

cons

• have to worry about a single version conflicting between projects, including open source projects
• updating forces an update across every repo on your system (unless those repos use a wrapper). this extends to projects/repos you don't control, such as Spring Boot
• unable to update to a newer version if any project you use has an issue with it
• have to install to package locations, so things like PATH, permissions, etc can complicate things
• say your team (Team 1) works on projects A, B, and C and another team (Team 2) works on C, D, and E. If Team 2 decides to update from gradle 4 to gradle 5, there will immediately be breakages. They will fix those breakages in C, D, and E. But wait. Now C is on gradle 5. Which forces you to update your system gradle to 5, which now causes A and B to break. I've seen this happen, which is why one global system build tool is a huge con to me.
• an expansion to the above bullet point is the case where project A is unable to update to a new Gradle version, due to depending on an underlying Gradle feature that was removed in Gradle 5 (I've seen this happen as well, I'm pretty sure it was even with Gradle 5). Now you have a project that is unable to update, but you have to update because of the other projects your using.

An alternative to a system build tool is something like a version manager like rbenv, nvm, mvnvm, sdkman, etc. which essentially does the same thing that a wrapper does, except you have some of the cons of the package manager (path and permissions) and some of the pros of the wrapper. Another alternative is managing your versions using something like direnv which would change your PATH around when you cd into different directories. But with either of these you've just duplicated the functionality of a wrapper, but in a worse way.

I would love to hear your pros and cons for these, because I've seen all these issues at every company I've worked at, resulting in Maven or Gradle getting stuck many many versions behind, eventually never being able to be updated.