Prologue Link to heading
I recently came across micronaut one of the many java micro-frameworks that gain a lot of interest lately. This particular framework was being installed locally using a tool that I haven’t come accross before: sdkman.
This will be a really short post about sdkman.
What is sdkman? Link to heading
Even if you only use a computer for playing games, sooner or later you are going to have to manage multiple versions of the same piece of software. Now, if you are into development then its possible that you’ve either have a handcrafted solution or using one provided by the operating system.
Handcrafted Link to heading
Be it the jdk itself, maven or even my IDE, I used to throw everything under ~/tools as versioned directories (e.g. maven-2.2.9, maven-3.3.5 etc) and then use symbolic links so that I have a fixed name (e.g. maven) linked to a versioned folder (maven -> maven-3.3.5). My PATH only included the link and not the versioned folder, so switching versions was just a matter of pointing the link to a different version.
Of course, this is one of the many ways to do things and is only described here to emphasize on the importance of tools like sdkman.
Operating system tools Link to heading
The last couple of years I’ve been mostly using linux and most of the distributions I’ve used included some sort of tooling for maintaining multiple versions of popular packages. Currently, I am on archlinux and for managing multiple versions of java is using `archlinux-java` as described: https://wiki.archlinux.org/index.php/Java. Other distributions have similar tools.
This is definitely an improvement compared to the manual approach described above, but don’t expect to find support for more exotic stuff.
My understanding on sdkman is that its aiming to fill that gap for all `sdks`.
Installation Link to heading
The installation process is straight forward and its just a simple command:
| |
and then for initialization:
| |
This will modify the bash/zsh rc files, so that it adds an export to the SDKMAN_DIR and also add the sdkman initialization. While this is no biggie, as a lot of tools now days tend to modify your rc files, I am not really fond of this approach.
To verify the installation:
| |
Using sdkman Link to heading
To use sdkman you just need to use the `sdk` function. As I was curious to see what sdks are supported, the first thing I tried was the list operation:
| |
This generated a long list, with things like:
- ant
- maven
- gradle
- sbt
- spring boot
- micronaut
- java
- visualvm
and more…
Installing an sdk Link to heading
I will use sdkman to install kotlin in my environment
| |
Installing a specific version of an sdk Link to heading
This installed version 1.2.71. But what if I wanted to install an older version? Say `1.2.70`?
| |
The older version got installed, but I was also prompted to select which one will be the default one.
This is really neat. I can verify that the version was successfully installed using the kotling binary:
| |
Changing the default version of an sdk Link to heading
Not if I wanted to switch again to the latest version:
| |
if no version is explicitly specified sdkman will set as default the latest stable. That’s an other nifty feature.
Broadcast messages Link to heading
One other thing that I liked is that some of the sdk commands, do display a broadcast message, that informs the user of new version available etc. Really useful!
Closing thoughts Link to heading
sdkman is not a tool that will change the world, but it does a simple job and does it really well. I’d like to see more sdks supported and of course not just java based ones. Personally, I am even tempted to use it for the java itself, given that nowdays the releases are so often that its hard to keep up!