TL; DR：SDKMAN CLI将用Golang重写自我们发布第一个版本的SDKMAN以来已经过去了六年。 在早期版本中，它被称为GVM，用于管理Groovy和相关工具。 很快变得很明显，它不仅限于Groovy生态系统，还可以应用于其他JVM SDK。 此时，GVM已重命名为SDKMAN。 尽管名称已更改，但核心技术保持不变。
就像GVM一度超过其名称一样，SDKMAN也超过了其构建的技术。 尽管后端服务已被更好的替代方案所取代，但CLI客户端仍然保持不变，并已成为我们最大的失望之源。
首先，我们选择Bash来创建GVM，因为它满足了所有要求。 它在所有* nix系统上都可用，它运行迅速，并为我们提供了一个运行时环境，而没有任何其他依赖性或开销。 这意味着在几乎所有系统上，下载新安装几乎都不费力。
尽管Bash给了我们很多好处，但随着时间的流逝，我们发现此选择存在许多问题：
- Windows用户必须通过安装Cygwin / Git Bash跳过障碍
- 我们的软件无法始终与其他外壳（例如鱼壳）配合使用
- 必须支持特殊的技巧才能与ZSH兼容
- Bash的主要版本之间不兼容（以及由于愚蠢的许可问题，Apple顽固地拒绝将OSX与现代版本的Bash一起交付）
- 使用curl作为主要的HTTP客户端导致网络问题
- 有效的Bash代码测试有困难
所有这些告诉我们现在该退出Bash了，转而支持其他方式，因此最近几个月，我开始研究Go作为可行的替代方案。 在权衡了几率之后，可以将Go上CLI实施的优点总结如下：
- 静态类型的编译语言，以在开发过程中检测错误
- 快得惊人
- 不再沉迷于脚下摇晃的土壤重击
- 为所有架构创建本地编译的二进制文件，从而消除了与平台无关的意外副作用
- 通过Godog更轻松地支持验收测试（用Go编写的Cucumber版本）
- 使您可以重新考虑当前SDKMAN实现的某些行为（稍后将对此进行详细介绍）
- 增强协作和社区投入
- 简单，让我们来做这个该死的工作（完成该死）
了解了所有这些之后，我决定构建新的
SDKMAN CLI界面的
第一个工作版本 。 完成这项工作后，新版本将成为SDKMAN的标准版本。 当然，这也将使我们能够重新考虑其当前的功能。 六年后，我们了解到它起作用并且不起作用，并且可以在我们出色的新版本中将这些知识记入脑中。
在这里，我们鼓励我们的社区加入并成为交流的一部分。 我们想知道您想要（或不想）看到哪些功能。 为此，我们在
Gitter中开设了一个新房间。 我们通过提供有关新CLI的反馈来邀请您加入和参与。 我们仍然使用Cucumber以与Bash版本相同的方式以一种可理解的语言描述行为，并且我们要求每个人都参与每个功能的实现。 和以前一样，我们希望
这些功能组成实时文档。
这就是为什么我这样称呼这篇文章。 我们喜欢开发SDKMAN的原始版本，但我们意识到它有问题。 现在，我们有机会提高它的可靠性，并为每个人改进它。 我们将很高兴为新CLI的实施提供任何帮助！
通过翻译：SDKMAN是我最喜欢的软件包管理器之一，它开始在新计算机上安装JVM，Gradle和Kotlin。 因此，最近，我们在CUBA Platform上开始在SDKMAN中发布CUBA CLI实用程序。 我进行此翻译是因为我很高兴看到SDKMAN的发展，并期待其新版本。