Комментарии 122
А какова теперь судьба Java SE? И вообще судьба Андроида?
Во-первых, у них своя реализация.
Во-вторых, Kotlin (тут я не уверен, что это что-то значит в данном контексте)
В-третьих, Fuchsia OS, но это не точно.
Есть еще Flutter. Как по мне сильнейший козырь и удар ниже пояса по Java.
Fuchsia OS и flutter это одна стихия, если можно сказать
Флаттер ненативен.
Он нативен
И все это работает через Android NDK
Здесь написано подробно, как работает
Flutter is built with C, C++, Dart, and Skia (a 2D rendering engine)
И все это работает через Android NDK
Здесь написано подробно, как работает
Удар ударом, только существует множество компаний, занимающиеся разработкой приложений на заказ и до сих пор набирающих разрабов на Java. Переход на Флаттер потребует большого количества времени и денег, ибо разные языки совершенно (Dart, на котором написан Flutter — это почти JS). Это все-равно что сказать нафиг Java вообще нужна, есть же С++. Мне на собеседованиях так и отвечали на мой вопрос, мол, на Dart не планируем переходить в ближайшее время, ибо очень экстремально, и это даже ни смотря на то, что для Android и для iOS все вынуждены иметь две отдельные команды разрабов и тестеров.
ИМХО тут скорее PWA от того же Гугл выстрелит чем Flutter а там где надо с операционной системой взаимодействовать тесно там как правили балом нативные приложения отдельно под каждую ОС там и будут. В общем — у iOS и Android разработчиков все будет ОК. А вот Flutter, Xamarin, ReactNative и т.д. подвинуться скорее всего. В прочем кто знает. Время покажет как оно на самом деле будет.
Вот тут хз. Как и в случае Java, основной интерес ведь представляет не сам язык, а инфраструктура, которая выросла вокруг этого языка. Если не было бы J2EE, Spring, Hibernate (тут продолжаем список) — кому интересна была бы Java? Мало кому.
Насчёт Flutter, насколько я вижу, сейчас ситуация упирается как раз в его окружение.
Если для андроида + Java/Kotlin у меня есть куча инструментов — Dagger, Realm, Architecture Components, Retrofit, Rx и реально куча всего разного, без чего полноценные приложения делать сложно, то вот для Flutter…
Насчёт Flutter, насколько я вижу, сейчас ситуация упирается как раз в его окружение.
Если для андроида + Java/Kotlin у меня есть куча инструментов — Dagger, Realm, Architecture Components, Retrofit, Rx и реально куча всего разного, без чего полноценные приложения делать сложно, то вот для Flutter…
Не сказал бы, что для активно развивающегося фреймворка у Flutter всё печально с окружением. Да, все ещё меньше либ, чем под нативку, но те вещи, которые, условно, не были доступны год назад, бодро появляются и развиваются. Достаточно взглянуть на Dart Pub и то, что он предлагает.
К Java SE всё это не имеет никакого отношения, там всё относительно хорошо.
А Android очень слабо привязан к Java как платформе — своя VM, свой байткод, даже в качестве языка уже больше используется Kotlin.
НЛО прилетело и опубликовало эту надпись здесь
- Это не хайп, посмотрите, на чём сейчас пишут люди под Android.
- TIOBE — так себе показатель.
НЛО прилетело и опубликовало эту надпись здесь
Цитата с google io19:
«Two years ago, we announced Kotlin was a supported language for Android. Our top developers loved it already, and since then, it’s amazing how fast it’s grown. Over 50% of professional Android developers now use Kotlin, it’s been one of the most-loved languages two years running on Stack Overflow, and one of the fastest-growing on GitHub in number of contributors.
Today we’re announcing another big step: Android development will become increasingly Kotlin-first..»
android-developers.googleblog.com/2019/05/google-io-2019-empowering-developers-to-build-experiences-on-Android-Play.html
В backend дела обстоят тоже неплохо, и много всего уже в проде.
«Two years ago, we announced Kotlin was a supported language for Android. Our top developers loved it already, and since then, it’s amazing how fast it’s grown. Over 50% of professional Android developers now use Kotlin, it’s been one of the most-loved languages two years running on Stack Overflow, and one of the fastest-growing on GitHub in number of contributors.
Today we’re announcing another big step: Android development will become increasingly Kotlin-first..»
android-developers.googleblog.com/2019/05/google-io-2019-empowering-developers-to-build-experiences-on-Android-Play.html
В backend дела обстоят тоже неплохо, и много всего уже в проде.
НЛО прилетело и опубликовало эту надпись здесь
TIOBE ориентируется на поисковые запросы, а запросы могут быть связаны с теми же статьями, которые вы сами и отметаете как хайп.
Смотрите тогда лучше, например, свежие результаты опроса от Stack Overflow, где спрашивают как раз о том, что реально используется (спойлер: там Kotlin и Swift идут почти ноздря в ноздрю).
А ещё лучше — попросту спросите у любого реального Android-разработчика, что с адопшеном Kotlin в Android-разработке. Он ответит вам, что доля уже громадная и продолжает расти.
Смотрите тогда лучше, например, свежие результаты опроса от Stack Overflow, где спрашивают как раз о том, что реально используется (спойлер: там Kotlin и Swift идут почти ноздря в ноздрю).
А ещё лучше — попросту спросите у любого реального Android-разработчика, что с адопшеном Kotlin в Android-разработке. Он ответит вам, что доля уже громадная и продолжает расти.
НЛО прилетело и опубликовало эту надпись здесь
Комментарии вида «использую Java поверх ядра на С++», вероятно, пишут бэкендеры. Ещё раз: спросите любого Android-разработчика. Всем, кто видит ситуацию в Android-разработке, очевидно, что язык там принят настолько массово и бесповоротно, что теперь двуязычие может там «изжить само себя» только в виде отказа от Java.
А много ли Kotlin-only вакансий разработчиков? Судя по MonsterJob — Kotlin вообще упоминается примерно в 20% вакансий по разработке под Android. Допускаю, что локально в России популярность Kotlin выше по понятным причинам.
Kotlin-only вакансий пока что немного, потому что типичный сценарий миграции такой: новый код в приложении пишут на Kotlin, но написанный ранее за годы джавовый не пытаются сразу весь переписать, а неспешно заменяют по мере развития. Соответственно, в таком случае сталкиваться с джавовым кодом приходится и в описание вакансии Java попадает, но уже как легаси.
А про MonsterJob — как именно вы высчитали 20%? Не вижу там лёгкого способа получить полную статистику, попробовал просто вбить в поиск «Android» и кликнуть в первые пять вылезших вакансий. Котлин оказался упомянут в четырёх из пяти.
Пишу вам из продакшена — два года на Котлине. Судя по опыту собеседований в этом году, очень многие либо на него перешли, либо в процессе.
На данный момент кроме вас из продакшна отписался только один человек — из примерно 11 тыс. просмотревших статью.
UPD: 3 человека из 12 тыс.
UPD: 3 человека из 12 тыс.
И ни одного, кто бы отписался что использует Java на продакшене. По вашей логике у нас есть победитель
У нас 10% Котлин, 80% Java, 10% C++. Очевидно смешивать языки никто не будет, значит и Котлин и Java продолжат расти со своей скоростью, наверное соотношение немного поменяется через лет 5, но не раньше.
Ни разу не очевидно. Мы мешаем джаву и котлин, и живем отлично. Джаву постепенно выкидываем.
Вы занимаетесь переписыванием, но если ваш процесс переписывания растянется на лет 5-7, то успехов в такой мешанине.
Пфф, Cmd+Alt+Shift+K. Конвертер вполне нормально работает, за ним чуть причесать. Это раз. Второе, если код меняется не сильно, то можно и на джаве написать, хоть это и очень неприятно после котлина. Третье, джава и котлин интероперабельны, так что весь новый код на котлине, даже если он как-то использует старый джавовый. Поменьше категоричности, вы тут не пуп Земли. Другие люди живут по-другому.
Посмотрите профиль — zagayevskiy в Яндексе работает. Успехи таких, кхм-кхм, контор зависят не от разработки, а от других вещей.
Уже достаточно много компаний, кто используют его в проде. Посмотрите на том же hh.ru. У нас в том числе он используется.
НЛО прилетело и опубликовало эту надпись здесь
Для меня реально интересно было бы посмотреть на человека, который сейчас начинал бы писать новый проект на андроиде, используя Java, а не Котлин.
Сами на Котлине, в проде, причём давно.
Сами на Котлине, в проде, причём давно.
Судя по тому, что на MonsterJob 4 из 5 вакансий Android Developer не упоминают Kotlin — таких полно. Вообще «убийцы» Java и до Kotlin были — Ceylon, Clojure, Groovy… Поддержка Google мало что значит, с учётом того, что в Fuchsia Kotlin они до сих пор не добавили (зато добавили Go) — видимо в будущем планируют переехать на полностью нативное окружение.
Поживём-увидим, но для андроид-разработки сейчас не использовать Котлин — можно, но не нужно. Ещё раз уточню, что одна из основных причин — это доступность фишек, которые на андроид-платформе недоступны в силу ограниченной поддержки фишек из новых версий Java.
Хочешь, например, Optional? А фиг тебе, только начиная с API 24.
Ну и сам язык просто приятен.
А из альтернатив для больших систем — так ведь Scala есть, и Тинькофф, и Сбер на ней много что делают, и не плачут, кстати.
Хочешь, например, Optional? А фиг тебе, только начиная с API 24.
Ну и сам язык просто приятен.
А из альтернатив для больших систем — так ведь Scala есть, и Тинькофф, и Сбер на ней много что делают, и не плачут, кстати.
Большинство фишек можно давно подключить с помощью библиотек, в т.ч. optional, например:
https://github.com/aNNiMON/Lightweight-Stream-API
https://github.com/aNNiMON/Lightweight-Stream-API
Кстати, Groovy никогда не позиционировался как убийца java, но как скриптовый язык и конструктор DSL, он довольно хорош. Котлин в эту нишу не попадает из-за проблем поддержки JSR-223 (у них там очень тормозная реализация была, когда в последний раз смотрел).
Ну только JSR-223 это не основной скриптинг в котлине, уже больше года есть https://github.com/Kotlin/KEEP/blob/master/proposals/scripting-support.md и да, он поддерживает запуск через JSR-223, но это далеко не основной способ
Не только под Android… После того как Spring Boot стал без костылей поддерживать Котлин, переперли все 16 микросервисов достаточно крупного приложения на него.
Это уже не похоже на хайп, Kotlin рекомендуется как основной язык для Android-разработки самим гуглом: https://android-developers.googleblog.com/2019/05/google-io-2019-empowering-developers-to-build-experiences-on-Android-Play.html
Today we’re announcing another big step: Android development will become increasingly Kotlin-first
TIOBE очень консервативный индекс. Swift это выброс, тк Apple просто заставила всех перейти. Люди пишут в проде на Котлине.
Куча приложений в проде, написанных на Котлине — часть из них попала в прод ещё до того, как Гугл объявил о поддержке Котлина.
Не знаю, как на других платформах (энтерпрайз, веб и проч.), но на андроиде это реальный мейнстрим. По куче разных причин, основная из которых — отсутствие плюшек из новых версий Java для андроид-девелоперов.
Не знаю, как на других платформах (энтерпрайз, веб и проч.), но на андроиде это реальный мейнстрим. По куче разных причин, основная из которых — отсутствие плюшек из новых версий Java для андроид-девелоперов.
НЛО прилетело и опубликовало эту надпись здесь
Работаю в Австралии, переписали все мобильные приложения на Котлин
Коротко о том, как в США «мало кто знает о Kotlin»:
«In a recent internal survey at Uber, we asked nearly 100 mobile engineers if they were willing to accept slower build times in order to be able to use Kotlin. The result? 95 percent have said that they would be willing to accept slower builds if they could write their code in Kotlin».
eng.uber.com/measuring-kotlin-build-performance
Когда в одном из крупнейших американских мобильных приложений 95% разработчиков выступают за использование языка, даже если это снизит скорость сборки — это не «мало кто знает», это universal acclaim.
«In a recent internal survey at Uber, we asked nearly 100 mobile engineers if they were willing to accept slower build times in order to be able to use Kotlin. The result? 95 percent have said that they would be willing to accept slower builds if they could write their code in Kotlin».
eng.uber.com/measuring-kotlin-build-performance
Когда в одном из крупнейших американских мобильных приложений 95% разработчиков выступают за использование языка, даже если это снизит скорость сборки — это не «мало кто знает», это universal acclaim.
Работаю в США, про Котлин знают все.
К Java SE всё это не имеет никакого отношения, там всё относительно хорошо.
Я бы не спешил с такими выводами. Пакеты «javax.» есть даже в ядре JDK, а синдром вахтера у Oracle прогрессирует с каждым годом.
У Java SE отдельная судьба в виде OpenJDK, и там у Oracle уже нет такой власти.
Андроид мигрирует на kotlin и dart (flutter).
Андроид мигрирует на kotlin и dart (flutter).
Для тех кто не в курсе хитросплетений, можно ликбез — какое отношение Java EE имеет к Eclipse и что теперь грозит собственно Eclipse IDE?
Под Eclipse в тексте подразумевается не Eclipse IDE, а организация Eclipse Foundation (которая занимается и этой IDE, и много чем ещё — в частности, вот Java EE должна была перейти от Oracle туда как Jakarta EE). Думаю, если только организация не прекратит своё существование, то IDE особо ничего не грозит, это разные истории.
Foundation — это ведь значит не только права, но и деньги? Я про что, кто платит разработчикам Eclipse IDE? Если Foundation составляет какую-то заметную долю в их зарплатах, это еще как ударит
Eclipse Foundation — это больше про организацию, а не разработку. Более подробно — www.eclipse.org/org (Eclipse committers are typically employed by organizations or are independent developers that volunteer their time to work on the Eclipse projects). Ну и бюджет у Eclipse Foundation соотв. весьма скромный — www.eclipse.org/org/foundation/reports/annual_report.php (в 2017 — $5.6M vs $562M у Mozilla Foundation).
Eclipse IDE — ничего. Eclipse Foundation — «опенсоурс» команда, которая поддерживает многое ПО в области Java, например Eclipse IDE или сервер Glassfish. Java EE — Oracle хотела передать Eclipse Foundation поддержку JEE(как когда-то — Glassfush), но переговоры провалились.
Eclipse IDE ничего не должно грозить, ведь речь идет об Enterprise Java, которая относится к корпоративным приложениям, а не к конкретной IDE.
НЛО прилетело и опубликовало эту надпись здесь
Погодите, так это что получается, Java EE оказалась такой же проприетарщиной как и .NET Framework?
Или не всё так плохо, и нас просто запугивают?
Нет, не такой же. Но и .NET уже не проприетарщина вроде как.
.NET Framework — проприетарщина. Но его и закопали уже по сути, новых фич не будет, поддержки C# 8 не будет, теперь только опенсурсный неткор и моно в тандеме.
А можно пруфы на счет отсутствия в .NET Framework поддержки C# 8? Там же в основном синтаксический сахар со стороны компилятора.
Например, я могу собрать под .NET Framework 4.0, используя те языковые фичи, которых не было, когда он вышел.(async/await исключение).
Например, я могу собрать под .NET Framework 4.0, используя те языковые фичи, которых не было, когда он вышел.(async/await исключение).
Там появилась возможность добавлять в методы интерфейсов реализацию (т.н. default-методы), притом заявляется возможность использования этой фичи для обеспечения обратной совместимости (например, чтобы наконец-то унаследовать ICollection<> от IReadOnlyCollection<>). Без поддержки рантайма такого сделать нельзя.
Для default interface methods нужна поддержка со стороны CLR, которой в legacy фреймворке нет.
Для нормальной работы со спанами нужна поддержка со стороны CLR и наборы перегрузок в тех же стримах, которых в legacy фреймворке нет.
Собственно, процесс слома совместимости новых фич C# с legacy фреймворком уже пошёл и останавливаться не собирается.
А async/await, да, я даже на .NET 2.0 заводил.
Последняя версия .net framework 4.8, новых версий больше не будет. Дальше только неткор. Соответственно C#8 может и будет, а вот 9-10 и так далее уже нет. Не все фичи языка компилируются в старый код. Те же концепты емнип потребуют ратнайм-поддержки. Или генерик-атрибуты. Или еще что-нибудь.
Ещё вопрос. Вроде же был прецедент, согласно которому API не подлежат копирайту. Так зачем в таком случае менять имя пакета?
Но тут речь-то уже не об API, а об исходниках конкретной реализации этого API.
Исходники в любом случае придётся написать новые, раз уж старые были закрытыми, это очевидно. Проблема вот в чём:
Если он будет модифицирован, то он должен быть переименован — [...] так и имя пакета (как javax.*), это означает, что существующие приложения не заработают на обновленной платформе без перекомпиляции после интенсивного рефакторинга.
а почему должен?
что мешает мне прямо сейчас выпилить штатную библиотеку и написать свою с другим именем (но именем пакета javax.* )?
что мешает мне прямо сейчас выпилить штатную библиотеку и написать свою с другим именем (но именем пакета javax.* )?
Вот именно это мне и непонятно.
Юридически ничто не мешает менять API в пакетах javax.* но только до тех пор, пока это не стало частью договора между Oracle и Eclipse Foundation.
Я так понял, Oracle поставила именно такие условия — «мы передадим вам все права на Java EE, но только если API в пакетах javax.* останутся как есть». Как по мне — чистый саботаж. Не понятно, зачем ставить это условие, ну кроме как сделать работу над Jakarta невыносимой.
Я так понял, Oracle поставила именно такие условия — «мы передадим вам все права на Java EE, но только если API в пакетах javax.* останутся как есть». Как по мне — чистый саботаж. Не понятно, зачем ставить это условие, ну кроме как сделать работу над Jakarta невыносимой.
а зачем менять API в пакетах javax.*?
Запилить пакеты javaxу.* с новыми API, а старое — пускай остается в javax.*
В самом начале работы новые пакеты на 100% повторяют старые, а в javax.* тупо стоит перенаправление на реальный код в javaxу.* После чего можно будет спокойно развивать API в пакетах javaxу.* и понемногу переезжать на него.
(и так до тех пор, пока в коде не останется ни одной ссылки на пакеты javax.* )
Запилить пакеты javaxу.* с новыми API, а старое — пускай остается в javax.*
В самом начале работы новые пакеты на 100% повторяют старые, а в javax.* тупо стоит перенаправление на реальный код в javaxу.* После чего можно будет спокойно развивать API в пакетах javaxу.* и понемногу переезжать на него.
(и так до тех пор, пока в коде не останется ни одной ссылки на пакеты javax.* )
Придется ломать обратную совместимость => миграция проектов будет очень дорогой. Еще один повод для архитекторов досконально пересмотреть выбранный стек технологий и, возможно, принять решение на в пользу Jakarta.
Ну в сообществе уже идут интенсивные обсуждения вариантов сохранения обратной совместимости. Java Agents, bytecode manipulation вот это все.
Ну в сообществе уже идут интенсивные обсуждения вариантов сохранения обратной совместимости. Java Agents, bytecode manipulation вот это все.
НЛО прилетело и опубликовало эту надпись здесь
Интересные изменения, особенно, что можно использовать Java из .NET
Я так и знал, что кто-нибудь переведёт именно эту статью с кричащим заголовком и начнётся паника. Лучше бы перевели Jakarta EE: A New Hope.
Если кратко и по сути о происходящем:
Подытоживая: Java в очередной раз идёт трудным путём, но к ещё более светлому будущему.
Если кратко и по сути о происходящем:
- Oracle должны были передать Eclispe Foundation права на зонтичный стандарт Java EE, чтобы полностью и окончательно сделать его open source и free. Подчеркну, что разговор именно о стандартах, язык и виртуальная машина уже open source и free.
- Oracle попытались оставить себе юридические лазейки, сохраняющие им возможности контроля за развитием, чтобы быть самыми равными среди равных. Естественно, Eclispe Foundation отказались от заключения соглашений на таких условиях.
- В результате Eclispe Foundation сейчас не могут изменять пакет
javaxи не могут свободно использовать торговую марку Java™. - Eclispe Foundation решает переименовать
javax.*вjakarta.*и убрать слово «Java» из названий стандартов входящих в Java EE — Java Persistence API (JPA), Java Architecture for XML Binding (JAXB) и прочих. - С одной стороны это затруднит процесс перехода Java EE в open source, так как для сохранения обратной совместимости придётся совершить много дополнительных операций и разработать сложные механизмы миграции.
- С другой стороны это позволит полностью лишить Oracle привилегированного положения, а также основательно переработать и улучшить систему инертных и местами устаревших стандартов.
Подытоживая: Java в очередной раз идёт трудным путём, но к ещё более светлому будущему.
Согласен. Новость так себе, но осадок то останется.
Лично я сложил для себя мнение — Java переживает не лучшие времена и возможно так сложится что эта платформа будет продаваться только вместе с модными оракловыми продуктами типа Oracle Retail, RPAS, OEBS и т.д
Как по мне очень странное поведение оракла на фоне стратегии Microsoft.
Лично я сложил для себя мнение — Java переживает не лучшие времена и возможно так сложится что эта платформа будет продаваться только вместе с модными оракловыми продуктами типа Oracle Retail, RPAS, OEBS и т.д
Как по мне очень странное поведение оракла на фоне стратегии Microsoft.
Java такие времена проживает с того момента как Oracle купил Sun. Как говорится «Don't make the mistake of anthropomorphizing Larry Ellison». Для платформы такого сложится уже точно не может, Oracle её не контролирует. Самое страшное, что может произойти — фрагментация enterprise-решений, когда одни web-приложения можно будет запустить только на Oracle WebLogic, а другие только на IBM WebSphere. Да и то вряд ли.
И как потом это самое jakarta.* запускать на Wildfly? А если запилят новый сервер поверх новых пакетов, кто будет переписывать весь мир на jakarta.*? Если не обеспечат обратную совместимость — это будет смертью JakartaEE.
На старом WildFly вероятно будут проблемы, но наверняка WildFly оперативно обновится под новую реальность. Запуск нового ПО на старых версиях WildFly вообще затруднителен, слишком много возникает конфликтов версий библиотек.
Новый код надо будет просто писать с использованием пакетов из
jakarta.*, а для запуска старого новым версиям Wildfly и других серверов приложений придётся добавить «режим совместимости», в котором байткод будет подменяться при загрузке классов. Предпоследний пункт как раз об этом. И в статье по ссылке это есть.Вы же понимаете что этот магический режим совместимости будет источником перформанс пенальти будь то на этапе компиляции, или в рантайме. А с этим у JavaEE и так плохо.
Дальше — больше, кроме самих серверов есть куча других библиотек которые занимаются рефлексией в рантайме, как они будут работать в таком двояком мире большой вопрос (и кто будет переписывать все это под новый мир).
На ровном месте создается огромное количество проблем, сделать это все бесшовно и без багов, да еще так, чтобы работало с легаси — близко к невозможному. Ведь цель номер один это сохранить полную обратную совместимость.
Поэтому для JakartaEE жизненно важно владеть существующими API.
А тот же RedHat (IBM) может себе позволить купить у Oracle необходимые права и не заниматься переименованием ради переименования, и вот у нас уже образовалась фрагментация.
Я понимаю, что это костыль и он приведёт к увеличению времени запуска, но Oracle не оставляет выбора.
Making this possible is going to involve some form of bytecode manipulation, which may sound severe, but in reality is how the majority of Java EE and Jakarta EE works anyway.
Nearly everything created in Java EE after 2006 uses some form of bytecode creation or manipulation. It’s the dirty little secret and a favored trick of the industry
В результате Eclispe Foundation сейчас не могут изменять пакет javax
О каких конкретно классах идёт речь? Первые попавшиеся под руку примеры:
Раз. github.com/javaee/servlet-spec/blob/master/src/main/java/javax/servlet/http/HttpServlet.java Licensed under the Apache License, Version 2.0.
Два. github.com/javaee/javamail/blob/master/mail/src/main/java/com/sun/mail/auth/OAuth2SaslClient.java GNU General Public License Version 2 only
Три. github.com/javaee/javax.ejb/blob/master/src/main/java/javax/ejb/EJB.java GNU
General Public License Version 2 only
Берите и меняйте их сколько влезет. Замечу что первый и третий пример находятся в javax и является API (а история про джаву и копирайты на API уже была), а второй вполне себе имплементация.
а история про джаву и копирайты на API уже была
И закончилась она тем, что постановлением апелляционного суда API могут быть защищены копирайтом. Google и EFF обращались в верховный суд, но безрезультатно. Можете изменять HttpServlet.java, но добавить в пакет новый публичный класс не сможете.
В статье написано чёрным по белому:
Я утверждаю что это утверждение ложно. Файлы имеют лицензию, разрешающую их изменять и распространять модифицированную версию.
Откуда вы это взяли? Я не вижу ничего подобного ни в одной из двух статей («Negotiations Failed: How Oracle killed Java EE» и «Jakarta EE: A New Hope»).
Eclipse Foundation может использовать довольно устаревший код без права модификации
Я утверждаю что это утверждение ложно. Файлы имеют лицензию, разрешающую их изменять и распространять модифицированную версию.
добавить в пакет новый публичный класс не сможете
Откуда вы это взяли? Я не вижу ничего подобного ни в одной из двух статей («Negotiations Failed: How Oracle killed Java EE» и «Jakarta EE: A New Hope»).
The Eclipse Foundation may use some rather outdated code, but must not modify it. If it gets modified, it must be renamed – both, the project name (like JAX-RS, which is not nice but acceptable) but also the package name (like javax.*)
Из «Negotiations Failed: How Oracle killed Java EE»
As originally envisioned, existing code would be under javax and modifications would be allowed with some restrictions. Code that had to be outside those restrictions would have been in the jakarta namespace. The way this would have played out is that an API like CDI, for example, would start 100% javax and slowly become some mix of javax and jakarta as it grew. Some specifications may have seen very little impact, some a lot. The line would have been decided by an unchangeable legal agreement we would never be able to read, but would have to intimately know.
The new rule is easy. If the specification API classes will be modified in any way, the specification’s API will be moved entirely to the jakarta namespace.
Из «Jakarta EE: A New Hope»
То есть, если хоть как-нибудь изменишь JPA, например, это больше нельзя будет называть JPA и нельзя располагать в пакете
javax.persistence, иначе Oracle засудит.The new rule is easy. If the specification API classes will be modified in any way, the specification’s API will be moved entirely to the jakarta namespace.
Это всего лишь «в эклипс фаундейшене решили что они будут перекладывать файл в другой пакет когда решили его поменять». Ну хотят перекладывать — пусть перекладывают, имеют право. Но эта цитата не является ответом на вопрос «что запрещает им менять файлы и добавлять новые прям в те же пакеты в которых они лежат».
Я утверждаю что это утверждение ложно
То есть вы считаете, что в статье написана неправда, а множество серьёзных в мире Java людей врут или поддались беспочвенной панике?
Ещё раз. В файлах, которые я привёл в пример, недвусмысленно указана лицензия, разрешающая их модификацию и распространение как исходных, так и модифицированных версий.
На чём основаны утверждения «модифицировать нельзя» или «нельзя добавлять новые файлы в тот же пакет» мне неизвестно.
Возможно эти серьёзные люди (и вы в том числе) знают что-то ещё. Ну так ответьте, откуда у вас информация про запрет на добавление новых файлов в существующие javax пакеты.
На чём основаны утверждения «модифицировать нельзя» или «нельзя добавлять новые файлы в тот же пакет» мне неизвестно.
Возможно эти серьёзные люди (и вы в том числе) знают что-то ещё. Ну так ответьте, откуда у вас информация про запрет на добавление новых файлов в существующие javax пакеты.
Я ориентируюсь на информацию из статей. Цитаты я вам привёл. Впрочем, из этих цитат следует, что и код изменять тоже нельзя. Как это соотносится с действующими на этот код лицензиями я не знаю.
Вы можете менять и распространять код как написано в лицензии, до тех пор пока не нарушаете товарный знак "Java", который принадлежит Oracle. Использование пакетов javax.* попадает под trademark, отсюда и проблемы.
Я вот сейчас возьму и нажму «Fork» на гитхабовом репозитории с javax.*. Начал ли я при этом «использовать пакеты javax.*» и тем самым нарушать trademark? А если я после этого поменял один из файлов и закоммитил изменения, я уже начал «использовать пакеты javax.*»? Если на оба вопроса ответ «нет», то чего ещё надо эклипсу? Ну не называйте это словом JavaEE и всё.
В статье, да и по логике — изменение будет производным продуктом, и будет нарушать Java трейдмарк.
- Запрещено ли это в GPL, а в лицензии которая на большинстве ораклового кода: https://oss.oracle.com/licenses/CDDL+GPL-1.1?
- В любом случае не понимаю до чего вы докапываетесь этим реплаем, скажите уже открыто.
> Файлы имеют лицензию, разрешающую их изменять и распространять модифицированную версию.
JDK распространяется под GPLv2, которая не имеет пункта про передачу патентов.
То есть, за создание производной работы тебя не засудят, да. Засудят за нарушение патентов.
Эта проблема решена в GPLv3, но переходить на неё Оракл, по очевидным причинам, не станет
JDK распространяется под GPLv2, которая не имеет пункта про передачу патентов.
То есть, за создание производной работы тебя не засудят, да. Засудят за нарушение патентов.
Эта проблема решена в GPLv3, но переходить на неё Оракл, по очевидным причинам, не станет
НЛО прилетело и опубликовало эту надпись здесь
Меня беспокоит затронет ли это уже существующие компоненты JavaEE? Например у Eclipse Foundation была и есть годная имплементация JPA/JAXB под названием EclipseLink/MOXy...
Какой желтушный заголовок. Достаточно будет `java.` в начале импортов заменить на `jakarta.*` и всё.
Достаточно будет `java.` в начале импортов заменить на `jakarta.*` и всё.
Не видим никаких сложностей, говорили они! В чем проблема, говорили они…
У тебя не всегда есть исходники софта. Их могли не передать (особенно если софт покупной). Их могли потерять. В конце концов, после пересборки может немного поменяться поведение, а те люди, которые это написали — уже умерли или отказываются иметь с тобой дела. И это если не касаться такой грязной и мрачной темы как сертификация в сцпецслужбах России. Удачи поменять что-то в таком софте.
Более того, если у тебя хэлловорлд — это не проблема никакая, поменять в двух местах. Если у тебя десять тысяч классов, надерганных на пару сотен микросервисов, то тебе придётся остановить всю свою инфраструктуру хотя бы чтобы обновиться. И это если всё пойдёт гладко.
Более того, если у тебя хэлловорлд — это не проблема никакая, поменять в двух местах. Если у тебя десять тысяч классов, надерганных на пару сотен микросервисов, то тебе придётся остановить всю свою инфраструктуру хотя бы чтобы обновиться. И это если всё пойдёт гладко.
Теоретически.
На практике, в любом более-менее сложном Java-фрэймворке под капотом стопицот хрупких костылей на рефлексии. Никогда не угадаешь, какой из них стрельнёт и когда.
На практике, в любом более-менее сложном Java-фрэймворке под капотом стопицот хрупких костылей на рефлексии. Никогда не угадаешь, какой из них стрельнёт и когда.
При принятии решения об использовании того или иного ПО в проектах, буду избегать коммерческого ПО от Oracle (в первую очередь БД Oracle) заменяя альтернативным. Очень уж у них карма плохая.
А я вам про это сегодня статейку написал! habr.com/ru/post/450992
и какие у вас альтернативы, особенно их хардварной реализации?
IBM?
Если вы о DB2 — то оно чуток немного совсем более медленное чем оракл, особенно в его хардварном варианте.
Особенно в крайних оракла версиях, где он гордо заявляет что вам больше не нужны DBA мы все автоматом фиксить на лету будем, вам достаточно просто намекнуть какие данные вам нужны, и заплатить 100500 денег ;)
Особенно в крайних оракла версиях, где он гордо заявляет что вам больше не нужны DBA мы все автоматом фиксить на лету будем, вам достаточно просто намекнуть какие данные вам нужны, и заплатить 100500 денег ;)
Из статьи ничего непонятно о сути конфликта.
Было много реализаций Java EE, скорее всего были open source с приемлимой для Eclipse лицензии. Как тогда IBM, Sun делали разные реализации? Почему Eclipse не может пилить свой open-source с теми же пакетами? Если они используют имя Jakarta, как торговая марка на Java может помешать?
Было много реализаций Java EE, скорее всего были open source с приемлимой для Eclipse лицензии. Как тогда IBM, Sun делали разные реализации? Почему Eclipse не может пилить свой open-source с теми же пакетами? Если они используют имя Jakarta, как торговая марка на Java может помешать?
Раньше Oracle единолично владела всеми правами на Java EE. Только они могли решать, что будет в следующей версии стандарта, а что не будет, только они решали, какие реализации соответствуют стандарту, а какие нет, и т.п. Такая власть одной коммерческой компании над стандартами приводила к существенным рискам использования другими компаниями реализаций этих стандартов. Суть передачи прав на стандарты в Eclipse Foundation была как раз в том, чтобы они развивались и управлялись общественной организацией. А суть конфликта в том, что Oracle любит переобуваться на лету и в последний момент решили не отдавать права полностью.
как показывает практика весь этот вой из ничего. могу вкратце даже не вникая дать прогноз: разберутся и всё будет хорошо, хотя я spring ни на что бы не променял
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Переговоры провалены: как Oracle убила Java EE