Можно ли быстро сделать и запустить single-file прототип на Java?
Как старый джавист я всегда немного с завистью смотрел видео, где человек на Python, PHP, Ruby пишет скрипт, содержащий достаточно сложный код и просто запускает его командой python script.py.
Не сказать, что Java ничего не делает в эту сторону:
1) JShell - позволяет просто запускать Java код без метода main построчно. Работает начиная с Java 9
2) JEP 330: Launch Single-File Source-Code Programs - не надо отдельно вызывать javac. Запуск программы работает через java HelloWorld.java. Работает с Java 11
3) JEP 477 Implicitly Declared Classes and Instance Main Methods - все тоже самое, но теперь не нужно объявлять класс (он создается неявно) и декларация метода main сильно упрощена. В режиме preview с Java 21
Но все это работает с простыми приложениями. А если нужны зависимости? Наш любимый Spring, например, с pom bom и кучей библиотек + Lombok. Да еще в нескольких файлах. Да еще хотелось бы не указывать параметры сборки в командной строке каждый раз, и не плодить лишних shell скриптов.
Когда-то подобная фича была в Spring Boot Cli - да, в Spring Boot и своя консоль. Но фичу выпилили, на мой взгляд зря. И из полезного в Cli остался по сути только аналог Spring Initialzr.
Но я отвлекся)
Кто ищет, тот всегда найдет - встречаем https://www.jbang.dev/documentation/guide/latest/index.html
Как это работает - хорошо проиллюстрировано по ссылке выше.
Я проверил на комбинации Spring Boot + Lombok все работает. Настройки из лежащего рядом application.properties подтягиваются. Единственный момент - были проблемы, если код разнесен по нескольким файлам - не обнаруживалась аннотация @Scheduled. Т.е. реализация multiple source file немного хромает, о чем разработчики предупреждают https://www.jbang.dev/documentation/guide/latest/organizing.html
Зато - все зависимости выкачиваются, код компилируется перед запуском, параметры компиляция настраиваются в файле с исходниками. Если надо - даже выкачивается Java. Принимает на вход java исходники, kotlin, упомянутый выше код для jshell, код внутри markdown (!!!) и можно даже так: jbang --code System.out.println("Hello World!")
Рекомендую к использованию!
#java #prototyping
Как старый джавист я всегда немного с завистью смотрел видео, где человек на Python, PHP, Ruby пишет скрипт, содержащий достаточно сложный код и просто запускает его командой python script.py.
Не сказать, что Java ничего не делает в эту сторону:
1) JShell - позволяет просто запускать Java код без метода main построчно. Работает начиная с Java 9
2) JEP 330: Launch Single-File Source-Code Programs - не надо отдельно вызывать javac. Запуск программы работает через java HelloWorld.java. Работает с Java 11
3) JEP 477 Implicitly Declared Classes and Instance Main Methods - все тоже самое, но теперь не нужно объявлять класс (он создается неявно) и декларация метода main сильно упрощена. В режиме preview с Java 21
Но все это работает с простыми приложениями. А если нужны зависимости? Наш любимый Spring, например, с pom bom и кучей библиотек + Lombok. Да еще в нескольких файлах. Да еще хотелось бы не указывать параметры сборки в командной строке каждый раз, и не плодить лишних shell скриптов.
Когда-то подобная фича была в Spring Boot Cli - да, в Spring Boot и своя консоль. Но фичу выпилили, на мой взгляд зря. И из полезного в Cli остался по сути только аналог Spring Initialzr.
Но я отвлекся)
Кто ищет, тот всегда найдет - встречаем https://www.jbang.dev/documentation/guide/latest/index.html
Как это работает - хорошо проиллюстрировано по ссылке выше.
Я проверил на комбинации Spring Boot + Lombok все работает. Настройки из лежащего рядом application.properties подтягиваются. Единственный момент - были проблемы, если код разнесен по нескольким файлам - не обнаруживалась аннотация @Scheduled. Т.е. реализация multiple source file немного хромает, о чем разработчики предупреждают https://www.jbang.dev/documentation/guide/latest/organizing.html
Зато - все зависимости выкачиваются, код компилируется перед запуском, параметры компиляция настраиваются в файле с исходниками. Если надо - даже выкачивается Java. Принимает на вход java исходники, kotlin, упомянутый выше код для jshell, код внутри markdown (!!!) и можно даже так: jbang --code System.out.println("Hello World!")
Рекомендую к использованию!
#java #prototyping
PHP становится Java-ой?
Недавно посмотрел видео о перспективах PHP https://vkvideo.ru/video-224967259_456239053 Я на PHP писал мало, но т.к. он широко распространён - интересно, развивается ли он и как именно. Он развивается, и я этому не удивлён. Да, есть распространённое негативное мнение про PHP и его разработчиков. Любой простой язык привлекает непрофессионалов. Но ситуация сложнее, чем кажется, на это намекает официальный code style языка https://php-psr.ru/accepted/PSR-12-extended-coding-style-guide/ Обязательность строк разделителей, фиксированное число пробелов, регистр символов - все серьёзно. Небольшое отступление - к аббревиатуре PSR из статьи выше мы ещё вернёмся.
Так вот, PHP становится похожим на Java.
Чтобы понять как именно - стоит вспомнить, чем он характеризовался изначально?
1) динамическая типизация. От неё уходят, с костылями в виде объявления типов в комментариях и проверке статическим анализатором типа checkstyle. Причина - невозможно работать со сложным проектом и динамической типизацией. Если ты конечно не хочешь "гов..кодить".
2) интерпретация вместо компиляции. Тоже уходят, есть AOT и JIT компиляторы PHP. Также фреймворки, например, IoC контейнеры, могут предварительно сохранять конфигурацию на диске. По соображениям производительности
Да, в PHP тоже есть IoC контейнеры.
3) малоизвестный факт - исходно в PHP была т.наз умирающая модель процессов. После обработки запроса клиента контекст процесса полностью очищается. Такой true stateless. Причём очищались не просто клиентские данные, а все бины IoC контейнера, т.е. вообще все. Побочные эффекты такого подхода противоположные. Положительный: PHP компоненты инициализируются очень быстро, по другому никак. Отрицательный: на утечки памяти можно забить, т.е. "гов...кодим") Так вот, от этой модели тоже уходят. Снова по соображениям производительности
В общем язык развивается, т.к. наследие огромное.
P.S. Чтобы не было пренебрежительного отношения к PHP - поговорим про стандартизацию. В PHP есть такое понятие, как middleware. Вот его неплохое описание https://laravel.com/docs/12.x/middleware
Ключевой момент - компоненты middleware переиспользуются в различных фреймворках. Как это получается? Потому что многое стандартизируется, с помощью PSR. В Java тоже есть стандарты - JPA, JDBC, http сервлеты и фильтры, но видится, что их меньше. Когда-то этим занимался проект Java EE, не смог, умер и воскрес, а за это время возникло несколько экосистем - Spring, Quarkus, Micronaut... И это я Kotlin не беру) Почему я назвал их экосистемами - каждая старается привязать к своим компонентам. Так что как ни странно - PHP выглядит более стандартизированным)
#java #PHP #lang
Недавно посмотрел видео о перспективах PHP https://vkvideo.ru/video-224967259_456239053 Я на PHP писал мало, но т.к. он широко распространён - интересно, развивается ли он и как именно. Он развивается, и я этому не удивлён. Да, есть распространённое негативное мнение про PHP и его разработчиков. Любой простой язык привлекает непрофессионалов. Но ситуация сложнее, чем кажется, на это намекает официальный code style языка https://php-psr.ru/accepted/PSR-12-extended-coding-style-guide/ Обязательность строк разделителей, фиксированное число пробелов, регистр символов - все серьёзно. Небольшое отступление - к аббревиатуре PSR из статьи выше мы ещё вернёмся.
Так вот, PHP становится похожим на Java.
Чтобы понять как именно - стоит вспомнить, чем он характеризовался изначально?
1) динамическая типизация. От неё уходят, с костылями в виде объявления типов в комментариях и проверке статическим анализатором типа checkstyle. Причина - невозможно работать со сложным проектом и динамической типизацией. Если ты конечно не хочешь "гов..кодить".
2) интерпретация вместо компиляции. Тоже уходят, есть AOT и JIT компиляторы PHP. Также фреймворки, например, IoC контейнеры, могут предварительно сохранять конфигурацию на диске. По соображениям производительности
Да, в PHP тоже есть IoC контейнеры.
3) малоизвестный факт - исходно в PHP была т.наз умирающая модель процессов. После обработки запроса клиента контекст процесса полностью очищается. Такой true stateless. Причём очищались не просто клиентские данные, а все бины IoC контейнера, т.е. вообще все. Побочные эффекты такого подхода противоположные. Положительный: PHP компоненты инициализируются очень быстро, по другому никак. Отрицательный: на утечки памяти можно забить, т.е. "гов...кодим") Так вот, от этой модели тоже уходят. Снова по соображениям производительности
В общем язык развивается, т.к. наследие огромное.
P.S. Чтобы не было пренебрежительного отношения к PHP - поговорим про стандартизацию. В PHP есть такое понятие, как middleware. Вот его неплохое описание https://laravel.com/docs/12.x/middleware
Ключевой момент - компоненты middleware переиспользуются в различных фреймворках. Как это получается? Потому что многое стандартизируется, с помощью PSR. В Java тоже есть стандарты - JPA, JDBC, http сервлеты и фильтры, но видится, что их меньше. Когда-то этим занимался проект Java EE, не смог, умер и воскрес, а за это время возникло несколько экосистем - Spring, Quarkus, Micronaut... И это я Kotlin не беру) Почему я назвал их экосистемами - каждая старается привязать к своим компонентам. Так что как ни странно - PHP выглядит более стандартизированным)
#java #PHP #lang
VK Видео
Какое будущее ждет PHP? / Валентин Удальцов / #14
В этом выпуске мы вместе с Валентином Удальцовым, автором канала Пых в Telegram, обсуждаем PHP (тот самый язык программирования, про который говорят, что он умирает, а на нём 80% сайтов до сих пор написано). Поговорим про весь путь его развития — от старых…