Java 17 LTS

В книге по котлин так на каждой странице и писали «Котлин гараздо круче чем java 6» :) Только уже в момент выхода 8 джавы котлиновские потуги были бесполезны, они там напридумывали то, что в джаве есть например asSequence и прочее подобное. Мало того, книжка учит, что надо использовать терминальные операции вместо…хотя пофиг. В общем да, котлин боролся с давно устаревшей джавой версии 6.

Согласен

Так оно уже не поддерживается толком.

говнокод

это отсюда экзампл, и как бы он не претендует.

мне интересно прост, будет работать compile-time проверка в type switch или нет.

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

По if-ам не будет. Так будет:

    public static double getPerimeter(Shape shape) {
        return switch(shape) {
            case Rectangle r -> 2 * r.length() + 2 * r.width();
            case Circle c -> 2 * c.radius() * Math.PI;
        };
    }

Ещё раз: с теми же настройками был успешно произведен апдейт с Eclipse 2019 на 2021-06.

Сегодня целый день проверял - 2021-09 нет

Да скачай ты уже Eclipse руками, сколько можно ныть?

По if-ам не будет. Так будет:

looks good )

еще вариант - облегчить рефакторинг enterprise quality кода, правда шансы, что крупный проект переедет на 17лтс, ничтожны.

Сейчас на 11 жаве уже больше приложений, чем на 8. С 11 до 17 мигрировать относительно несложно. На 8 тоже вряд ли многие будут сидеть очень долго. Так что я бы про ничтожные шансы не зарекался.

Дело не в сложности, а в самом факте необходимости переезда. Это ж проект, бюджет, ресурсы. А дедлайны как обычно вчера.

Проблема Котлина и других язычков на базе JVM в том, что Жабу все-равно нужно знать. От нее никак не избавиться, на ней написаны почти все библиотеки и фреймворки и выходит что вместо одного языка, тебе приходится знать оба.

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

Это не проблема, котлин это надмножество над Java, если человек осилил Kotlin или Scala то по наитию сможет понять код на java не изучая его. А вот с clojure конечно будут проблемы, кодерам привыкшим к процедурное-алгоритмическим языкам тяжело понять функциональный язык да еще на s-expression, но и LISP кодерам тоже тяжело понять java, даже автор clojure не осилил ООП, правда это было 10 лет назад когда он в этом прямо заявил на претензии по поводу его кода на java. За 10 лет он наверное проникся.

Уважаемый эксперт по архитектуре ыглыбза - вам двойка.

Нужно для каждого нового релиза изменять update site url.

Он у них version specific.

Зы. А когда они завезут для немецких раскладок клавиатур поддержку «Toggle Comment» через хоткей?

Я за 20 лет не вижу прогресса в этой очень важной части написания кода.

Котлин позволяет создать свой DSL, т.е. писать код проблемно ориентированный, это не всегда нужно, но когда нужно это просто кил фича. На Java такой код читается плохо, пишется тоже очень плохо и ide не помогает писать код из-за обилия «import static», достаточно рассмотреть JOOQ или Mockito. А «import static» делается чтоб код сделать хоть немного компактнее и легче для восприятия.

Java хороший язык, он задуман быть ограничивающим, ты не можешь переопределить операторы, обращение к методам не может быть записано каким-либо иным способом, лямбда захватывает текущий контекст и не может принести свой, поэтому код на java всегда читается однозначно, его намного проще как ревьювить без ide человеку, так и проще написать статический анализатор.

Я думаю использование Kotlin/Scala в больших командах может превратиться в ад, с другой стороны над приложениями для andorid по моим представлениям обычно трудятся 1-2 кодера. Небольшим командам легко выработать общий стиль, для двух человек даже не проблема читать код друг-друга, даже если они будут писать по разному.

Я для своих проектов использую Kotlin, но у меня есть некоторые опасения попасть в команду пишущую на kotlin и тем более я бы не хотел попасть в бодишоп (в укоренившимся понимании этого слова), в такой агломерации уровень кодеров очень разный и ревьювить твой код там будут совершенно разные люди.

Каким образом это проблема? Все эти котлины сделаны в первую очередь для джавистов. Ну и джава язык несложный.

Уважаемый эксперт по архитектуре ыглыбза - вам двойка.

Нужно для каждого нового релиза изменять update site url.

Он у них version specific.

Тебе двойка за игнорирование мной сказанного выше о конфигурации обновлений.

