SDKMAN - Dead, Long Live SDKMAN

TL; DR: SDKMAN CLI will be rewritten to Golang

Six years have passed since we released the first version of SDKMAN. In earlier versions, it was known as GVM and was used to manage Groovy and its associated tools. It soon became apparent that it should not be limited to the Groovy ecosystem, and could also be applied to other SDKs on the JVM. At this point, the GVM was renamed SDKMAN. Although the name has changed, the basic technology remains the same.

Just as GVM once outgrown its name, SDKMAN outgrew the technology on which it was built. Although the backend services were replaced by better alternatives, the client's CLI remained the same and became our biggest source of frustration.

In the beginning, we chose Bash to create a GVM, because it covered all the requirements. It was available on all * nix systems, worked quickly and provided us with a runtime environment without any additional dependencies or overhead. This meant that downloading a new installation practically didn’t require efforts on almost any system.

Despite the advantages that Bash gave us, over time we discovered many problems with this choice:

• Windows users should jump over hoops while installing Cygwin / Git Bash
• our software does not always work well with alternative shells such as the fish shell
• need to support special hacks for compatibility with ZSH
• incompatibility between major versions of Bash (and Apple’s stubborn refusal to ship OSX with the current version of Bash because of stupid licensing issues)
• network issues due to using curl as the main http client
• Difficulties with Effective Bash Code Testing

All this tells us that it’s time to throw Bash in favor of something else, so in recent months I began to study Go as a viable alternative. After weighing the odds, the benefits of implementing CLI on Go can be summarized as follows:

• statically typed compiled language to detect errors during development
• performed incredibly fast
• no more dependence on shaky soil bash under your feet
• creates compiled binaries for all architectures, eliminating unexpected platform-related side effects
• easier support of acceptance testing via Godog (version of Cucumber, written in Go)
• allows you to rethink some behavior of the current implementation of SDKMAN (more on this later)
• allows you to improve collaboration and increase the contribution of community members
• simple and lets us just do the damn job (Get Shit Done)

Understanding all this, I decided to build the first working version of the new CLI interface SDKMAN . After this work is completed, the new version will become the standard version of SDKMAN. Of course, this will also allow us to review how it is currently functioning. Six years later we learned what works and does not work, and we can bring this knowledge to mind in our brilliant new version.

Here we encourage our community to join and become part of the conversation. We want to know which features you would like to see (or would not want to). To do this, we are opening a new room in Gitter.. We invite you to join and participate by giving feedback to the new CLI. We still use Cucumber to describe behavior in an understandable language just like in the Bash version, and ask everyone to take part in the implementation of each function. As before, we want these functions to make up live documentation.

That is why I called this post so. We liked to develop the original version of SDKMAN, but we realized that there were problems in it. Now we have the opportunity to make it more reliable and improve it for everyone. We will be glad to any help on the way to implementing the new CLI!

From the translator: SDKMAN is one of my favorite package managers, it starts installing JVM, Gradle and Kotlin on a new machine. That is why, most recently, in the CUBA Platform, we started publishing our CUBA CLI utility in SDKMAN . I made this translation because I am pleased to see the development of SDKMAN and I look forward to its new version.