Сегодня (3 мая) президент Eclipse Foundation Майк Милинкович (Mike Milinkovic) написал в своем блоге об окончательных результатах закрытых переговоров между Oracle и Eclipse Foundation о товарном знаке. Как мы помним, Oracle объявила, что она открывает исходный код Java EE для этой организации, так что фреймворк будет с открытым кодом “по-настоящему”. После 18 месяцев интенсивных переговоров все усилия подошли к концу: переговоры провалены. Соглашения о товарном знаке не будет.
Простыми словами, причина, согласно протоколов встречи совета директоров, в том, что Oracle взамен выдвинули ряд неприемлемых условий. Некоторые из них подвергают серьезному риску само существование Eclipse Foundation. В Oracle потребовали, чтобы продукты, распространяемые Eclipse Foundation (такие, как Eclipse IDE) были укомплектованы JRE сертифицированными только Oracle или ее лицензиатами — никаких сертификатов других вендоров или несертифицированных сред выполнения. Следовательно, и IDE, и GlassFish не были бы больше вендор-независимыми. И это ограничение не было озвучено в начале переговоров, о нем было объявлено значительно позже, когда передача кода уже началась. Можно предположить, что это было реакцией на передачу OpenJ9 JVM от IBM, что является прямой угрозой бизнесу Oracle. Но, как только продукты Eclipse перестали бы быть вендор-независимыми, это могло привести к отмене налоговых льгот для Eclipse Foundation, что означало бы финансовое фиаско и, возможно, означало бы конец организации в целом. Следовательно, это было не просто неприемлемо, было просто невозможно согласиться с условиями Oracle, так что переговоры в той или иной мере полностью провалились.
Все, что от этого осталось — не более и не менее, чем конец Java EE. Eclipse Foundation может использовать довольно устаревший код без права модификации. Если он будет модифицирован, то он должен быть переименован — как имя проекта (как JAX-RS, что не очень здорово, но приемлемо), так и имя пакета (как javax.*), это означает, что существующие приложения не заработают на обновленной платформе без перекомпиляции после интенсивного рефакторинга. Следовательно, это будет совершенно новая, несовместимая платформа, наихудший вариант из возможных, поскольку нарушается не только принцип “WORA” (Write Once Run Anywhere), да в реальности этого просто не произойдет: после 18 месяцев практически никто из вендоров приложений вообще не захочет потратить время и деньги для поставки новых пересобранных версий всем клиентам во имя поддержки переименованной платформы с сомнительным будущим. Будущее неясно, потому что Oracle уже начала политику блокирования решений совета директоров Eclipse Foundation, в котором у Oracle есть представитель, в котором необходимо единогласное решение. У Oracle есть сила и, похоже, она будет использовать эту силу, чтобы блокировать будущее Eclipse Foundation. Компания уже продемонстрировала это на совете директоров, где она единственным голосом заблокировала решение, которое в противном случае было бы единогласным.
Текущая реакция Eclipse Foundation — это продемонстрировать успех и спасти хотя бы часть тех ценностей, которые были разрекламированы в рамках кампании торговой марки Jakarta. Но какой ценой? Для чего сохранять торговую марку того, что стало пустым остовом? Теперь это больше не наследник Java EE как глобального стандарта, это просто какой-то фреймворк, сделанный какой-то организацией и пользователи скоро это поймут и сделают выводы. На данный момент планы сфокусированы на переименовании всего как можно скорее. Но кто в действительности запрыгнет на этот поезд, если это повлечет изменения во всех существующих приложениях? Майк Милинкович из Eclipse все ещё видит светлое будущее впереди. Для меня стакан не полон наполовину: сегодня он развалился на части. Это день, когда Oracle убила Java EE.
Комментарии (111)
Akela_wolf
08.05.2019 08:56Для тех кто не в курсе хитросплетений, можно ликбез — какое отношение Java EE имеет к Eclipse и что теперь грозит собственно Eclipse IDE?
phillennium
08.05.2019 09:44+3Под Eclipse в тексте подразумевается не Eclipse IDE, а организация Eclipse Foundation (которая занимается и этой IDE, и много чем ещё — в частности, вот Java EE должна была перейти от Oracle туда как Jakarta EE). Думаю, если только организация не прекратит своё существование, то IDE особо ничего не грозит, это разные истории.
olegchir
08.05.2019 16:55+1Foundation — это ведь значит не только права, но и деньги? Я про что, кто платит разработчикам Eclipse IDE? Если Foundation составляет какую-то заметную долю в их зарплатах, это еще как ударит
HSerg
09.05.2019 03:22Eclipse 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).
Anton23
08.05.2019 09:45-1Eclipse IDE — ничего. Eclipse Foundation — «опенсоурс» команда, которая поддерживает многое ПО в области Java, например Eclipse IDE или сервер Glassfish. Java EE — Oracle хотела передать Eclipse Foundation поддержку JEE(как когда-то — Glassfush), но переговоры провалились.
bestie
08.05.2019 12:25Eclipse IDE ничего не должно грозить, ведь речь идет об Enterprise Java, которая относится к корпоративным приложениям, а не к конкретной IDE.
vvm13
08.05.2019 12:26Текст достаточно ясен, хотя была пропущена запятая. «В Oracle потребовали, чтобы продукты, распространяемые Eclipse Foundation (такие, как Eclipse IDE) были укомплектованы JRE, сертифицированными только Oracle или ее лицензиатами — никаких сертификатов других вендоров или несертифицированных сред выполнения.». То бишь, Eclipse IDE выбран лишь в качестве примера.
«Следовательно, это было не просто неприемлемо, было просто невозможно согласится с условиями Oracle, так что переговоры в той или иной мере полностью провалились.». Следовательно, Eclipse IDE ничего не грозит.
mayorovp
08.05.2019 09:42-4Погодите, так это что получается, Java EE оказалась такой же проприетарщиной как и .NET Framework?
Или не всё так плохо, и нас просто запугивают?
Anton23
08.05.2019 09:46+10Нет, не такой же. Но и .NET уже не проприетарщина вроде как.
kekekeks
08.05.2019 10:52+10.NET Framework — проприетарщина. Но его и закопали уже по сути, новых фич не будет, поддержки C# 8 не будет, теперь только опенсурсный неткор и моно в тандеме.
iluxa1810
08.05.2019 14:34+2А можно пруфы на счет отсутствия в .NET Framework поддержки C# 8? Там же в основном синтаксический сахар со стороны компилятора.
Например, я могу собрать под .NET Framework 4.0, используя те языковые фичи, которых не было, когда он вышел.(async/await исключение).mayorovp
08.05.2019 15:37Там появилась возможность добавлять в методы интерфейсов реализацию (т.н. default-методы), притом заявляется возможность использования этой фичи для обеспечения обратной совместимости (например, чтобы наконец-то унаследовать
ICollection<>отIReadOnlyCollection<>). Без поддержки рантайма такого сделать нельзя.
kekekeks
08.05.2019 15:57Для default interface methods нужна поддержка со стороны CLR, которой в legacy фреймворке нет.
Для нормальной работы со спанами нужна поддержка со стороны CLR и наборы перегрузок в тех же стримах, которых в legacy фреймворке нет.
Собственно, процесс слома совместимости новых фич C# с legacy фреймворком уже пошёл и останавливаться не собирается.
А async/await, да, я даже на .NET 2.0 заводил.
mayorovp
08.05.2019 09:44+2Ещё вопрос. Вроде же был прецедент, согласно которому API не подлежат копирайту. Так зачем в таком случае менять имя пакета?
Shtucer
08.05.2019 10:00Но тут речь-то уже не об API, а об исходниках конкретной реализации этого API.
mayorovp
08.05.2019 10:09+1Исходники в любом случае придётся написать новые, раз уж старые были закрытыми, это очевидно. Проблема вот в чём:
Если он будет модифицирован, то он должен быть переименован — [...] так и имя пакета (как javax.*), это означает, что существующие приложения не заработают на обновленной платформе без перекомпиляции после интенсивного рефакторинга.
egordeev
08.05.2019 09:59+7есть сомнения, что конец Java EE может быть даже не в этом, а в том, что .NET Core уже активно развивается:
devblogs.microsoft.com/dotnet/introducing-net-5iluxa1810
08.05.2019 14:36+1Интересные изменения, особенно, что можно использовать Java из .NET
mayorovp
08.05.2019 15:39Так давно уже можно было, см. проект IKVM.NET. Я так Apache FOP использовал для генерации PDF, и с IBM WebSphere MQ тоже через JMS работать проще чем через "родной" драйвер.
Ещё Saxon под .NET "реализован" как обертка над java-библиотекой.
kekekeks
08.05.2019 16:01+1Там имеется ввиду адаптация Mono-вского моста к JNI используемого в Xamarin.Android. Теперь и на десктопе обещают вроде как.
sergey-gornostaev
08.05.2019 10:22+19Я так и знал, что кто-нибудь переведёт именно эту статью с кричащим заголовком и начнётся паника. Лучше бы перевели Jakarta EE: A New Hope.
Если кратко и по сути о происходящем:
- 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 в очередной раз идёт трудным путём, но к ещё более светлому будущему.valis
08.05.2019 12:36+2Согласен. Новость так себе, но осадок то останется.
Лично я сложил для себя мнение — Java переживает не лучшие времена и возможно так сложится что эта платформа будет продаваться только вместе с модными оракловыми продуктами типа Oracle Retail, RPAS, OEBS и т.д
Как по мне очень странное поведение оракла на фоне стратегии Microsoft.sergey-gornostaev
08.05.2019 13:22+4Java такие времена проживает с того момента как Oracle купил Sun. Как говорится «Don't make the mistake of anthropomorphizing Larry Ellison». Для платформы такого сложится уже точно не может, Oracle её не контролирует. Самое страшное, что может произойти — фрагментация enterprise-решений, когда одни web-приложения можно будет запустить только на Oracle WebLogic, а другие только на IBM WebSphere. Да и то вряд ли.
UbuRus
08.05.2019 13:25И как потом это самое
jakarta.*запускать на Wildfly? А если запилят новый сервер поверх новых пакетов, кто будет переписывать весь мир наjakarta.*? Если не обеспечат обратную совместимость — это будет смертью JakartaEE.Mishiko
08.05.2019 13:37+1На старом WildFly вероятно будут проблемы, но наверняка WildFly оперативно обновится под новую реальность. Запуск нового ПО на старых версиях WildFly вообще затруднителен, слишком много возникает конфликтов версий библиотек.
sergey-gornostaev
08.05.2019 13:40Новый код надо будет просто писать с использованием пакетов из
jakarta.*, а для запуска старого новым версиям Wildfly и других серверов приложений придётся добавить «режим совместимости», в котором байткод будет подменяться при загрузке классов. Предпоследний пункт как раз об этом. И в статье по ссылке это есть.UbuRus
08.05.2019 13:57Вы же понимаете что этот магический режим совместимости будет источником перформанс пенальти будь то на этапе компиляции, или в рантайме. А с этим у JavaEE и так плохо.
Дальше — больше, кроме самих серверов есть куча других библиотек которые занимаются рефлексией в рантайме, как они будут работать в таком двояком мире большой вопрос (и кто будет переписывать все это под новый мир).
На ровном месте создается огромное количество проблем, сделать это все бесшовно и без багов, да еще так, чтобы работало с легаси — близко к невозможному. Ведь цель номер один это сохранить полную обратную совместимость.
Поэтому для JakartaEE жизненно важно владеть существующими API.
А тот же RedHat (IBM) может себе позволить купить у Oracle необходимые права и не заниматься переименованием ради переименования, и вот у нас уже образовалась фрагментация.
sergey-gornostaev
08.05.2019 14:05Я понимаю, что это костыль и он приведёт к увеличению времени запуска, но 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
slonopotamus
08.05.2019 14:22В результате 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 уже была), а второй вполне себе имплементация.sergey-gornostaev
08.05.2019 14:44а история про джаву и копирайты на API уже была
И закончилась она тем, что постановлением апелляционного суда API могут быть защищены копирайтом. Google и EFF обращались в верховный суд, но безрезультатно. Можете изменять HttpServlet.java, но добавить в пакет новый публичный класс не сможете.slonopotamus
08.05.2019 14:58В статье написано чёрным по белому:
Eclipse Foundation может использовать довольно устаревший код без права модификации
Я утверждаю что это утверждение ложно. Файлы имеют лицензию, разрешающую их изменять и распространять модифицированную версию.
добавить в пакет новый публичный класс не сможете
Откуда вы это взяли? Я не вижу ничего подобного ни в одной из двух статей («Negotiations Failed: How Oracle killed Java EE» и «Jakarta EE: A New Hope»).sergey-gornostaev
08.05.2019 15:15The 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 засудит.slonopotamus
08.05.2019 15:47The 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.
Это всего лишь «в эклипс фаундейшене решили что они будут перекладывать файл в другой пакет когда решили его поменять». Ну хотят перекладывать — пусть перекладывают, имеют право. Но эта цитата не является ответом на вопрос «что запрещает им менять файлы и добавлять новые прям в те же пакеты в которых они лежат».
sergey-gornostaev
08.05.2019 15:18Я утверждаю что это утверждение ложно
То есть вы считаете, что в статье написана неправда, а множество серьёзных в мире Java людей врут или поддались беспочвенной панике?slonopotamus
08.05.2019 15:41Ещё раз. В файлах, которые я привёл в пример, недвусмысленно указана лицензия, разрешающая их модификацию и распространение как исходных, так и модифицированных версий.
На чём основаны утверждения «модифицировать нельзя» или «нельзя добавлять новые файлы в тот же пакет» мне неизвестно.
Возможно эти серьёзные люди (и вы в том числе) знают что-то ещё. Ну так ответьте, откуда у вас информация про запрет на добавление новых файлов в существующие javax пакеты.sergey-gornostaev
08.05.2019 15:49-1Я ориентируюсь на информацию из статей. Цитаты я вам привёл. Впрочем, из этих цитат следует, что и код изменять тоже нельзя. Как это соотносится с действующими на этот код лицензиями я не знаю.
UbuRus
08.05.2019 16:24+1Вы можете менять и распространять код как написано в лицензии, до тех пор пока не нарушаете товарный знак "Java", который принадлежит Oracle. Использование пакетов
javax.*попадает под trademark, отсюда и проблемы.slonopotamus
08.05.2019 16:39Я вот сейчас возьму и нажму «Fork» на гитхабовом репозитории с javax.*. Начал ли я при этом «использовать пакеты javax.*» и тем самым нарушать trademark? А если я после этого поменял один из файлов и закоммитил изменения, я уже начал «использовать пакеты javax.*»? Если на оба вопроса ответ «нет», то чего ещё надо эклипсу? Ну не называйте это словом JavaEE и всё.
UbuRus
08.05.2019 16:49В статье, да и по логике — изменение будет производным продуктом, и будет нарушать Java трейдмарк.
- Запрещено ли это в GPL, а в лицензии которая на большинстве ораклового кода: https://oss.oracle.com/licenses/CDDL+GPL-1.1?
- В любом случае не понимаю до чего вы докапываетесь этим реплаем, скажите уже открыто.
olegchir
08.05.2019 16:57+2> Файлы имеют лицензию, разрешающую их изменять и распространять модифицированную версию.
JDK распространяется под GPLv2, которая не имеет пункта про передачу патентов.
То есть, за создание производной работы тебя не засудят, да. Засудят за нарушение патентов.
Эта проблема решена в GPLv3, но переходить на неё Оракл, по очевидным причинам, не станет
vsb
08.05.2019 17:01Кроме лицензии есть ещё торговые марки. Возможно дело в этом.
// Я всё жду, когда Oracle начнёт монетизировать торговую марку JavaScript :)
Throwable
08.05.2019 10:35+1Меня беспокоит затронет ли это уже существующие компоненты JavaEE? Например у Eclipse Foundation была и есть годная имплементация JPA/JAXB под названием EclipseLink/MOXy...
sergey-gornostaev
08.05.2019 10:40Это не коснётся ни одной из реализаций Java EE 8 или более ранних версий. Разборки связаны только с желанием Oracle сохранять право вето в решениях о направлении развития новых версий стандартов.
ExplosiveZ
08.05.2019 11:46+1Какой желтушный заголовок. Достаточно будет `java.` в начале импортов заменить на `jakarta.*` и всё.
AstarothAst
08.05.2019 13:13+9Достаточно будет `java.` в начале импортов заменить на `jakarta.*` и всё.
Не видим никаких сложностей, говорили они! В чем проблема, говорили они…
olegchir
08.05.2019 16:59У тебя не всегда есть исходники софта. Их могли не передать (особенно если софт покупной). Их могли потерять. В конце концов, после пересборки может немного поменяться поведение, а те люди, которые это написали — уже умерли или отказываются иметь с тобой дела. И это если не касаться такой грязной и мрачной темы как сертификация в сцпецслужбах России. Удачи поменять что-то в таком софте.
Более того, если у тебя хэлловорлд — это не проблема никакая, поменять в двух местах. Если у тебя десять тысяч классов, надерганных на пару сотен микросервисов, то тебе придётся остановить всю свою инфраструктуру хотя бы чтобы обновиться. И это если всё пойдёт гладко.
vokzamag
08.05.2019 21:42Теоретически.
На практике, в любом более-менее сложном Java-фрэймворке под капотом стопицот хрупких костылей на рефлексии. Никогда не угадаешь, какой из них стрельнёт и когда.
Mishiko
08.05.2019 13:26+2При принятии решения об использовании того или иного ПО в проектах, буду избегать коммерческого ПО от Oracle (в первую очередь БД Oracle) заменяя альтернативным. Очень уж у них карма плохая.
mkovalevskyi
08.05.2019 18:32и какие у вас альтернативы, особенно их хардварной реализации?
HSerg
09.05.2019 03:34IBM?
mkovalevskyi
09.05.2019 17:09Если вы о DB2 — то оно чуток немного совсем более медленное чем оракл, особенно в его хардварном варианте.
Особенно в крайних оракла версиях, где он гордо заявляет что вам больше не нужны DBA мы все автоматом фиксить на лету будем, вам достаточно просто намекнуть какие данные вам нужны, и заплатить 100500 денег ;)
vics001
08.05.2019 13:52+1Из статьи ничего непонятно о сути конфликта.
Было много реализаций Java EE, скорее всего были open source с приемлимой для Eclipse лицензии. Как тогда IBM, Sun делали разные реализации? Почему Eclipse не может пилить свой open-source с теми же пакетами? Если они используют имя Jakarta, как торговая марка на Java может помешать?sergey-gornostaev
08.05.2019 14:28+2Раньше Oracle единолично владела всеми правами на Java EE. Только они могли решать, что будет в следующей версии стандарта, а что не будет, только они решали, какие реализации соответствуют стандарту, а какие нет, и т.п. Такая власть одной коммерческой компании над стандартами приводила к существенным рискам использования другими компаниями реализаций этих стандартов. Суть передачи прав на стандарты в Eclipse Foundation была как раз в том, чтобы они развивались и управлялись общественной организацией. А суть конфликта в том, что Oracle любит переобуваться на лету и в последний момент решили не отдавать права полностью.
YuryB
08.05.2019 17:25-1как показывает практика весь этот вой из ничего. могу вкратце даже не вникая дать прогноз: разберутся и всё будет хорошо, хотя я spring ни на что бы не променял
sergey-gornostaev
08.05.2019 17:39+1Так Spring тоже зависит от Java EE. У Spring MVC под капотом стандарт сервлетов, у Spring Data под капотом JPA, и т.д. и т.п. Но я тоже думаю, проблема так или иначе решится. Возможно даже, что Oracle в конце концов сдастся.
HSerg
09.05.2019 03:48Помните, как получилось у Oracle с OpenOffice? Oracle дождались фактической смерти проекта, а хладный трупик потом спрятали в Apache Foundation. Впрочем, тогда всё обошлось, может и у нас получится.
saag
А какова теперь судьба Java SE? И вообще судьба Андроида?
Shtucer
Во-первых, у них своя реализация.
Во-вторых, Kotlin (тут я не уверен, что это что-то значит в данном контексте)
В-третьих, Fuchsia OS, но это не точно.
valis
Есть еще Flutter. Как по мне сильнейший козырь и удар ниже пояса по Java.
androidovshchik
Fuchsia OS и flutter это одна стихия, если можно сказать
namikiri
Флаттер ненативен.
androidovshchik
Он нативен
И все это работает через Android NDK
Здесь написано подробно, как работает
namikiri
Спасибо за ссылку, извиняюсь.
Acuna
Удар ударом, только существует множество компаний, занимающиеся разработкой приложений на заказ и до сих пор набирающих разрабов на Java. Переход на Флаттер потребует большого количества времени и денег, ибо разные языки совершенно (Dart, на котором написан Flutter — это почти JS). Это все-равно что сказать нафиг Java вообще нужна, есть же С++. Мне на собеседованиях так и отвечали на мой вопрос, мол, на Dart не планируем переходить в ближайшее время, ибо очень экстремально, и это даже ни смотря на то, что для Android и для iOS все вынуждены иметь две отдельные команды разрабов и тестеров.
cVoronin
Вот тут хз. Как и в случае Java, основной интерес ведь представляет не сам язык, а инфраструктура, которая выросла вокруг этого языка. Если не было бы J2EE, Spring, Hibernate (тут продолжаем список) — кому интересна была бы Java? Мало кому.
Насчёт Flutter, насколько я вижу, сейчас ситуация упирается как раз в его окружение.
Если для андроида + Java/Kotlin у меня есть куча инструментов — Dagger, Realm, Architecture Components, Retrofit, Rx и реально куча всего разного, без чего полноценные приложения делать сложно, то вот для Flutter…
fRoStBiT
К Java SE всё это не имеет никакого отношения, там всё относительно хорошо.
А Android очень слабо привязан к Java как платформе — своя VM, свой байткод, даже в качестве языка уже больше используется Kotlin.
faoriu
Не путайте хайп и продакшн: в индексе TIOBE за 2019 год Kotlin на 39м месте — ниже Lisp, Logo, Dart и тд. Для сравнения Swift — на 18м месте.
fRoStBiT
faoriu
Одно дело писать статьи «как я слепил Hello, World на Kotlin», другое — продакшн.
Для сравнения я и привёл Swift — который аналогично заявляется как замена ObjC.
nerumb
Цитата с 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 дела обстоят тоже неплохо, и много всего уже в проде.
faoriu
“The most loved and fastest growing blah-blah-blah” — это и есть хайп. Статистика говорит о другом. Я ведь специально проверил, как там у Kotlin дела за последний год, прежде чем комментировать, так что тратить зря время на поиск опровержений не советую.
Впрочем эти данные можно трактовать и так: нативная разработка под Android менее популярна, чем разработка под COBOL и LISP.
phillennium
TIOBE ориентируется на поисковые запросы, а запросы могут быть связаны с теми же статьями, которые вы сами и отметаете как хайп.
Смотрите тогда лучше, например, свежие результаты опроса от Stack Overflow, где спрашивают как раз о том, что реально используется (спойлер: там Kotlin и Swift идут почти ноздря в ноздрю).
А ещё лучше — попросту спросите у любого реального Android-разработчика, что с адопшеном Kotlin в Android-разработке. Он ответит вам, что доля уже громадная и продолжает расти.
faoriu
Я что-то не наблюдаю хайпа вокруг COBOL или Objective-C. Тем не менее в TIOBE они существенно выше Kotlin.
Причём оба — ноздря в ноздрю с Ruby, VBA и Assembly. Очень «информативно». В долгосрочной перспективе такая фигня с двуязычием сама себя изживает, поскольку даёт повод собеседующим умничать не про один язык, а про два. В итоге всё равно побеждает самый «официальный» и самый привычный язык, ну или все просто переползают на какой-нибудь Xamarin.
Судя по комментариям — мнения противоречивы. Когда в прошлом году Хабр бомбили статьями о Kotlin — многие начали вообще открыто плеваться.
phillennium
Комментарии вида «использую Java поверх ядра на С++», вероятно, пишут бэкендеры. Ещё раз: спросите любого Android-разработчика. Всем, кто видит ситуацию в Android-разработке, очевидно, что язык там принят настолько массово и бесповоротно, что теперь двуязычие может там «изжить само себя» только в виде отказа от Java.
xfaetas
А много ли Kotlin-only вакансий разработчиков? Судя по MonsterJob — Kotlin вообще упоминается примерно в 20% вакансий по разработке под Android. Допускаю, что локально в России популярность Kotlin выше по понятным причинам.
phillennium
Kotlin-only вакансий пока что немного, потому что типичный сценарий миграции такой: новый код в приложении пишут на Kotlin, но написанный ранее за годы джавовый не пытаются сразу весь переписать, а неспешно заменяют по мере развития. Соответственно, в таком случае сталкиваться с джавовым кодом приходится и в описание вакансии Java попадает, но уже как легаси.
dj1m
именно так происходит не только в android разработке. А прям в самом кровавом интерпрайзе. Микросервисы, докер, все дела. Новенькое пишут сразу на котлине, старое переписывают, когда руки дотягиваются.
phillennium
А про MonsterJob — как именно вы высчитали 20%? Не вижу там лёгкого способа получить полную статистику, попробовал просто вбить в поиск «Android» и кликнуть в первые пять вылезших вакансий. Котлин оказался упомянут в четырёх из пяти.
WraithOW
Пишу вам из продакшена — два года на Котлине. Судя по опыту собеседований в этом году, очень многие либо на него перешли, либо в процессе.
xfaetas
На данный момент кроме вас из продакшна отписался только один человек — из примерно 11 тыс. просмотревших статью.
UPD: 3 человека из 12 тыс.
dumistoklus
И ни одного, кто бы отписался что использует Java на продакшене. По вашей логике у нас есть победитель
xfaetas
Вопрос про Java не стоял.
VioletGiraffe
Пишу из продакшена, использую Java поверх ядра на С++ :) На Kotlin переходить никакого желания не испытываю, не вижу смысла.
vics001
У нас 10% Котлин, 80% Java, 10% C++. Очевидно смешивать языки никто не будет, значит и Котлин и Java продолжат расти со своей скоростью, наверное соотношение немного поменяется через лет 5, но не раньше.
zagayevskiy
Ни разу не очевидно. Мы мешаем джаву и котлин, и живем отлично. Джаву постепенно выкидываем.
vics001
Вы занимаетесь переписыванием, но если ваш процесс переписывания растянется на лет 5-7, то успехов в такой мешанине.
zagayevskiy
Пфф, Cmd+Alt+Shift+K. Конвертер вполне нормально работает, за ним чуть причесать. Это раз. Второе, если код меняется не сильно, то можно и на джаве написать, хоть это и очень неприятно после котлина. Третье, джава и котлин интероперабельны, так что весь новый код на котлине, даже если он как-то использует старый джавовый. Поменьше категоричности, вы тут не пуп Земли. Другие люди живут по-другому.
MicroNovaX
К сожалению плохо работает с большими классами (никак, крашится).
Проверялось с пол года назад, не уверен, что ситуация изменилась.
androidovshchik
В таком случае, надо лучше знать kotlin, потому что конвертер не знает многие аспекты языка/технологий
yarric
Посмотрите профиль — zagayevskiy в Яндексе работает. Успехи таких, кхм-кхм, контор зависят не от разработки, а от других вещей.
zagayevskiy
И от чего же?
nerumb
Уже достаточно много компаний, кто используют его в проде. Посмотрите на том же hh.ru. У нас в том числе он используется.
faoriu
Если ваш кадровик пишет о Kotlin в описаниях вакансий — сразу появляются кандидаты с многолетним опытом энтерпрайзной разработки под ним.
cVoronin
Для меня реально интересно было бы посмотреть на человека, который сейчас начинал бы писать новый проект на андроиде, используя Java, а не Котлин.
Сами на Котлине, в проде, причём давно.
xfaetas
Судя по тому, что на MonsterJob 4 из 5 вакансий Android Developer не упоминают Kotlin — таких полно. Вообще «убийцы» Java и до Kotlin были — Ceylon, Clojure, Groovy… Поддержка Google мало что значит, с учётом того, что в Fuchsia Kotlin они до сих пор не добавили (зато добавили Go) — видимо в будущем планируют переехать на полностью нативное окружение.
cVoronin
Поживём-увидим, но для андроид-разработки сейчас не использовать Котлин — можно, но не нужно. Ещё раз уточню, что одна из основных причин — это доступность фишек, которые на андроид-платформе недоступны в силу ограниченной поддержки фишек из новых версий Java.
Хочешь, например, Optional? А фиг тебе, только начиная с API 24.
Ну и сам язык просто приятен.
А из альтернатив для больших систем — так ведь Scala есть, и Тинькофф, и Сбер на ней много что делают, и не плачут, кстати.
stgunholy
Не только под Android… После того как Spring Boot стал без костылей поддерживать Котлин, переперли все 16 микросервисов достаточно крупного приложения на него.
Tomok
Это уже не похоже на хайп, Kotlin рекомендуется как основной язык для Android-разработки самим гуглом: https://android-developers.googleblog.com/2019/05/google-io-2019-empowering-developers-to-build-experiences-on-Android-Play.html
zagayevskiy
TIOBE очень консервативный индекс. Swift это выброс, тк Apple просто заставила всех перейти. Люди пишут в проде на Котлине.
cVoronin
Куча приложений в проде, написанных на Котлине — часть из них попала в прод ещё до того, как Гугл объявил о поддержке Котлина.
Не знаю, как на других платформах (энтерпрайз, веб и проч.), но на андроиде это реальный мейнстрим. По куче разных причин, основная из которых — отсутствие плюшек из новых версий Java для андроид-девелоперов.
faoriu
Это, видимо, российская специфика — судя по MonsterJob в США о Kotlin мало кто знает.
Kirhgoff
Работаю в Австралии, переписали все мобильные приложения на Котлин
phillennium
Коротко о том, как в США «мало кто знает о 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.
ma1uta
У Java SE отдельная судьба в виде OpenJDK, и там у Oracle уже нет такой власти.
Андроид мигрирует на kotlin и dart (flutter).
androidovshchik
Flutter это скорее переходник между android и fuchsia