Зы. А когда они завезут для немецких раскладок клавиатур поддержку «Toggle Comment» через хоткей?

Я за 20 лет не вижу прогресса в этой очень важной части написания кода.

Спроси их сам.

Тут 3/4 форума за С топят, а ты про устаревание на рынке труда…

«Кажется смешным, но люди берут». Наверное так комфортнее, иметь rhel 6 и древнюю Яву за бешеные бабки… С другой стороны, если работает, а от апгрейда банк крякнется, будет дороже.

И это мы ещё Кобол не обсуждали…

Спроси их сам

Вот мы и попались. Я теперь точно знаю, что ты не живешь в Германии. Немецкие Eclipse Java кодеры используют с 2004го года комбинацию Strg+7

Ну ты прямо Шерлок Холмс. Хотя нет, скорее доктор Ватсон, потому что слишком долго думал.

В долгоиграющем сервисе у тебя жабий сборщик мусора положит весь сервис, если вовремя такой сервис не перезапускать

А долгоиграющий - это сколько? У меня за последние 190 дней аптайма ничего не легло пока что (да и то перезапускал только из-за обновления). Перед тем - было около полутора лет аптайма.

В долгоиграющем сервисе у тебя жабий сборщик мусора положит весь сервис, если вовремя такой сервис не перезапускать

Во времена монолитов все было нормально, по мере работы приложения уровень потребления памяти стабилизировался и не рос. GC показывал обычную «пилу» на графиках потребления. Утечка могла быть разве только от кривого использования ThreadLocal или HashMap. А так все работало месяцами до нового релиза.

Но вот перезапустить отдельно веб сервис без перезапуска того же Tomcat было чревато, утекал permgen space. Но это конечно мелкая неприятность, просто нужно было знать что не все фичи одинаково полезны.

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

Ватсон без трубки уже не мог

Ватсон без трубки уже не мог

Так вот почему у тебя так долго не получалось.

OK, следующая версия Java 18 будет называться Visual Oracle Cobol With Objects 18

Grand Oracle With Natural Objects — сокращение доставляет!

Я как-то запускал гуй на жабе, это было больно.

На python Gui-и намного тормознее.

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

Вряд ли переписывание коболовского кода на код другого языка вообще в принципе обсуждаемо, учитывая количество кода на коболе и его важность.

гм. у мну полно случаев с работающим оборудованием, хотящим 1.7 и (местами) даже 1.6 типичный пример - Brocade 300 и VNX.

=D

Ахаха! Это 5!

ничего не скажет для англоязычного. Вот Super Hyper Intelligent java Translator - это да!

В принципе, да.

Но, даже, если и не подписали: почему ты до сих пор задаешь вопросы уровня школоло? Eclipse RCP/SWT выстрелил в тырпрайсе в те времена, когда свинг какаля и писался в подгузники. Именно RCP/SWT и захавал весь корпоративный сегмент.

java использует подход - дай пионерам в других языках набить шишек и внедряет только действительно полезные фичи - это позволяет ей иметь хорошую обратную совместимость до версии 1.0 (привет пистону и шарашке), а также всегда быть stable и up2date.

Так ведь в джаве есть класс Properties со времен 1.0.2 В чем проблема?

Человек хочет вместо полей класса атрибуты класса (aka properties в терминологии c#), т.е. это как поля класса хранящие состояние объекта но такие же нормальные члены класса как методы: переопределяемые, с поздним связыванием и возможностью перехватывать обращения к ним посредством динамических прокси. Если бы было так то ненужно было бы генерировать set/get методы в бинах. Но Java создавалась давно и видно для скорости сделали как в c++, а из-за обратной совместимость переиграть не могут.

https://openjdk.java.net/jeps/409 сосиска вон для тебя даже специально ссылки на всю эту мишуру понавставлял, там на первом же развороте есть цели этого дела и пример когда это вдруг может понадобиться, не ленись )

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

Короче, что то же надо релизить из года в год, почему бы не это?

Как будто у них без этого работы нет. Коллекции например починить.

зачем ограничивать расширение существующего кода

Например в Scala это делают, чтобы гарантированно проверить все типы в паттерн-матчинге. Здесь скорее всего, за тем же.

их все устраивает, и новые языки типа котлина даже закладываются на эти коллекции в том виде что они есть, никто не будет ломать обратную совместимость просто так.

Я понимаю, что их устраивает, в том то и проблема, что чешут там где не чешется. Ну и один раз совместимоть они уже поломали.

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