Comments 122
Во-первых, у них своя реализация.
Во-вторых, Kotlin (тут я не уверен, что это что-то значит в данном контексте)
В-третьих, Fuchsia OS, но это не точно.
Флаттер ненативен.
Flutter is built with C, C++, Dart, and Skia (a 2D rendering engine)
И все это работает через Android NDK
Здесь написано подробно, как работает
Насчёт Flutter, насколько я вижу, сейчас ситуация упирается как раз в его окружение.
Если для андроида + Java/Kotlin у меня есть куча инструментов — Dagger, Realm, Architecture Components, Retrofit, Rx и реально куча всего разного, без чего полноценные приложения делать сложно, то вот для Flutter…
К Java SE всё это не имеет никакого отношения, там всё относительно хорошо.
А Android очень слабо привязан к Java как платформе — своя VM, свой байткод, даже в качестве языка уже больше используется Kotlin.
- Это не хайп, посмотрите, на чём сейчас пишут люди под Android.
- TIOBE — так себе показатель.
«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 дела обстоят тоже неплохо, и много всего уже в проде.
Смотрите тогда лучше, например, свежие результаты опроса от Stack Overflow, где спрашивают как раз о том, что реально используется (спойлер: там Kotlin и Swift идут почти ноздря в ноздрю).
А ещё лучше — попросту спросите у любого реального Android-разработчика, что с адопшеном Kotlin в Android-разработке. Он ответит вам, что доля уже громадная и продолжает расти.
UPD: 3 человека из 12 тыс.
Посмотрите профиль — zagayevskiy в Яндексе работает. Успехи таких, кхм-кхм, контор зависят не от разработки, а от других вещей.
Сами на Котлине, в проде, причём давно.
Хочешь, например, Optional? А фиг тебе, только начиная с API 24.
Ну и сам язык просто приятен.
А из альтернатив для больших систем — так ведь Scala есть, и Тинькофф, и Сбер на ней много что делают, и не плачут, кстати.
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, но это далеко не основной способ
Это уже не похоже на хайп, 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
Не знаю, как на других платформах (энтерпрайз, веб и проч.), но на андроиде это реальный мейнстрим. По куче разных причин, основная из которых — отсутствие плюшек из новых версий Java для андроид-девелоперов.
«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 прогрессирует с каждым годом.
Андроид мигрирует на kotlin и dart (flutter).
Погодите, так это что получается, Java EE оказалась такой же проприетарщиной как и .NET Framework?
Или не всё так плохо, и нас просто запугивают?
.NET Framework — проприетарщина. Но его и закопали уже по сути, новых фич не будет, поддержки C# 8 не будет, теперь только опенсурсный неткор и моно в тандеме.
Например, я могу собрать под .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.
Исходники в любом случае придётся написать новые, раз уж старые были закрытыми, это очевидно. Проблема вот в чём:
Если он будет модифицирован, то он должен быть переименован — [...] так и имя пакета (как javax.*), это означает, что существующие приложения не заработают на обновленной платформе без перекомпиляции после интенсивного рефакторинга.
что мешает мне прямо сейчас выпилить штатную библиотеку и написать свою с другим именем (но именем пакета javax.* )?
Вот именно это мне и непонятно.
Я так понял, Oracle поставила именно такие условия — «мы передадим вам все права на Java EE, но только если API в пакетах javax.* останутся как есть». Как по мне — чистый саботаж. Не понятно, зачем ставить это условие, ну кроме как сделать работу над Jakarta невыносимой.
Запилить пакеты javaxу.* с новыми API, а старое — пускай остается в javax.*
В самом начале работы новые пакеты на 100% повторяют старые, а в javax.* тупо стоит перенаправление на реальный код в javaxу.* После чего можно будет спокойно развивать API в пакетах javaxу.* и понемногу переезжать на него.
(и так до тех пор, пока в коде не останется ни одной ссылки на пакеты javax.* )
Ну в сообществе уже идут интенсивные обсуждения вариантов сохранения обратной совместимости. Java Agents, bytecode manipulation вот это все.
Так давно уже можно было, см. проект IKVM.NET. Я так Apache FOP использовал для генерации PDF, и с IBM WebSphere MQ тоже через JMS работать проще чем через "родной" драйвер.
Ещё Saxon под .NET "реализован" как обертка над 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.
И как потом это самое jakarta.*
запускать на Wildfly? А если запилят новый сервер поверх новых пакетов, кто будет переписывать весь мир на jakarta.*
? Если не обеспечат обратную совместимость — это будет смертью JakartaEE.
jakarta.*
, а для запуска старого новым версиям Wildfly и других серверов приложений придётся добавить «режим совместимости», в котором байткод будет подменяться при загрузке классов. Предпоследний пункт как раз об этом. И в статье по ссылке это есть.Вы же понимаете что этот магический режим совместимости будет источником перформанс пенальти будь то на этапе компиляции, или в рантайме. А с этим у JavaEE и так плохо.
Дальше — больше, кроме самих серверов есть куча других библиотек которые занимаются рефлексией в рантайме, как они будут работать в таком двояком мире большой вопрос (и кто будет переписывать все это под новый мир).
На ровном месте создается огромное количество проблем, сделать это все бесшовно и без багов, да еще так, чтобы работало с легаси — близко к невозможному. Ведь цель номер один это сохранить полную обратную совместимость.
Поэтому для JakartaEE жизненно важно владеть существующими API.
А тот же RedHat (IBM) может себе позволить купить у 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, но добавить в пакет новый публичный класс не сможете.
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 пакеты.
Вы можете менять и распространять код как написано в лицензии, до тех пор пока не нарушаете товарный знак "Java", который принадлежит Oracle. Использование пакетов javax.*
попадает под trademark, отсюда и проблемы.
В статье, да и по логике — изменение будет производным продуктом, и будет нарушать Java трейдмарк.
- Запрещено ли это в GPL, а в лицензии которая на большинстве ораклового кода: https://oss.oracle.com/licenses/CDDL+GPL-1.1?
- В любом случае не понимаю до чего вы докапываетесь этим реплаем, скажите уже открыто.
JDK распространяется под GPLv2, которая не имеет пункта про передачу патентов.
То есть, за создание производной работы тебя не засудят, да. Засудят за нарушение патентов.
Эта проблема решена в GPLv3, но переходить на неё Оракл, по очевидным причинам, не станет
Меня беспокоит затронет ли это уже существующие компоненты JavaEE? Например у Eclipse Foundation была и есть годная имплементация JPA/JAXB под названием EclipseLink/MOXy...
Достаточно будет `java.` в начале импортов заменить на `jakarta.*` и всё.
Не видим никаких сложностей, говорили они! В чем проблема, говорили они…
Более того, если у тебя хэлловорлд — это не проблема никакая, поменять в двух местах. Если у тебя десять тысяч классов, надерганных на пару сотен микросервисов, то тебе придётся остановить всю свою инфраструктуру хотя бы чтобы обновиться. И это если всё пойдёт гладко.
На практике, в любом более-менее сложном Java-фрэймворке под капотом стопицот хрупких костылей на рефлексии. Никогда не угадаешь, какой из них стрельнёт и когда.
Особенно в крайних оракла версиях, где он гордо заявляет что вам больше не нужны DBA мы все автоматом фиксить на лету будем, вам достаточно просто намекнуть какие данные вам нужны, и заплатить 100500 денег ;)
Было много реализаций Java EE, скорее всего были open source с приемлимой для Eclipse лицензии. Как тогда IBM, Sun делали разные реализации? Почему Eclipse не может пилить свой open-source с теми же пакетами? Если они используют имя Jakarta, как торговая марка на Java может помешать?
Переговоры провалены: как Oracle убила Java EE