Говоря о профессиональном программировании на Java нельзя не отметить, что усредненные сценарии применения несколько отличаются от ранее рассмотренных баз данных и PHP. Разработка будь то бекэнда или мобильных приложений на Java или под JVM всё-таки связана с промышленными и крупными проектами, для которых важна стабильность, быстродействие, кроссплатформеность и прочие плюшки получаемые в комплекте. Не пишут лендинги или отчеты на Java в заметных количествах - на Java, как правило, написаны серьезные системы под руководством крупных компаний не имеющих острого дефицита в финансовых ресурсах. В экосистеме Java cложилась ситуация даже, с некоторой точки зрения, обратная PHP, у которой средства разработки в основном коммерческие, а продукты малопригодные к тиражированию и нужные только владельцам некоторого основного бизнеса. В мире же Java недостатка в бесплатном и довольно качественном инструментарии как будто и нет, но для профессиональных разработчиков нет проблем с тем что бы и приобрести замечательные коммерческие продукты производства JetBrains или специализированные инструменты типа PWS Studio.
Поэтому сценариев когда во что бы то ни стало надо использовать бесплатные инструменты мало. С предложением разработать какой-нибудь продукт на платформе Java скорее всего выйдет какой-нибудь крупный заказчик у которого не возникнет вопросов с предоставлением вам рабочего места или каких-то лицензионных продуктов. Либо вам предложат такую сумму, которая будет подразумевать сопутствующие расходы. Вряд ли, если вы опытный Java разработчик, у вас есть проблемы с личным оборудованием, которое не потянет последнюю редакцию IntelliJ Idea или Eclipse JDT. Но, да, это если вы действительно опытный специалист.
Поэтому первый сценарий по которому могут пригодится бесплатные инструменты - это если вы новичок и только набираетесь опыта. И возможно у вас из оборудования только ноутбук пятилетней давности, который под весом Eclipse просто сломается пополам. Есть еще многострадальный Netbeans, но, во-первых, он не намного легче, во-вторых - ну, он местами действительно странный - это надо признать. Есть вариант с Idea Community Edition - вот он прямо для новичка - ни больше ни меньше. Но тут возникает проблема с подсаживанием. После Idea, какой бы она урезанной не была, пересаживаться обратно на какой-нибудь Netbeans будет, мягко говоря, неприятно. А впервые лично покупать Ultimate надо уже с приличным портфолио и с гарантией занятости.
Есть и второй сценарий. Сразу отказаться от перспективы стать жертвой маркетологов из JetBrains и набить руку на бесплатных IDE. А какая самая хорошая бесплатная IDE, которая не требует геймерской сборки компьютера? Правильно - VSCode.
Нет, я в самом деле не оговорился. VSCode прекрасен почти по всем статьям. Но, раз лично я, а может и кто-то из вас, выбрал для построения универсальной IDE Vim, то и научить Vim понимать Java не будет лишним. Опять же, лично я пока скорее всего запущу на большом проекте Netbeans или Idea, но вот раз пошла такая пьянка, то почему бы не покодить и в Vim.
Eclipse
Огромный вклад, помимо разумеется родительской Oracle, в экосистему Java вносит Eclipse Foundation. Продукты и инструменты от Eclipse открыты и распространяются бесплатно под лицензией EDT - что-то близкое к Apache License. В отличии от, не к столу будет упомянуто, JDeveloper, который пока тоже бесплатный, но закрытый. И который поэтому, вполне вероятно, завтра станет каким-нибудь ограниченным по модели JetBrains.
Примечательно, что наравне с IBM, Oracle, RedHat и прочими функционерами отрасли в фонде принимает участие и Microsoft. Причем играя там отнюдь не последнюю роль. А именно адаптируя инструменты, в том числе и под VSCode. Собственно разбираемый JDT Language Server был разработан при непосредственном участии Microsoft именно под него. А соответственно благодаря протоколу LSP от всё той же Microsoft стал доступен широкой общественности в лице разработчиков других редакторов кода.
Необходимо отметить, что Eclipse JDT LS не единственный Language Server для Java в природе. Существует еще как минимум две работоспособные реализации. От некоего Джорджа Фрейзера с соответствующим плагином для Vim и внутренний движок Apache Netbeans, к которому нет рабочих плагинов кроме как к VSCode. Первый вряд ли чем-то выгодно отличается от продукта Eclipse, во всяком случае, судя по количеству контрибюторов и времени обновления, он не самый свежий, а качество движка Apache мы примерно знаем. Поэтому выбор в данном случае сделать было легко. Тем более движок Eclipse хорошо поддержан через Vim Conqueror of Completion и NeoVim.
Сам JDT LS устанавливается в систему тривиально путем скачивания Java приложения и созданием ссылки или указания пути к сценарию bin/jdtls. Запуск требует минимум JDK 11. Так же можно собрать сервер из исходников при помощи Maven. Плагины используют непосредственно jar файлы для общения с сервером, но можно и напрямую воспользоваться bin/jdtls и для этого вам понадобится еще и (зачем-то) Python3.
coc-java
Вообще предыдущее действие можно опустить, потому что конкретно расширение coc-java само таскает сервер нужной версии с собой. Что в принципе тоже вариант, учитывая то что весит JDT LS немного - что-то порядка 50 МБ. То есть для установки рабочего окружения и начала работы с Java в Vim примерно так же как и в IDE Eclipse достаточно набрать из самого Vim:
:CocInstall coc-javaВ отличии от предыдущих манипуляций с SQL клиентом и PHP LS вы тут же получаете рабочий Java редактор со всеми фичами перечисленными для JDT. В том числе работу с Maven и Gradle, Javadoc, с аннотациями, диагностику от компилятора, форматирование. Но как и с PHP LS для того что бы конфигурацию смело называть полноценной IDE не хватает нескольких штрихов.
JDWP + vimspector + coc-java-debug
Главное что приходит в голову это пошаговый дебаггер или инспекция. Прикрутить такой функционал к Vim кажется на первый взгляд сложно, но происходит на самом деле всё довольно гладко и опять же без какого-то явного рукоприкладства. Во-первых, сам дебаггер встроен в рантайм JVM и как и почти всё в мире Java стандартизирован и называется Java Debug Wire Protocol. Фактически вам достаточно запустить java с определенными ключами. В примере приложенном в репозитории такая команда может выглядеть так:
$ cd src/java/hello-maven
$ javac -g src/main/java/ru/notdotnet/provim/App.java
$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=5005,suspend=y -cp src/main/java ru.notdotnet.provim.App Или, например, раз уж это проект Maven, тоже самое для запуска тестов при помощи плагина:
$ cd src/java/hello-maven
$ mvn test -Dmaven.surefire.debugОсталось подключиться к нему из Vim.
Существует ряд универсальных плагинов, которые реализуют возможности Debug Adapter Protocol (DAP) и красиво отображают всё стандартное хозяйство. Мне приглянулся vimspector который в числе прочего подходит как для JDT LS так и для Xdebug для PHP. Установка стандартная - добавляем плагин в ~/.vim/plugins.vim
" DAP manager
Plug 'puremourning/vimspector'Так же надо сказать плагину, что бы применил сочетания клавиш. Есть два варианта: 'VISUAL_STUDIO' и 'HUMAN'. Я поставил последнее.
let g:vimspector_enable_mappings = 'HUMAN'Важно поставить эту инструкцию в общей конфигурации, так переменная должна быть объявлена до фактической загрузки плагинов. Теперь вам доступны стандартные операции установки точек останова, пошагового выполнения и всего прочего. Но нужно еще прокинуть мостик до JDWP.
Для этого нужно установить еще одно расширение coc-java-debug, которое помимо команды установки :CocInstall coc-java-debug потребует таки немного дополнительных манипуляций.
Нужно объяснить инспектору куда, собственно, подключаться. Для этого в корне проекта нужно создать файл .vimspector.json со следующим содержимым:
{
"adapters": {
"java-debug-server": {
"name": "vscode-java",
"port": "${AdapterPort}"
}
},
"configurations": {
"Java Attach": {
"default": true,
"adapter": "java-debug-server",
"configuration": {
"request": "attach",
"host": "127.0.0.1",
"port": "5005"
},
"breakpoints": {
"exception": {
"caught": "N",
"uncaught": "N"
}
}
}
}
}
Ну и последним штрихом нужно объяснить Vim как это всё хозяйство запускать.
nmap <leader><F1> :CocCommand java.debug.vimspector.start<CR>Теперь достаточно поставить брейкпойнт (<F9>) и запустить (<leader><F1>) отладку введя номер порта на котором ожидает приложение запущенное ранее.
По итогу
Что бы еще пригодилось в повседневной работе? Какие-то генераторы чего-то, линтеры, более высокоуровневая интеграция с фреймворками, но это уже детали и скорее всего есть способы всё это как-то приделать. Например, можно прямо в coc-settings.json добавить следующие строки для интеграции с Lombok.
{
// codelens
"codeLens.enable": true,
"java.referencesCodeLens.enabled": true,
"java.jdt.ls.vmargs": "-javaagent:/opt/lombok/lombok.jar",
// "java.jdt.ls.vmargs": "-javaagent:/opt/lombok/lombok.jar -Xbootclasspath/a:/opt/lombok/lombok.jar", // for older versions of Java
}
В целом же 90% работы можно выполнять и на данном этапе достаточно эффективно как профессионалу, которому надо очень быстро передвигаться по коду и между файлами, так и новичку, который всё еще остро нуждается в подсказках о наличии тех или иных классов и методов. А запускается всё это хозяйство за считанные секунды. При этом просматривать и редактировать файл можно прямо сходу, пока в фоне поднимается сервер, ну а потом работает точно с такой же производительностью как и в самом Eclipse.
Есть причины полагать, что с какого-то момента преимущества Vim как текстового редактора начнут складываться на чашу весов не в пользу тяжелых графических IDE. И пусть в Vim всё еще нельзя будет отрендерить UML диаграмму или мышкой раскидать окна инспектора, скажем откровенно, что это и не те задачи которые надо делать ежедневно.
В следующий раз попробую прикрутить таки Xdebug к Vimspector и тогда останется наконец перетащить всё это в хозяйство на Lua и плагины свойственные NeoVim.
