Анонс Oracle Java Verified Portfolio

«Бесплатно», это же не обязательно «свободно».

Ну и было бы хорошо перечислить, что там за инструменты.

Ну и было бы хорошо перечислить, что там за инструменты.

JavaFX, расширение для VS Code и фреймворк Helidon. В общем, нужность крайне сомнительна.

Я скептически отношусь к подобным инициативам. Слишком разросся и потому фрагментировался рынок разработки на Java, чтобы в нём двигать унификацию по всем версиям JDK. У разрабов уже есть портфолио на определённых комбинациях компонент, работающих в проде десятилетиями, надроченные до автоматизма навыки выяснения несовместимости одного с другим и постепенного апгрейда зависимостей. Да даже супер-пупер писк моды в ИИ, Claude не осиливает собрать хелловорлд на jdk11 и каком-нибудь spring boot, банально запутывается в установке нужной версии gradle.

А кому нужно модно и молодёжно, не оглядываясь на легаси и суровый энтерпрайз, просто возьмут Kotlin или Scala, и соотв. другие фреймворки, написанные в идиоматическом для языка стиле.

Ах да, и этим разрабам с портфолио до лампочки все эти облака Оракула.

А можно эти десятилетия не тратить на выяснение несовместимостей, а просто взять готовое, и к тому же с поддержкой.

Это «готовое с поддержкой» выльется в какой-то жёсткий вендорлокинг на ораклянских облаках. А все критические компоненты опытные Джава-разрабы и так уже берут «готовое и с поддержкой».

Есть два варианта, самому колупаться 10 лет с версиями jvm и библиотек и стать «опытным» или можно взять готовое решение и оптимизировать рабочие процессы.

Нет, таких вариантов нет. Потому что «самому колупаться» уже надо было 10 лет назад, когда никаких инициатив от корп либо не было, либо они были бесполезны на практике.

я верно понял что громко-анонсированный «Java Verified Portofolio» это JavaFX (вяло пишем унылые UI) и ещё два зонда: плагин VSCode и коннектор ко всяким ИИ ??

свою инициативу Java Verified Portfolio

Чё т я так и не понял что это и почему оно ненужно.

Барахло!

Прошло меньше 5 дней с момента анонса, надеюсь, что репозитарий будет расти.

и коннектор ко всяким ИИ

всё-таки и сам Helidon, реализация Jakarta MicroProfile

Ни Helidon, ни оракловое расширение для vscode не являются сколько-нибудь популярными. Поэтому данную инициативу можно рассматривать лишь как вялую попытку пиара своих не слишком взлетевших технологий.

инновационных Java-приложений

Наконец-то, уже заждались! Со встроенным AI, я надеюсь?

А говорят, ИТ развивается бешеными темпами — но люди буквально до сих пор программируют на джаве. Можете ли вы представить ситуацию, чтобы во времена появления джавы пользовались инструментами тридцатилетней давности?

Так не на Java 1.1 программируют же.

А что-то прямо принципиально изменилось?

Люблю я это слово «принципиально».

Много чего изменилось. А принципиально или не принципиально это вопрос субъективный. Для кого-то и за последние 2000 лет ничего принципиально не изменилось.

Ну давай сравним первую джаву сначала с современной джавой, а потом, допустим с FORTRAN IV. Необязательно даже принимать во внимание то, как выглядел физически сам процесс программирования.

Unix :)

Ну и сравни, и представь своё сравнение, не пустопорожние бредни, человека, который на java не программировал, а вот качественное сравнение, которое бы доказывало твою мысль. А мы тёмные почитаем. Не? Ну тогда не удивляйтесь приставке «лютый болтун».

JavaFX

Разве Oracle не забил на это всё и не отдал JavaFX Gluon'у?..

Разве Oracle не забил

Как видишь, решили откопать стюардессу

JavaFX

Эта штука, мне кажется, нужная.
Но я всегда считал, что она и так опенсорсная.

Я тут свой pet-project думаю пока делать на Swing: из плюсов JavaFX - это есть библиотека для автотестов (под Swing вроде всё уже давно не поддерживается: а альтернативы для штуки, типа FEST вроде нет) и оно поддерживается, пусть и через 3rd party, компанию Gluon. Минусы: контролы выглядят довольно громоздко, оно не совсем кроссплатформенное из-за WebView и кодеков (мой проект это скорее бы не коснулось, но идеологически как-то неправильно. Как в свое время было с SWT).

Буквально месяц назад Клауд написал мне с нуля java springboot приложение.

Время идёт, ИИ взрослею. Причем развитие ИИ идёт не быстро, а очень быстро. Два месяца назад писал чушь. Через месяц вышла новая версия, которая может.

