Так вот, буквально пару дней назад Марк в OpenJDK'шном мэйл-листе jdk9-dev опубликовал письмо о предполагаемом переносе срока выхода Java 9 / JDK 9 с сентября 2016 года на март 2017-го.
Основные тезисы таковы:
- Jigsaw (модули) — ключевой подпроект Java 9. Он очень важный и очень большой
- Разработчики платформы Java добились серьезных успехов на пути его реализации
- Согласно текущему расписанию, важный майлстоун, Feature Complete, к которому все фичи вместе с соответствующими юнит-тестами должны быть интегрированы в основной репозиторий, должен состояться уже через неделю, 10 декабря.
- но Jigsaw требует больше времени и к 10 декабря разработчики не успели. Нужно больше времени для того, чтобы получить фидбэк от пользователей ранних билдов.
- Как результат, Марк запрашивает у коммьюнити перенос сроков. Feature Complete он предлагает сдвинуть на пять с половиной месяцев: с 10 декабря 2015 на 25 мая 2016. А General Availability (GA), то есть, дату окончательного релиза, с 22 сентября 2016 года на 23 марта 2017.
Почему я уверен в том, что этот запрос Марка будет удовлетворен сообществом:
- У него неплохая аргументация. Лучше качественная фича, чем некачественная
- У него огромный вес в коммьюнити и в Java Organization в Oracle. Все-таки Главный Архитектор.
- Jigsaw, в отличие от лямбд, нужен далеко не всем. В коммьюнити до сих пор нет единого мнения насчет того, насколько вообще с модульностью стоит заморачиваться. Некоторые (не без основания) считают, что Compact Profiles вполне достаточно с точки зрения минимизации дискового пространства, а платить такую цену (столько лет и столько людей, постоянные переносы сроков) за инкапсуляцию и другие плюшки Jigsaw — это реально перебор.
В принципе после истории с многократным переносом Java 7 и переносом Java 8 никакой неожиданности в текущем запросе Марка на перенос не было. Так что история повторяется. Ждем очередных постов про поезда в блоге Марка.
Почему поезда? Марк очень любит эту метафору и постоянно использует ее в своем блоге. То он пишет про то, что какая-то фича (aka Jigsaw) не успевает на поезд под названием «Java 8». То он пишет про то, что релиз Java — это как несущийся поезд и что его не остановить за секунду (и поэтому мы не будем вот прямо сейчас резко прерывать на полном ходу разработку, а возьмем еще полгода на то, чтобы все аккуратно доделать, постепенно снижая обороты, то есть, будем тормозить поезд не экстренно, а размеренно).
Предыдущие поезда про Java 8 и Jigsaw: раз, два, три.
Такие вот
Комментарии (36)
xhumanoid
03.12.2015 15:03+2>> Почему я уверен в том, что этот запрос Марка будет удовлетворен сообществом:
2 пункта в подтверждение, но вот 3й как раз в тему почему некоторые в сообществе считают, что может лучше уже и на 10ку скинуть модули, так как их первоначально вообще в 7ку обещали и где гарантия, что из-за них в мае не придется опять переносить еще на 6 месяцев релиз
23derevo
03.12.2015 15:59+2Марк пытается впихнуть модули в Java уже много лет. Ходят слухи, что если они не успеют к маю, то это будет конец карьеры Марка Рейнхольда в Oracle.
EaE
03.12.2015 15:04+2Да уже пофиг. Полугодом раньше, полугодом позже, когда Java отстает от потребностей индустрии лет на пять — не смертельно.
С другой стороны, альтернативы толком нет.
Fafnir
03.12.2015 15:57Scala?
EaE
03.12.2015 16:04+3Ну вот это рефлекторная реакция, мол Scala. А на самом деле технологический стек там жестокий, sbt — один сплошной анекдот, сама скала больше интеллектуальная игрушка для ее создателей, чем профессиональный инструмент. Не думаю, что она победит, хотя через пять лет видно будет. На мой вкус, Scala хорошо взлетит на задачах метапрограммирования, но их гораздо меньше, чем задач общего плана.
Fafnir
03.12.2015 16:40+2Не без проблем, конечно, но полет нормальный. Sbt не быстрый, но свое дело делает, это он раньше был совсем отсталым. Scala сам по себе уже не новый язык, на нем есть большие проекты, например, Apache Spark.
Twitter, опять же, давно юзает его в Production и выпустил много open-source инструментов.
Java уже давно двигается по инерции, как, впрочем, и сам Oracle, который все больше катится в забвение.EaE
03.12.2015 16:58+1У меня вопрос-оффтопик, а у sbt вообще есть смысл? Ну, я имею в виду, он изначально решал какие-то задачи, которых не решали иные сборщики, или просто «мы можем писать мета-язычки на скале, поэтому давайте напишем мета-язычок для сборки, просто потому что можем»?
xhumanoid
03.12.2015 17:32+1как минимум он решает проблему, что для зависимостей с разными версиями скалы нужны разные версии билдов
зависимость собранная для скалы 2.10 не взлетит если у вас проект на 2.11 и тд
то есть главные смысл в автоматическом мэтчинге нужной версии скалы
но по мне это пример костыля, который пытается маскировать основную проблему «между версиями плывет байткод»
ну а второй момент политический: зачем нам мэйвен если мы можем и сборщик тоже использовать со скалой, в итоге scala everywhere
solver
03.12.2015 18:24+1А почему сразу мавен то в пример?
Gradle отличный сборщик.
Как по мне, так лучше бы они вложились в развитие плагина scala для него.
Ибо вот это вот «scala everywhere, но с костылями и головняком» — реально нафиг никому не уперлось кроме Typesafe.xhumanoid
03.12.2015 20:16+1ну давайте быть честными, в момент становления sbt тот же gradle был не намного лучше
так как до версии 1.0 в нем очень часто после очередного milestone отваливался билд, пока не снесешь кеш в домашней директории на сборке ошибка писалась совсем не интуитивно понятная, а после сноса кеша резко все продолжало работать.
поэтому и развивались они параллельно, а менять сейчас смысла нету, так как свою задачу в данный момент делают оба
p.s. я уже не раз имел спор с билд инженерами чем вам (maven/gradle/sbt) не угодил, а выбрали (maven/gradle/sbt), ведь я могу с помощью него сделать все тоже, что вы делаете на своем. в общем это холивар =) причем очень жестокий. в любой системе можно сделать как вменяемый билд скрипт, так и такой что никто его не осилит
xhumanoid
03.12.2015 17:28+5>> Не без проблем, конечно, но полет нормальный
>> на нем есть большие проекты, например, Apache Spark
тогда может нам еще расскажите про совместимость между версиями?
Spark до сих пор используют scala 2.10.4, так как переехать на 2.11 свежее требует достаточно много ресурсов.
а дальше будет 2.12 которая вроде как обещают совместимость с 2.11, но хз-хз, так как работу с лямбдами полностью переделали
а после 2.13 в которой collections полностью обещают переделать, в итоге нету вообще никакой гарантии что даже на уровне source code будет работать.
или может расскажите про play?
если у вас проект на play со смесью java и scala и вам нужно смигрировать с play 2.1 на последние версии java, то резко оказывается что scala 2.9 не переваривает байткод от восьмерки, нужно обновить скалу до свежей версии,
обновляем скалу и нарываемся на второй пункт — 2.1 собран только под scala 2.9, под свежую скалу нету его, следовательно просто java обновить вы не можете, нужно обновлять и скала и сам плей
плей между версиями меняет api следовательно опять секс =)
итого: смена language level с 7 на 8 для scala части выливается в обновили scala core / all frameworks / fix all changed api
вообще если подойти более обще, то оказывается, что тот же typesafe пытается как-то объяснить Одерскому, что меняя api и ломая байткод каждую версию в серьезные проекты залезть сложно, на что получает закономерный ответ «нужно больше фич, а поддержка и совместимость это вторично»Fafnir
03.12.2015 17:56Spark до сих пор используют scala 2.10.4, так как переехать на 2.11 свежее требует достаточно много ресурсов.
А в чем проблема? Spark можно собрать под 2.11 начиная с версии 1.2 или вроде того.
а после 2.13 в которой collections полностью обещают переделать
Поживем — увидим, но это точно не Rust, так что все не должно сломаться.
если у вас проект на play со смесью java и scala и вам нужно смигрировать с play 2.1 на последние версии java
Выстрелить себе в ногу можно разными способами. Увидев Play 2 после Play 1, уже можно было понять, что эти парни — маньяки.xhumanoid
03.12.2015 18:18+4>> Spark можно собрать под 2.11 начиная с версии 1.2 или вроде того.
вот именно, поэтому найти в природе 2.11 немного проблематично, даже на офф сайте
«Note: Scala 2.11 users should download the Spark source package and build with Scala 2.11 support.»
а просто взять и использовать нельзя…
>> так что все не должно сломаться.
ага, сломается только половина
я не противник скалы, сам регулярно её использую для прототипов и небольших проектов, но начинать серьезный проект который нужно будет поддерживать годами я морально не готов, так как все эти изменения немножко напрягают. сам подход bytecode мы ломаем постоянно, а source level «всего» через раз отпугивают от scala очень много компаний. тут компании задумываются над тем, что обновлять java каждые 18 месяцев это слишком часто, давайте нам релиз цикл хотя бы 2 года, а вы со scala предлагаете каждые 2 года заставлять их переписывать код.
p.s. минутка юмора: очередной раз перечитывая www.scala-lang.org/api/2.11.4/index.html#scala.collection.concurrent.Map и все его варианты с + ++: --= /: :\ ++= складывается впечатление, что Одерски пытался написать обфускатор, но люди обозвали это языком и пытаются кодить =)
ppopoff
04.12.2015 14:45По поводу обфускации и операторов /: :\.
В своем докладе Scala with style Мартин сам признал это ошибкой.
ppopoff
03.12.2015 23:26+2Вас никто не заставляет использовать sbt. Можете использовать maven или gradle, если вам так удобнее. Многие scala-разработчики используют gradle и ничего в этом зазорного нет.
EaE
04.12.2015 13:39Заставляют, конечно, иначе стал бы я тут пыхтеть.
ppopoff
04.12.2015 14:32+1Вас заставляют коллеги, или разработчики фреймворков?
В случае с фреймворками все не так плохо.
webmascon
04.12.2015 15:26+1Ну задержат так задержат. Нам бы в продакшене с Java 6 на Java 7 перейти бы, а потом на Java 8. А до Java 9 мы еще не скооро доберемся
gurinderu
04.12.2015 18:34Что за компания если не секрет? Как вы вообще в проде держите, то, что не сапортится уже долгое время?
leventov
05.12.2015 08:48+2Android это еще во всю Java 6, Google отказался от поддержки Java 5 (в публичных библиотеках, что может быть знаком, что и у себя на проде) только полтора года назад. Кое-где может быть все существенно хуже. Волкер Симонс говорил, что SAP будет поддерживать Java 1.4 (!) еще как минимум 10 лет (!!!)
pyatigil
06.12.2015 01:49+1
leventov
05.12.2015 08:54Впечатление, что сделать релиз Java физически нельзя быстрее чем за 3 года. Это длина цикла разработки таких масштабных изменений, как лямбды, модули, value типы (на 10)
LastDragon
05.12.2015 10:05Как стороннему наблюдателю мне кажется что проблема исключительно в разработчиках и/или менеджменте — тот же C# уже длительное время спокойно развивается семимильными шагами (хотя после развала sun вроде немного получше стало?).
23derevo
13.12.2015 19:12Я думаю, что основная причина — рост сложности. База исходников растет, декомпозиция слабая, поэтому можно говорить про квадратичный рост сложности.
gurinderu
Действительно печальная новость. День омрачён.