Комментарии 36
Забыли написать, что раньше он был свободный для скачивания и коммерческого использования, что и позволило ему широко распространиться, но после покупки Oracle изменился подход к его лицензированию и теперь есть сложности с использованием последних версий языка, поэтому многие коммерческие продукты либо делают свои или используют чужие кастомные сборки, либо используют старые версии Java.
Помимо реализации oracle, имеющией перечисленные вами проблемы, есть полностью открытые реализации openjdk и openj9
Так я про это и говорю. Раньше была одна Java, а теперь экосистема фрагментирована.
Сможете показать пару несовместимостей между парой любых сертифицированных ванильных JDK?
Что конкретно вы подразумеваете под ограничениями "ванильное" и "сертифицированное"?
Насколько я помню, как раз ограничения на сертификационные тесты, это одна из особенностей новой лицензионной политики.
Именно это и подразумеваю. Те которые прошли TCK и сказали что изменений не вносили. Вы говорите что экосистема фрагментирована, значит эти сборки как-то отличаются. Так покажите пару различий.
Ограничение нормальное вообще. Неплохо разделяет сборки от Васяна от сборок от больших ребят.
Исходники есть, собирайте и пользуйтесь на здоровье. Это полностью законно. JDK собирается не так сложно вообще. А есть сборки от серьезных ребят которые заплатили нормально денег и прошли все тесты от Оракла. Их много бесплатных, берите любую и пользуйтесь на здоровье.
Вы реально не понимаете в чем проблема или только делаете вид, что с экосистемой Java все хорошо? Представьте, что вместо какого нибудь GCC или LLVM будет существовать два десятка разных брендированных компиляторов. Все они собраны из одни и тех же исходников и какие-то из них даже прошли тесты, но настоящие GCC или LLVM использовать нельзя, так как это не позволяет их лицензия.
Кроме Orace JDK и Open JDK существует еще куева туча сборок:
AdoptOpenJDK
Amazon Corretto
Azul Zulu
Bck2Brwsr
CACAO
Codename One
DoppioJVM
Eclipse OpenJ9
GraalVM CE
HaikuVM
HotSpot
Jamiga
JamVM
Jelatine JVM
Jikes RVM (Jikes Research Virtual Machine)
JVM.go
Liberica JDK
leJOS
Maxine
Multi-OS Engine
RopeVM
uJVM
Azul Zing JVM
CEE-J
Excelsior JET
GraalVM EE
Imsys AB
JamaicaVM (aicas)
JBlend (Aplix)
MicroJvm (IS2T – Industrial Smart Software Technology)
OJVM
PTC Perc
SAP JVM
Waratek CloudVM for Java
И это далеко не полный список и вы будете настаивать, что между ними нет никаких различий?
Так покажите эти различия. Я прошу всего парочку. Только не между любыми, а между теми которые соответствуют критериям которые я чуть выше описал. Это вроде немного. Между gcc и clang я вам легко покажу больше чем два различия.
Пока вся разница это минус два в мою карму. Этот аргумент я вижу и понимаю. Убедительно. Еще чуть-чуть и вы будете правы, а я буду молчать.
между теми которые соответствуют критериям которые я чуть выше описал
Я вас просил уточнить, что вы имеете ввиду под термином "ванильное", но ответа так и не получил. Наверно для того, чтобы у вас была возможность сказать "что я не это имел ввиду"? Я не хочу тратить время на пустую переписку. Если вы считаете, что с экосистемой Java все в порядке, ну и пусть, я не буду вас переубеждать, это ваши проблемы, тем более я на ней уже не пишу и теперь этот бардак меня не касается
Между gcc и clang я вам легко покажу больше чем два различия.
Это такой стеб или вам нравится изображать из себя недалекого человека?
Естественно gcc и clang полностью различаются.
Ванильная сборка это сборка авторы которой не написали в ридми что они внесли вот такие-то изменения. Внести изменения и по прежнему проходить TCK нетривиально, но возможно.
Вам надо просто написать или найти в интернете программу которая ведет себя по разному на разных ванильных JDK для доказательства вашего тезиса о проблемах в джава экосистеме. Судя по вашим комментариям это несложно.
На моей стороне TCK. Мой тезис: Все кто TCK походит и сознательно не ломает совместимость одинаковые и между ними нет разницы.
Переход на личности, минусы в карму. Хабр2024 стал странным.
Вам надо просто написать или найти в интернете программу которая ведет себя по разному на разных ванильных JDK для доказательства вашего тезиса о проблемах в джава экосистеме.
Мне это не нужно, это ваше желание, которое я удовлетворять не нанимался.
Изначально я озвучил тезис, что с началом эпохи коммерциализации Java, и сменой лицензии на не свободную, её экосистема стала очень фрагментирована. И в качестве доказательства этого факта привел неполный список сборок JDK. Может какие-то из них совместимы полностью, может быть нет, мне это не интересно, так как подтверждает мой тезис просто сам факт их наличия.
Как контр аргумент (и проверку на фальсифицируемость), я упомянул проекты GCC и LLVM (clang). Пока их лицензии свободные, то и нет необходимости всем и каждому собираться кастомные сборки компиляторов (хоть ванильные, хоть нет).
И да, согласен, Хабр уже давно странный.
То есть вы принесли тезис о фрагментированности, а пруфов на фрагментированнность, кроме плевков в карму и перехода на мою личность, не будет. Ну окей.
Про наличие TCK я подозреваю вы узнали от меня.
Вы уже не первый раз высказываете недовольство оппонентом в споре, требуя от него (т.е. от меня), что-то сделать для вас, что по вашему мнению, сможет вас убедить. Но почему то не хотите ни слушать, ни замечать другие аргументы, да и сами не чураетесь переходов на личности.
Я вам уже объяснил свое мнение насчет фрагментированности Java после смены лицензии. Допускаю, что может быть для вас наличие десятков разных сборок JDK подобным аргументом не являются, но это ваше мнение, которое я уважаю и не собираюсь вас в этом переубеждать.
А минус в карму за "Неконструктивное общение" я вам поставил после того, как вы начали что-то требовать, вместо того, что бы аргументировано обосновать свое мнение насчет изначально озвученных фактов и аргументов.
Обоснование приносит тот кто принёс какой-то тезис.
Откройте любую статью про джаву. Видите там упоминание на каких idk оно работает? Откройте Гитхаб любой крупной библиотеки. В том числе сложной как Спринг или насквозь пропитанной хаками как Нетти. Там видите упоминание про поддерживаемые idk? Вот, я тоже не вижу.
Вывод: тезис о фрагментированности вам надо как-то серьезно обосновывать. Не обосновывать такое можно если вас зовут Алексей, например. Тогда все сами побегут разбираться и доказывать его.
Ну вот опять. Сами придумываете аргументы, сами их пытаетесь опровергнуть.
Если библиотека частично поддерживает какой-то компилятор или платформу, это не говорит о фрагментированости платформы разработки.
Например, clang ведет себя по разному при работе под Linux и Windows. (наткнулся на особенность случайно, из-за чего пришлось использовать библиотеку libffi). Но является ли это фактом, указывающим на фрагментированность экосистемы clang или С++ в целом? Вряд ли.
Другое дело, если бы существовал бы десяток (условно) сборок clang на базе одного и того же исходного кода, причем не важно, что большинство из них будет вели бы себя одинаково.
присоединюсь к аргументам @BugM .
вам всего лишь говорят, что заявления о "фрагментированности экосистемы" - мягко говоря, несостоятельны. (наличие множества совместимых между собой альтернативных джавамашин - это никак не фрагментированность. ключевое тут - "полностью совместимых между собой")
аналогично не соответствует действительности и мнение про "закрытость языка" по лицензиям - вы путаете официальную сборку джавамашины от оракла , и сам язык java (как набор стандатов, описаний и требований к логическому механизму).
вы же, очень похоже, к сожалению, не слышите оппонента, его аргументов и не пытаетесь понять о чем он вам говорит.
Наш коллега, как мне кажется, катастрофически далёк от мира Java и занимается некоторой подменой понятий.
Если взять за точку отсчета 2010 год (Покупку Sun Microsystems компанией Oracle), то можно назвать достаточное количество имплементаций JVM.
* Azul Zing от Azul Systems - старт 2002 год. Проприетарная платная JVM со своим высокопроизводительным Garbage Collector (GC)
* JRockit от BEA Systems - старт 2002 год. Затем куплена Oracle. Проприетарная и сильно платная. Уникальный для того времени GC, который скорее всего лег в основу G1 OpenJDK и Oracle JVM. Убита Oracle в 2012
* IBM J9 от понятно кого. С ростом популярности Java и распространением энтерпрайзного софта на этой платформе IBM в 1999 году заключило соглашение с Sun и получило право форкнуть Java SE (кажется 1.3) чтобы сделать порты под AIX, z/OS с учетом специфики IBM POWER и мэнфреймов.
* SAP JVM. Не могу назвать точную дату, но первый релиз не позже Java SE 6, то есть 2004-2006 годы. Причина та же, что и у IBM. Дорогущее энтерпрайзное ПО работающее на ОСях - Windows, Solaris, HP-UX, AIX, i5/OS (IBM i) и на процах - x86, x86-64, IA-64, SPARC, PA-RISC, PowerPC (IBM POWER). SAP договаривается с Sun и делает форки под все платформы, чтобы системные интеграторы при внедрении систем не плясали с бубном.
* OpenJDK. 2007 год, случилось знаковое событие. Поняв все преимущества коллективной разработки OpenSource компания Sun Microsystems публикует исходники своей JVM под названием OpenJDK и лицензией GPL-2
Можно еще продолжить, но нет смысла. Тут и так 5 абсолютно различных имплементаций, ни в коем случае не сборок, JVM, эпохи до Oracle. И конечно Java software будет на них выполняться одинаково в соответствии с заявленной версией совместимости с TCK (наборами JSR).
Теперь можно и к сборкам перейти. Oracle не стал закрывать OpenJDK лицензиями. Более того, OpenJDK - это основная платформа OracleJDK в которую включены некоторые проприетарные элементы. Лично мне непонятен ход с лицензиями на OracleJDK, как и не понимаю, кому нужна именно сборка от Oracle, там нет киллер фич. Но прошла некоторая волна создания сборок OpenJDK другими компаниями. И в этом вообще нет никаких проблем. Та же AdoptOpenJDK (Eclipse Temurin) это сборка референсной OpenJDK и возможность получить платную поддержку. Российская LibericaJDK - сборка, но плюс ребята дописывают улучшения, не ломающие TCK и являются контрибуторами OpenJDK. Примерно такая же ситуация с Amazone Coretto.
Я работаю в компании, в которой уже много лет собираю собственные сборки OpenJDK и дописываю патчи, которые не ломают TCK, но учитывают особенности нашего продакшена в рантайме.
и занимается некоторой подменой понятий.
Это вы хорошо отметили. А ничего, что JVM (о чем вы пишите) и JDK о котором идет речь, это как бы не совсем одно и тоже?
Коллега, вы еще раз подчеркиваете то, что вы далеки от темы.
JDK - это Development Kit. Набор инструментов, который предназначен для разработки и отладки приложений на Java. И этот набор должен (TCK) гарантировать, что мнемоническая команда "swap" имея код "5f" свопнет два верхних слова на стеке. То есть javac на выходе даст всегда одинаковый байткод.
И JDK он же одинаков. Есть фундаментальная база, обложенная JSR. Если кто-то из производителей хочет "обогатить" JDK своими новыми либами - да пожалуйста. Кто-то мешает использовать в С++ boost? Никто, кроме корпоративных правил. Но наработки boost уходят в апстрим языка.
И вот тут возникает Java SE. Набор библиотек, которые работают поверх JVM. И они формируют язык и экосистему. И он стандартен. Иначе это не Java. Кто был не согласен - сделали Scala, Closure, Kotlin (огромное спасибо ребятам из JetBrains)
Вы в своем же посте путаете кучу понятий.
В вашем перечислении присутствует HotSpot. Но это не JDK, это имплементация рантайма. Как и JamaicaVM, дорогая имплементация JVM под real-time. Это не JDK, это рантаймы.
Текущие популярные сбоки Java SE
Temurin
Coretto
Liberica
Да и прочие несут в себе стандартный набор библиотек. Не отличающийся от OpenJDK. Байт-код там будет всегда одинаков. Но может быть обогащен. Никто не мешает заменять условно запрещенный sun.misc.Unsafe на новые технологии.
Вы в своем же посте путаете кучу понятий.
Хабр "прекрасен". Убить карму в комментах, где только и разрешено писать - это сильно. Причем на корректном посте, задевшем ЧСВ другого комментатора. Ну что же поделать. Мои коллеги теперь знают с кем и каким юрлицом лучше не сотрудничать.
Я не вижу смысла в третий раз отвечать на одни и те же аргументы. А так как вы даже не потрудились перечитать мою переписку выше с @BugM (в которой, кстати, мы хоть и не убедили друг друга, но как бы пришли к одному знаменателю, что каждый по своему может быть прав), но я не вижу смысла начинать туже самую переписку по новой.
А так как вы с самого начала начали мешать в одну кучу терминологию и разные понятия, то я не вижу смысла в дальнейшем обсуждении с вами этого вопроса.
Ну очень краткая история. :-(
из-за android вспомнил (по памяти:) если у ява программиста вытащить половину (оперативной) памяти то ява программы будут работать быстрее
решил глянуть (webarchive) одну популярную ява прогу (2006 ver 0.1.0 и 2010 ver 1.0) - нашёл в итоге roadmap 2005 по которому смогли всё допилить к версии 1.0 (удивляло что смогли и вроде с 0.7.6 сразу зарелизили поняв что год без проблем) и узнал что она иранская (никогда не интересовался чья) да из-за качественного исполнения для неё остальные страны собрали/напили контента и до сих пор работает хотя рессурс давно в webarchive (ушёл туда когда стало oracle хотя .org домену 20+ лет)
может в конец статьи добавить
Кик Рэдек из Microsoft считает С# более сложным языком, чем Java. По его мнению, «язык Java был построен таким образом, чтобы уберечь разработчика от стрельбы себе в ногу» (англ. «Java was built to keep a developer from shooting himself in the foot»), а «С# был построен так, чтобы дать разработчику пистолет, но оставить его на предохранителе» (англ. «C# was built to give the developer a gun but leave the safety turned on»).
Один экран текста по заявленой теме и "вода". Уж лучше статью на Википедии почитать.
Презентация Star7 ("пульт" из статьи) от Джеймса Гослинга прямиком из 1992-го.
Если углубиться в тему и отбросить ваниль, то получится сказ о том как "просрать все полимеры". Неплохая и перспективная технология благодаря бездарной политике была сначала выпилена из винды, затем снесена с десктопа, смыта с клиентского веба, практически были просраны все мобильные платформы (только Гугл на свою задницу взял джаву и сильно пожалел потом). На сервере благодаря энтерпрайзному булшиту, веб разработка практически была утрачена в угоду легковесным решениями типа ruby on rails. Все эти JSR спецификации были дорогим и факультативным процессом, и реально никому особо и не впились. Фактически все это время один Spring тащил на себе всю джаву, новый клал по большей части на весь JEE. Около 7 лет застоя языка вызвали отток девелоперов из экосистемы и создание стопицот альтернативных мертворожденных JVM языков. Сегодня джава зацепилась за клауд, но и здесь не все гладко: внезапно оказалось, что она долго стартует, что сильно мешает технологиям с динамическими инстансами, а также не позволяет быть лекговесным языком для написания утилит и скриптов, как Пайтон или JS. ML и AI опять же...
Вообщем, история джавы -- это нифига не история успеха. Скорей вопреки стараниям менеджеров, над все ещё ее использует.
На сегодняшний момент, Java это единственная популярная платформа, где запили настоящие виртуальные потоки вместо корутин. Благо, дизайн языка это позволяет.
А для скорости запуска давно есть GraalVM с предварительной компиляцией, плюс, скоро Leyden в релизе (AOT кеш в CDS).
И Java и JVM развивается. Сам Oracle набирает разработчиков.
А какой язык вам больше нравится, без озвученных недостатков Java?
Спасибо. Освежил немного в голове.
1995 релиз
2009 покупка оракл.
2023 сентября 21 версия)
Всё было не так. (С) Было всё веселее.
Жил был один инженер которому поручили разработать ПО для пульта телевизора. Писал код он на С.
Дело было новое и железо (микропроцессоры для пульта) ему приносила часто новое и разное.
И запарился он иметь зоопарк своих программ на С под разное железо для пульта. Запарился по полгода читать доки на каждый микропроцессор.
Решил он повеситься. Выбрал для этого серверную. Там хорошо, холодно. Висеть можно долго пока не найдут. Но не пустили его в серверную. И пошёл он к своему руководству с заявлением на увольнение.
Руководство его формально спросило — причина увольнения?
— Да, запарился я с вашим изменением железа, — сказал он. — Мне приходится по пол-программы каждый раз переписывать, — приврал он маленько.
В это время у руководство чего-то сидел Гослинг — который обычно ездил по универам на конференции и слушал о новинках в разработке ПО.
Гослинг сидел как все американцы — положив ноги на стол, перед директором. Директор слушал его в пол уха, ничего не понимая про некую «виртуальную машину», про которую Гослинг ему уже не раз пытался втолковать.
В то время не только все в универах то бредили ООП, но и интенсивно обсуждали виртуальные машины.
Гослинг волей не волей вынужден был присутствовать при увольнении этого программиста. Выслушав причину он немного подумал и сказал инженеру по пультам — Не увольняйся пока, я тут новую штуку придумал — пишешь один раз, выполняется во всех пультах для телевизора. …
Язык назвали «Oak» — что на жаргоне означало коньяк. (С)
Но когда дело дошло до маркетологов, те сказали, что негоже программистам пить алкоголь.
Стали выбирать: чай, молоко, пиво, вино, виски, сок, шампанское и сидр. Остановились на кофе — на жаргоне это «Java». (С)
( Кстати, когда Java уже взлетело, то программисту, разработавшему по заказу простой язык для обработки нажатий на странице в броузере, маркетологи сразу же сказали, что язык его будет называться JavaScript и надо также добавить оператор new.
Но зачем, спросил программист, — у меня же нет ООП.
Неважно, добавь, — сказали ему маркетологи. — За пару недель уложишься?
Так возник JavaScript, который к Java имеет такое же отношение, как «car» к «carnival». )
И наступил 1995 год и Java взлетел — шума было много. Почти как C, но реализация ООП проще чем у С++.
Про то, что Java был придуман как язык для написания ПО для встроенных систем типа пульта телевизора, сразу же забыли ибо наступили годы Интернета. — Что то надо было приспособить для рисования картинок в броузере. И для этого привлекли Java.
Если бы в 1995 году кто-то сказал, что Java станет (займёт место Кобола) языком для Энтерпрайз систем — его бы в дурку послали.
в статье упущены ключевые фичи языка и стратегии его поддержки, без которых язык не стал бы едва ли не единственным языком написания больших бизнес приложений, и тем явлением которое мы сегодня имеем.
собственно, отсутствие этих вещей у многочисленных "убийц джавы", и стало причиной того что все они - на обочине истории, а джава как была, ведущим языком для бизнес-приложений, так и остается.
первое: наличие четкого описания работы языка.
описания достаточного для того, что бы можно было сделать две ключевые вещи:
а) сделать полностью совместимую альтернативную реализацию компилятора
б) провести тест на совместимость различных компиляторов.
собственно это и есть вторым важным пунктом :
наличие процесса тестирования на совместимость компиляторов. как компиляторов разных версий (обеспечение обратной совместимости и неизменности работы вашего кода на новых версиях языка/компилятора, так и кроссплатформенная совместимлсть )
причем у sun, процесс тестирования был закреплён юридически и без этого нельзя было объявить ваш компилятор - джавой.
помните историю такого поделия майкрософта как J# ? и куда оно "внезапно делось"?
подскажу: юристы sun выиграли дело у мелклмягких и запретили им создавать несовместимую со стандартом версию "java" (там дальше пошла цепочка событий "откуда есть пошел c#, и нафига и кому он был нужен", но это совершенно другая истоия). причем произошло это очень быстро - буквально год или около того. издательство bhv успело даже книжек понавыпускать... а потом их "как смыло".
именно ~100% обратная совместимость (обеспеченная наличием стандарта и тестов) и статическая типизация - и сделали язык тем незаменимым и фактически безальтернативным средством для написания бизнес приложений с длительным жизненным циклом, которым java сегодня и является.
это, а не "какие то там свойства языка".
всё, собственно, потому, что у бизнеса который вкладывает деньги в большой софт на много-много лет - нет никакого желания тратить деньги на рефакторинг кода, после выхода новой версии компилятора.
с джавой процесс переезда на новую версию компилятора - максимально безболезненный (ps: если, конечно, вы "находитесь в пределах стандарта языка", не пользуете недокументированные фичи типа доступа к приватным методам через рефлекшен как было у многих с 6й джавай, или не пытаетесь заигрывать с байткодом ... но это тоже долгая история и повод для холиваров долгими зимними вечерами у камина)
—————
вы скажете что же js и с/с++ ? прекрасный выбор. есть стандарты, есть возможность проверить компилятор, но с обратной и/или кроссплатформенной совместимостью не так как у джавы. хорошие языки для своей ниши - скриптование в браузере (именно скриптование, а не то тяжеловеское безумие с концепцией "js новый ассемблер" которое сегодня творится) и написание близкого к железу кода. это, а не написание приложений с бизнес логикой и длительным жц.
котлин? этот очередной недоубийца джавы (без стандарта, альтернативных реализаций и тестирования совместимости) тоже ушел бы на обочину истории, но оказался нужен гуглу как запасной аэродром от нападок менеджеров оракла по поводу джавы. собственно, в мобильной разработке, с коротким жц приложений (вышла новая версия телефона - надо всё переписывать) - ему вполне себе комфортно. тут многие языки не соблюдающие принципов совместимости и наличия полного описания будут прекрасно жить.
про остальное... потом как-нибудь ))
Краткая история Java