SDKMAN — мёртв, да здравствует SDKMAN

Original author: Marco Vermeulen
  • Translation

TL;DR: SDKMAN CLI будет переписан на Golang

Шесть лет прошло с тех пор как мы выпустили первую версию SDKMAN. В более ранних версиях он был известен как GVM и использовался для управления Groovy и связанным с ним инструментарием. Вскоре стало очевидно, что он не должен ограничиваться экосистемой Groovy, и может также применяться к другим SDK на JVM. В этот момент GVM был переименован в SDKMAN. Хотя название и изменилось, основная технология осталась прежней.

Подобно тому, как GVM однажды перерос своё имя, SDKMAN перерос технологию, на которой он был построен. Несмотря на то, что сервисы бэкенда были заменены лучшими альтернативами, CLI клиент остался прежним и стал нашим самым большим источником разочарования.

В начале мы выбрали Bash для создания GVM, потому что он закрывал все требования. Он был доступен на всех *nix системах, быстро работал и предоставлял нам среду исполнения без каких-либо дополнительных зависимостей или накладных расходов. Это означало, что загрузка новой установки практически не требовала усилий почти на любой системе.

Несмотря на преимущества, которые нам дал Bash, со временем мы обнаружили множество проблем с этим выбором:

  • пользователи Windows должны прыгать через обручи, устанавливая Cygwin / Git Bash
  • наше программное обеспечение не всегда хорошо работает с альтернативными оболочками, такими как Fish shell
  • необходимо поддерживать специальные хаки для совместимости с ZSH
  • несовместимость между основными версиями Bash (и упорный отказ Apple от поставки OSX с современной версией Bash из-за глупых вопросов лицензирования)
  • проблемы с сетью из-за использования curl в качестве основного http-клиента
  • сложности с эффективным тестированием кода на Bash

Все это говорит нам, что пора бросить Bash в пользу чего-то еще, поэтому в последние месяцы я начал изучать Go как жизнеспособную альтернативу. После взвешивания шансов, плюсы реализации CLI на Go можно суммировать следующим образом:

  • статически типизированный компилируемый язык, позволяющий обнаруживать ошибки во время разработки
  • исполняется невероятно быстро
  • больше нет зависимости от зыбкой почвы Bash под ногами
  • создает изначально скомпилированные двоичные файлы для всех архитектур, устраняя неожиданные связанные с платформой побочные эффекты
  • более легкая поддержка приемочного тестирования через Godog (версия Cucumber, написанная в Go)
  • позволяет переосмыслить некоторое поведение текущей реализации SDKMAN (подробнее об этом позже)
  • позволяет улучшить сотрудничество и увеличить вклад членов сообщества
  • прост и позволяет нам просто сделать эту чертову работу (Get Shit Done)

Понимая всё это, я решил построить первую рабочую версию нового CLI-интерфейса SDKMAN. После завершения этой работы новая версия станет стандартной версией SDKMAN. Конечно, это также позволит нам пересмотреть то, как он функционирует в настоящее время. Через шесть лет мы узнали, что работает и не работает, и можем довести эти знания до ума в нашей блестящей новой версии.

Здесь мы призываем наше сообщество присоединиться и стать частью общения. Мы хотим знать, какие функции вы хотели бы видеть (или не хотели бы). Для этого мы открываем новую комнату в Gitter. Мы приглашаем вас присоединиться и принять участие, давая обратную связь на новый CLI. Мы все еще используем Cucumber для описания поведения в понятном для понимания языке так же, как и в случае с версией Bash, и просим всех принять участие в реализации каждой функции. Как и прежде, мы хотим, чтобы эти функции составляли живую документацию.

Именно поэтому я назвал этот пост так. Нам нравилось разрабатывать оригинальную версию SDKMAN, но мы поняли, что в ней есть проблемы. Теперь у нас есть возможность сделать его более надежным и улучшить его для всех. Мы будем рады любой помощи на пути к реализации нового CLI!

От переводчика: SDKMAN — один из самых любимых мною пакетных менеджеров, с него начинается установка JVM, Gradle и Kotlin на новой машине. Именно поэтому, совсем недавно мы в CUBA Platform начали публиковать в SDKMAN свою утилиту CUBA CLI. Я сделал этот перевод, поскольку рад видеть развитие SDKMAN и с нетерпением жду его новой версии.

Only registered users can participate in poll. Log in, please.

Как вы устанавливаете JDK?

Haulmont
244.66
Создаем современные корпоративные системы
Share post

Similar posts

Comments 16

    0

    OFF: в голосовалке не хватает пункта "иное" — пришлось воздержаться.


    А вообще молодцы — для их проекта уже давно пора было от скриптов уйти

      0
      Немного странно только, что Go. Но ничего стабильнее наверное просто не существует, Kotlin/Scala native слишком молоды, а Rust просто сложный.
        0
        Вы не поверите, для скриптов есть python) Довольно стабильный.
          +1

          и возвращаемся к проблеме как с Bash :) разные версии, необходимость что-то ставить на Windows, etc

            0
            везде есть 2.7
            ну и для скриптов отлично пишется универсальный код. там затык только с бинарными данными
              0
              везде есть 2.7

              Ах если бы это было так. Когда-то для себя выбирал на чём скриптоваться и выбрал bash

                0
                ну тогда и bash не совсем везде :)
                  0

                  Если уж и завязываться на шелл, то только на POSIX sh.

                  0
                  найдете в дефолтной windows python 2.7? А так да все чаще желаю смерти bash в пользу python
                    0
                    в bash там какой версии подефолту? :)
                      0

                      Так одна из причин ухода с bash как раз из-за того, что его в Win нет по-умолчанию.

                        0
                        я сравнивал bash vs python.
                        наличие примерно одинаковое.
                        а писать на питоне всяко удобнее.
              +1
              Наверное, потому что «стильно, модно, молодежно».
              А так ко второй версии изменять систему работу с модулями, добавят дженерики и работу с исключениями. Вот тогда Go можно посмотреть. :-)
                0
                Serverless… же

                deployment time становится фактором, на который обращают внимание.
              0
              Идея хороша, использовал SDKMAN для установки Groovy.
              Думал, так же будет с Java, но тут ждал облом: через SDKMAN ставится openjdk. Нет, спасибо. Пары проблем при работе с оупен-джавой хватило, чтобы взять за правило: не пользоваться ею, всегда ставить оракл-джаву.
              Так что, к сожалению, последний пункт: «ZIP/GZ архив» (и полчаса ада блуждания по лабиринтам www.oracle.com, чтобы найти ссылку на скачивание этого архива). Вот когда sdkman поддержит установку oracle jdk, тогда это будет киллер-фича.
                +1
                Текущая ситуация не располагает к использованию Oracle JDK. LTS спустя 6 месяцев после релиза теперь только за деньги. Более того, Oracle JDK = OpenJDK (с некоторыми патчами) для JDK 8+. Единственное важное отличие — Java FX было нивелировано тем, что Java FX больше не входит в JDK.

              Only users with full accounts can post comments. Log in, please.