Но это офтопик, сорян.

Я уже написал, как ИИшка справляется с написанием спринг Бут приложений. Это не ИИшка месячной давности. Возможно, на каких-то более новых версиях Бута, с вырвиглазным мавеном, ИИшка справляется лучше. Но шаг влево, шаг вправо - и ИИшке нужно помогать своим интеллектом.

Swing - целочисленный, JavaFX - плавучеточечный. Мониторы современные. Выбор очевиден.

Я скептически отношусь к подобным инициативам

здесь на самом деле есть два варианта, зачем «это» пытаются куда-то двигать:

1. есть куча энтерпрайза, который до сих пор сидит на какой-нить IBM WebSphere 6.1 и, соответственно, Java 1.5, несмотря на то что оно уже давно не поддерживается, имеет кучу дыр и пр. - просто считают, что дешевле оставить в таком виде как есть нежели обновлять. У этих энтерпрайзов денег много, но они очень «инертные» - никто не хочет обновляться устраивать сессию раз в полгода/год, а вот горизонт планирования лет так в 10-15 - самое оно. Никакой опенсорс 10-15 лет поддержки никак не вытянет (один тот же Spring где-то каждые 5 лет кому-то перепродают - откуда здесь хотя бы 5 лет получить?), поэтому вот этим энтерпрайзам пытаются какую-то какаху выдавить и заработать денюжку
2. менеджмент действительно надеется, что получится отжать у спринга часть рынка, а там кто-то да и подсядет на иглу купит поддержку - тогда это уже клиника, спринг начал свое победоносное шествие на фоне того, что в комитетах импотенты заседали и ничего толком определить не могли, а сейчас на борьбу со спрингом опять комитет собрали… вот реально, это та самая пресловутая перестановка кроватей в борделе

Нет там никакого комитета. Спринг родился, как борьба с тяжеловесным J2EE но в итоге выродился в такую же тяжеловесную оверинжиниренную кучу кода, что самое забавное - поддерживающую кучку ныне уже Jakarta EE стандартов. Конечно до уровня вебсферы, стартующуей 15 минут, он не дорос, но сегодня многие люди хотят, чтобы веб-сервер запускался за доли секунды. И Helidon это предлагает.

Хотя лично мне Helidon уже кажется переусложнёным и оверинжиниренным. Я на него одно время возлагал некоторые надежды, но сейчас расстроился. Хотя в любом случае это глоток свежего воздуха после спринга.

вебсферы, стартующуей 15 минут

Как романтично... ;P ;))

Я такое сотворить не умею и никогда не умел... аж завидно... :D :)))

Нет там никакого комитета

ну а кто тогда все эти (довольно странные) спецификации пишет и еще какие-то референсные реализации создает? Если раньше житуи принадлежал ораклу, то теперь им управляют более другие мутные типы, но в итоге ничего толком не меняется, например: JPQL replace() function

сегодня многие люди хотят, чтобы веб-сервер запускался за доли секунды. И Helidon это предлагает

как бы это не означало, что эти «многие люди» решают XY problem: «у нас приложение часто падает, давайте сделаем, чтобы оно хотя бы быстро запускалось»

в итоге выродился в такую же тяжеловесную оверинжиниренную кучу кода

нужно же понимать откуда ноги растут изначально… вот если идти по примерам этого Helidon (PokemonResource):

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    @Transactional(Transactional.TxType.REQUIRED)
    public Response create(Pokemon pokemon) {
        try {
            em.persist(pokemon);
            return Response.status(201).build();
        } catch (Exception e) {
            throw new BadRequestException("Unable to create pokemon: " + pokemon.getName());
        }
    }

то невооруженным взглядом можно заметить, что и демаркация транзакций неправильная, и структура БД торчит кишками наружу без возможности что-то гибко менять и хоть как-то защищаться, не говоря уже о каких-то более высокоуровневых материях. Но зато у нас футпринт маленький и перезапускается в случае падения быстро, складывается ощущение, что «фреймворк для написания микросервисов» - это своего рода индульгенция для разработчиков: раз микросервисы, то можно писать откровенную дичь.

ну а кто тогда все эти (довольно странные) спецификации пишет и еще какие-то референсные реализации создает?

Так а к хелидону какое отношение эти спецификации имеют?

как бы это не означало, что эти «многие люди» решают XY problem: «у нас приложение часто падает, давайте сделаем, чтобы оно хотя бы быстро запускалось»

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

нужно же понимать откуда ноги растут изначально… вот если идти по примерам этого Helidon (PokemonResource):

Хз, что это, я про helidon se если что. Там совсем другой код.