Не скомпилируется. Нужен statement.

А вот такую вещь вы знали? В Java есть ещё одна форма комментариев:

this_is_for_loop:
for (int i = 0; i < 10; i++) {
    print_variable_i:
    System.out.println(i);
}

Я тоже заметил, что можно исполнять файл с несколькими публичными классами. Но так и не понял, зачем это нужно. Если файл один, то всё и так находится в одном пакете, и public/не-public уже не имеет значения.

Хороший вопрос для рассылки OpenJDK :)

Потому что тогда бы пришлось делать toUpperCase для первой буквы имени поля, но toUpperCase зависит от локали: youtu.be/qurG_J81_Cs?t=1625

Боюсь, что найдутся извращенцы, которые начнут навешивать аннотации Ломбока на записи…

Предлагаю для следующей статьи делать ставки, под каким номером будет коммент про то, что Java становится похожей на Kotlin.

Первый раз слышу, чтобы Eclipse позволял перезагружать плагины без перезагрузки. Любая установка плагинов / обновление Eclipse показывает окно с просьбой перезагрузки.

Ещё вспомнил: переменные в try-with-resources тоже неявно final.

В случае плагина в отдельном jar все равно все так и будет

Почему? ClassLoader в джаве грузит классы лениво, в момент первого обращения к ним. В джарке могут быть сотни классов и далеко не все из них понадобятся. Например, пользователь вообще не будет трогать те или иные кнопки, и тогда получается, что вы зря грузили все эти лишние классы.

Ещё раз: 100% надёжного решения нет. Даже в случае Томката.

Выгрузить класс может только сборщик мусора, если класс станет недостижимым. Это значит, что не должно быть ни одной цепочки сильных ссылок от GC roots до любого объекта этого класса + не должно быть цепочек ссылок на сам этот класс. Но даже если вы всё это проконтролируете, то всё равно не сможете положиться на немедленную выгрузку классов, так как сборщик мусора собирает мусор непредсказуемо. Это значит, что какое-то время эти классы будут висеть в metaspace и занимать место.
Загружать новые версии плагинов можно, и я даже встречал людей, которые утверждали, что это делают, но я считаю, что геморрой от этого превышает пользу.
(Это всё моё личное мнение)

Не совсем понимаю, как URLClassLoader поможет вам найти нужные реализации сервисов. Загрузчик классов может только загружать классы и всё. Будете грузить вообще все классы, которые есть, а потом через reflection искать нужные? У вас приложение будет стартовать по 10 минут.

а для lookup-а сервисов — ServiceLoader.

Вот только вам придётся для этого прописывать все свои реализации сервисов в `META-INF/services/`. Это большой геморрой, особенно когда точек расширений у вас очень много. Спасибо, но это слишком неудобно. Использовать module-info.java гораздо проще и надёжнее.

Идея classpath проще и универсальней.

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

Используется, и ни в каких-нибудь, а в Спринге! А как вы думаете там работают всякие автофигурации, когда вам достаточно просто навесить аннотации на типы, а Спринг сам просканирует classpath и найдёт их? Как вы это предлагаете делать без парсинга байткода? Если у вас нет XML-конфигурации, то список классов заранее неизвестен, и Спрингу придётся пропарсить классы, чтобы понять, какие именно нужны.

Eclipse != OSGi. Мы много чего используем готового из Eclipse, чему просто не существует альтернатив. А OSGi — лишь крошечный кусочек.

Хорошее обсуждение, которое полностью основано на личных мнениях людей. «Я предпочитаю», «Я думаю» и всё в таком духе. Совершенно правильно, что вопрос закрыли.

Я не убегаю от Eclipse никуда, с чего вы это вообще взяли?