Компания Amazon опубликовала (https://aws.amazon.com/blogs/opensource/amazon-corretto-8-ge.../) первый готовый к промышленному применению релиз проекта Corretto 8 (https://aws.amazon.com/corretto/), рамках которого на основе OpenJDK подготовлен дистрибутив Java 8 (https://www.opennet.ru/opennews/art.shtml?num=39334). Продукт распространяется бесплатно и доступен (https://github.com/corretto/corretto-8) в исходных текстах под лицензией GPLv2. Готовые сборки поставляются (https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/do...) для Linux (Amazon Linux 2, Debian/Ubuntu, RHEL/CentOS), Windows и macOS, и сформированы для архитектур aarch64 и x86_64. Дополнительно подготовлен готовый образ для использования в контейнерах Docker (https://hub.docker.com/_/amazoncorretto).
Ключевой целью проекта является продолжение сопровождение ветки Java 8 после прекращения (https://www.oracle.com/technetwork/java/javase/tech/eol-1357...) компанией Oracle публичного выпуска обновлений для Oracle JDK 8 (начиная с января 2019 компания Oracle публикует обновления для Java 8 только в рамках расширенной платной поддержки по подписке). Компания Amazon намерена поддерживать Java 8 в виде дистрибутива Corretto 8 как минимум до июня 2023 года.Кодовая база Corretto 8 синхронизирована с JDK Open8u202. Предлагаемый Amazon расширенный цикл поддержи включает формирование ежеквартальных обновлений, в состав которых будут включаться (https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/ch...) оптимизации производительности и исправления, связанные с безопасностью. В выпуски Corretto также планируется выборочно бэкпортировать некоторые новшества из новых релизов, а также включать улучшения, развиваемые сообществом OpenJDK. На протяжении всего времени существования ветки Corretto 8 доступ к обновлениям будет предоставляться бесплатно и без каких-либо ограничений.
Проект Corretto стал продолжением развития дистрибутива Java, уже используемого во внутренней инфраструктуре Amazon для обеспечения работы тысяч рабочих сервисов. Продукт сертифицирован как соответствующий спецификациям Java SE, при внесении изменений проверяется при помощи TCK (Technology Compatibility Kit) и может быть использован для замены других дистрибутивов Java SE. В феврале или марте компания Amazon намерена сформировать ещё одну LTS-ветку - Corretto 11, основанную на OpenJDK 11. Поддержка Corretto 11 будет осуществляться до августа 2024 года.
URL: https://aws.amazon.com/blogs/opensource/amazon-corretto-8-ge.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=50071
> используемого во внутренней инфраструктуре Amazon для обеспечения работы тысяч рабочих сервисовСамый правильный вариант для ЯП нового поколения: сами пользуемся, не против чтобы пользовались другие. А всякие Rust, собранные непонятно для кого и изменяемые непонятно для чего, это не вариант.
А в каком месте он нового поколения?
Может автор из 90х пишет
Крупные компании опенсорсят не из-за доброты душевной, а потому что на большей выборке ошибки быстрее находятся, и на грабли наступает кто-то другой за тебя.
Какая разница если в итоге выигрывают все?
Языки придумывались, потому что типовые задачи решались быстрее на новых языках. Или на новом уровне.
А сейчас придумываются потому что могут придумать, хотя практической пользы в этом мало. Тот же велосипед, вид сбоку. Существенно ничего не меняется.
Жаба так появился и своё время был не нужен трушным поклонникам одного системного языка.
А мне кажется, что жабу делали для того, чтоб толпы индусов могли хоть как-то, но _предсказуемо_ чё-то пилить. То есть это не для разработки язык, а для управления таковой в условиях околоплинтусной квалификации исполнителей.Это не отменяет единиц специалистов, необходимых на такие проекты и в любом разе вырастающих самостоятельно, но скорее оттеняет их.
PS: как амазон вот оттенил оракль, ага.
Если тебе что-то кажется, не стоит выносить это на всеобщее обозрение. Лучше обсудить это со специалистом.
Вот это было очень грубо и не в тему. Чистое хейтерство, наглое и нескрываемое.
Михаил, как-то уж очень поверхностно. Хотя, в общем, так оно и есть. Ява экосистема (языком это уже давно не назвать) сугубо прикладная, к чему тут вышеплинтусовый уровень? И, да, так уж сложилось, что пишут, на любом языке, сейчас "толпы индусов", но не только пишут, а и руководят разработкой тоже. Квалификация которых не высока (иногда ужасающе... не высока). Но, понимаете, норму определяют не единицы, а масса.
> норму определяют не единицы, а масса.Вот тут ты дал маху)
> А мне кажется, что жабу делали для того, чтоб толпы индусов могли хоть как-то, но _предсказуемо_ чё-то пилить.Sun не знала, зачем она создавала Java. Их идея была сделать кроссплатформенный язык, чтобы write once, run everywhere, или типа того у них слоган был. Но реальность оказалась не столь радужной, и Java довольно долго выгрызала себе нишу, она выгрызала себе много ниш, но успешной оказалась только в злой корпоративщине, где текучка кадров, длинные сроки поддержки, постоянно меняющиеся ТЗ, и прочие гнусности. Из остальных ниш её выперли, в конечном итоге.
Э. А как же Андроид? Который сейчас больше половины общемирового пользовательского джанк-софта. В корпоративщине Ява выигрывает за счёт богатейшего и давно вылизанного инструментария и высочайшего уровня стандартизации всего и вся. Ну и потому, что... альтернативы просто нет.
> Э. А как же Андроид? Который сейчас больше половины общемирового пользовательского джанк-софта.
> В корпоративщине Ява выигрывает за счёт богатейшего и давно вылизанного инструментария
> и высочайшего уровня стандартизации всего и вся. Ну и потому, что...
> альтернативы просто нет.А, да, простите, забыл про андроид.
Слава высшим силам, что под Андроид можно писать на чём угодно, не только на Java :)
>Из остальных ниш её выперли, в конечном итоге.Фантасты попеннета... приходи через 30 лет с такими заявлениями, пока что жаба везде.
Ну уж слишком толсто! Явный перебор! Скорее нигде, чем везде!
Так она и не создавала яву. SUN купила лицензию на Оберон. И с него все содрали.
Делали вряд ли для этого, но в итоге получилось именно так.
А вот, кстати, Apple-овский Swift явно проектировался именно с такими целями. :-)
ява изначально была попыткой создать нынешнее ардуино
разрабатывалась для микроконтроллеров и подобного
мне совершенно понятны жалобы создателей явы на врох дефайнов которые надо было раньше вводить в разные микроконтроллеры и учитывать их мелкие различия - это не платформа РС - где все стандартно
как пример - разница между Intel 8051 и Intel 8052 всего в размере памяти и одлном таймере - но куча производителей еще и свои кристаллы на базе этих ядер делала
так что там ява была уместна
ну то что она там не пошла а вдруг ее всунули в аплеты а потом в общее программирование - так то нормально в мире ИТ
если бы строители строили дома как программисты пишут программы - вся цивилизация рухнула бы от первого залетевшего дятла (с)
Кроме Си и Ассемблера для микроконтроллеров больше ничего не прижилось (отдельные откровенно слабенькие попытки применить что-то ещё, как правило, не от большого ума, ибо ресурсы микроконтроллера не те)
Гундяю чаще молись, если кажется. Тебе расисту("толпы индусов", "околоплинтусное что-то там")и до тех индусов как до Киева раком.
С индусами много работал и работаю. Редкостные прохвосты и... расисты. Но у них это, видимо, результат жесточайшей конкуренции.
Поддержу, пожалуй.
Поработал с индусами очень не мало.
- Практически нулевая ответственность
- Насколько бы детально не было б написано тз, в любом случае, оно будет понято не так, а неудобные моменты (тонкости, ограничения, учёт пограничных условий) будут просто пропущены/забыты. Доходило до идиотизма — тз вычитывалось и исправлялось сначала командой бизнес-аналитики (британцы), а потом допроверялось и упрощалось тех.писателями (американцы). После финального согласования с тех.диром, тз уходило аутсорсерам в Индию
- Если ты взял такого исполнителя за яйцо, будь готов к неожиданным сюжетным поворотам (виноват будет не наш копчёный друг, а ты)
- несмотря на утвержденный ранее стэк, вместо простой функции на scala/java/JS, ты мог получить всё, что угодно, начиная с заглушки и заканчивая матрёшкой из 10 функций, самая нижняя из которых вызывает aws-cli с грепом в цикле
- После пятого конфликта (когда CTO сказал «пока не сделают, денег не платить»), генеральный, таки начал сомневаться в частности консалтеров, которые рассказали ему насколько индийский аутсорц лучше своей команды разработки
- дальше было проще: кумарам выдали общие требования (переписать на ноду/скалу/java/питон, увеличить стабильность и предсказуемость); выдали код существующей системы (пыха, работает со времён выпуска 5.6); попросили просчитать деньги/время.
- в ответ пришло, что им нужно два месяца и 30к зелени (что явно дешевле скалистов в штатах, но на уровне европ); но в письме было ГЛАВНОЕ ТРЕБОВАНИЕ (похоже с той стороны поняли, что жирная рыба срывается) — аванс 100%; письмо показали CTO и CEO; последний сказал чтобы согласовывали аванс в 25% или пойдут лесом; с той стороны согласились
- через два месяца мы получили письмо с zip в аттаче (20 мб); мы его распаковали; внутри было 18 версий одного и того же питоонячьего virtualenv; ни инструкций к запуску, ни комментов не было; по упоминаниям zope в коде поняли что это зопный проект; запустили; чаще оно падало чем работало; апи был несовместим; код выглядел как доработанная руками попытка переписать регулярками пыху в питон
- CTO в очередной раз выматерился и пошёл объяснять CEO, что если он хочет и дальше работать с этими экстравагантными парнями, то ему придётся делать это самостоятельно
- при этом, в головном офисе, в команде разработки, есть 2 разраба из Индии — милейшие ребята, очень ответственные разработчики (и геи); они были одни из первых, кто был против найма аутсорца с их родиныВыводы предлагаю сделать самостоятельно.
Знания о создании ЯП стали общедоступными ("девальвации знаний"). Поэтому появилась новая возможность упростить решение проблемы: вместо написания кода написать ЯП, на котором написать код. Иногда это приводит к долгосрочным последствиям (см. напр. историю создания php), но обычно ограничивается рамками одной задачи.Там, где ты видишь проблему, я вижу возможности.
Все уже придумали до вас. Ходим кругами.Есть функциональный подход, если императивный подход. По сути как с состоянием языки работают. Ну и с памятью, конечно. Безопасно или нет.
LISP, Haskell
FORTRAN, C, C++, Swift, RustИ помеси:
Clojure, Java, JavaScript с примесями концепций.Давайте, жгите правду матку как я неправ.
На деле бывает так.
Придумывается язык X. Выбирается как работать с памятью будем? Безопасно или нет. Язык какой подход исповедует? Императивный (так дурачкам проще и школьники осилят). Профит.
Получили - Swift, Rust, Java, Python и т.п.
> Все уже придумали до вас. Ходим кругами.
> Есть функциональный подход, если императивный подход. По сути как с состоянием языки
> работают. Ну и с памятью, конечно. Безопасно или нет.Вы забыли про декларативный подход. И вообще говоря, есть куча мелких ньюансов при решении разных _реальных_ задач - потому так много языков программирования и появилось. Ибо эти "мелкие ньюансы" могут влиять очень так нехило.
Жаба в прошло хипстота, стал легаси велосипедом который уже и бросить жалка и появился новый велосипед от Амазон.
А разве в OpenJDK не исправляются уязвимости? Какие отличия от OpenJDK? В том, что Amazon рискует своим добрым именем?
Срок поддержки Амазон предлагает существенно больший.
>Срок поддержки Амазон предлагает существенно больший.В CENTOS6 и CENTOS7 жаба8 есть. Подозреваю, что и в CENTOS8 будет не только 11.
Итого, на самом деле неясно нафига?
Ну ведь есть не только центос.
Да и амазон обещает производительность поднимать, а у центос только патчи безопамности.
Производительность и Java - это вещи прямо противоположные! Если требуется производительность на Java, то пишите код, требующий производительности на C++, в котором делайте вставки на Ассемблере :) А на фиг тогда Жаба? :)
>Если требуется производительность на Java, то пишите код, требующий производительности на C++попеннет во всей красе... весь хайлоад на жабке написан. Можно это игнорировать, мой милый страус, но реальность от этого не меняется.
>Ну ведь есть не только центос.Да, ещё RHEL есть.
>Да и амазон обещает производительность поднимать, а у центос только патчи безопамности.поднимать производительность, ничего не ломая, в заброшенной ветке. слабоумие и отвага. хотя, подозреваю, что это менеджерское бла-бла и заметного буста не будет.
В комплекте сабжа отсутствует компонент Java Web Start (в Linux аналог IcedTea). Какие идеи?
Потому этот web start жуткая давно бесполезная хрень.
Если применяется корпоративное приложение на данной технологии (включая наработанные терабайты баз данных), и приложение вполне справляется с задачей, выбирать не приходится, а требуется поддерживать приложение.
Да, я даже знаю о каком вы приложении. Так вот, JAWS, как его основу, давно, ещё лет десять назад, надо было менять. JAWS всегда было жутким убожеством, а уж сейчас это даже хуже, чем держаться за какой-нибудь борланд паскаль или фокспро.
Достаточно сделать standalone-запускалку приложения, с терабайтами ничего не случится.
Сделайте мне такую для ip-kvm-ов lantronix. Желательно, для заброшенных, но работающих ещё в полях spider.
И на что предлагаете заменить, например, в имеющихся KVM'ах (где через .ws-файл в момент открытия KVM передается информация о хосте и временный ключ сессии?)В смысле, я понимаю что на некоторых новых материнках уже есть KVM на базе HTML5. Но имеющихся, где на базе Java как бы тоже полно.
На привычные уже лет десять JAX-RS и JavaScript.
А зачем подобному "обновления безопасности"? Они, ведь, и так -- дуршлак. И раньше с этим как-то уживались.
Отдельные VLAN или даже стомегабитку, если всё равно больше незачем и остался надёжный хлам тех лет, и соответственно отдельный узел доступа с JRE _и браузером_ тех лет.
О, это старье обычно и заводится нормально только на JRE 6 (или даже 5), который никто не мешает держать под рукой параллельно с новой (или в контейнере).Запустить можно ручками с консоли, вот так:
http://javatechniques.com/blog/launching-java-webstart-from-.../Насчет секьюрити-апдейтов я бы сильно не беспокоился - эти IP-KVM сами по себе одна большая дыра, в любом случае требуется изоляция.
> О, это старье обычно и заводится нормально только на JRE 6 (или
> даже 5), который никто не мешает держать под рукой параллельно с
> новой (или в контейнере).Часто заводится и на более новом JRE (7 и 8), но обычно требуют строго оракловую. На openjdk некоторые KVM'ы не хотят работать в упор - не могут разобрать .ws-файл и все :) (т.к. пишут туда кривой xml, а реализация разбора xml по умолчанию в openjdk другая, чем была в оракловой джаве и по-другому разбирает при наличии ошибок). Встречал такое на KVM'ах, где начинка была от AMI MegaRAC - они многим OEM'ам поставляли, в частности материнки, где графика от ASPEED идет "Aster GUI" на базе MegaRAC.
А еще видел смешные примеры (это уже по-моему на супермикрах, далеко не старых), где с openjdk консоль открывается, но отсутствует полоска меню... видимо какой-то экспешен внутри происходит и этот кусок не рендерится, а остальное работает. А с оракловой - меню на месте!
> Запустить можно ручками с консоли, вот так:
> http://javatechniques.com/blog/launching-java-webstart-from-.../Спасибо, любопытно.
> Насчет секьюрити-апдейтов я бы сильно не беспокоился - эти IP-KVM сами по
> себе одна большая дыра, в любом случае требуется изоляция.Так то дыра на KVM, а то дырявая джава на моей машине! Есть разница. Там-то понятно, что изоляция. Хочется на системе, откуда туда ходим иметь джаву не дырявую и не разводить огромный зоопарк этих джав.
Удвою, пожалуй.Есть у меня гроздь ip-kvm от lantronix раскиданных по всей необъятной. В интернет не смотрят — видят только тоннель до vpn сервера. Их консоль работает либо как аплет, либо как java web start. Через опенждк оно со скрипом запускается, но заваливает исключениями и падает. На ораклячьей ждк — в ус не дует. Работает, кстати, и на java8.
С Википедии:
В Java 9 технологию WebStart объявили устаревшей и убрали в версии Java 11.
XP не поддерживается, слабаки!!!
Попробуйте эту версию https://adoptopenjdk.net/releases.html
И эту https://www.bell-sw.com/
Хорошая новость, чё. А то Оракл погнал новые версии плодить. Совершенно ни к чему.
Раньше сан писала спецификации JCR. Язык развивала по необходимости.
А оракл больше похоже язык пилит
JCP или JSR. Одно процесс, другое -- процедура. Ничего не поменялось. Другое дело, что Спринг вылез. Он несколько сместил на себя центр тяжести. Но обычно что-то стоящее из него потом пролезает и в стандарт.
Но Java 8 не нужен. Как и Java 11. GraalVM вполне юзабелен и готов для продакшна. Не готовы только дополнительные языки.
Вообще-то, если кто не в курсе, есть Intel x86 VM и AMD x86 VM, т.е. аппаратные интерпретаторы двоичных инструкций x86, но для получения нативного байткода есть Ассемблер, но если хочется писать побыстрее и чтобы всё было более или менее гламурно, то есть православный С++, компиляторы которого поддерживают Ассемблерные вставки :) Все остальные программные VM работают поверх x86 VM. Поэтому про реальную производительность можете забыть, и никакие LLVM вам в этом не помогут особенно для языков с динамической типизацией!
Дебки с Явой? Мне не привиделось? Отличное решение для тех, у кого устаревший дистрибутив с Java 1.6 или 1.7! Например Debian 7 Wheezy
и это тоже.
Корыто - хорошое название
Неучь безграмотная, "правильный" по-итальянски.