Pull to refresh

Comments 13

Очень рискованный шаг с ускоренным циклом релизов, я бы даже сказал пугающий.
Вот то что они решили OracleJDK фактически превратить в OpenJDK радует. А вообще складывается такое чувство что Oracle уже устал от java и хочет потихоньку вытолкнуть его полностью на плечи сообщества, нагнуть гугл на отчисления не вышло вот наверное и думают как аккуратно сбагрить все это добро.

А я как раз очень оптимистично настроен. При наличии LTS версий шаг с частыми релизами не такой пугающий, я бы сказал. Скорее было наоборот, грустно было читать список планируемых фич и понимать, что они лет через 10 попадут в релиз, не меньше.


Конечно, тут есть две опасности — потерять совместимость и стабильность или пойти по пути "теперь можно все". Надеюсь, что JCP EG все же сохранит здравый смысл!

Проблема в том что jvm плохо предрасположен к установке пары версий одновременно. Т.е. ситуация:
В системе есть некоторый софт который работает только на LTS релизе, тут появляется необходимость поставить другую софтину которая хочет новую фичи. Заводить одновременно 2 разных jvm достаточно проблематично, можно но проблемно по крайней мере на мой взгляд.
Другая ситуация:
Вы пишите софтину и понадобилась некая фича которая есть только в feature ветке, вы на нее полагаетесь, юзаете. Тут проходит полгода, написана гора кода и выходит новый релиз в котором эта фича объявлена deprecated и на ее место выкачена новая реализация, вы тратите пару месяцев на переписывание кода, пишите еще тонну кода и выходить новый релиз. В новом feature релизе старую реализация вырезали на корню, ее смену проапгредили сломав совместимость с изначальной версией. Чтобы понять всю боль можно посмотреть на javaFX в которой между v2 и v8 огромная пропасть несовместимости api.
Вот еще никак не засяду разобраться с jigsaw т.к. он чисто своим описанием меня уже напряг. И честно признаться лично для меня, с учетом что программирование это хобби, jigsaw может оказаться точкой отсчета чтобы уползти в изучение mono\С#. Такое же отношение у меня и к var\val, пробовал читать код с их использование и как будто попал в кошмар из месева разного кода.

Насчет разных версий — видимо поэтому Марк подчеркнул, что для облегчения использования разных версий помогут контейнеры. Да и в целом, две JDK вполне себе живут рядом.


Чтобы фичу объявили deprecated через полгода в мире Java… ну не знаю, такое теоретически, конечно, может случится, но это как страховка от похищений пришельцами.


А если вам кажется сложным jigsaw и не нравятся var / val то лучше смотреть не на C# где все это уже в каком-то виде есть, а иногда в более продвинутом (читай — сложном) виде, а какой-нибудь Go.

Живут, но приходится приложить усилия чтобы так было.

Посмотрим что будет, я так же относился к лямбдам а сейчас ничего так, прижился хотя встречая лямбды в чужом коде глаз спотыкается на них и заставляет разбираться что тут черт возьми творится.
2 версии, к примеру 6 и 7 или 7 и 8 работали нормально. А вот три — уже глюки.
Вот у меня на работе интересный зверопарк из за этого вырос. Есть hiPath который конфигурируется в браузере через аплеты и требует java 6 ранних версий. Есть ибэпы отечественные и тоже через браузер с аплетами и только на java 7. А есть еще софтинка для работы с особыми логами которая уже на java 8. Все это изначально крутилось на 3х разных древних машинках, затем сдохла та что с java 6. Скрипя мозгами удалось завести 6 яву рядом с 7й. Предсказуемо сдохла тачка с 8й явой и тут разродились на новую тачку под все это добро. На новой долго и упорно пытался сколхозить помесь но работало это ужасно. В конечном счете есть крутая тачка в которой установлено 3 виртуалки. Весь фокус кстати отчасти из за deprecated\обновленных методов и изменений в политике безопасности самой явы. Исходников софта естественно нет, но даже добравшись до сути проблемных мест сделать ничего нельзя т.к. аплеты зашиты в железки и при работе тонны проверок на подлинность как со стороны аплета самого себя так и со стороны железки которая при коннекте аплета к ней проверяет аплет.
Вообще тема с аплетами почемуто сопровождалась всегда дикой болью. Может просто я невезучий.

Думаю, это актуально только для десктопной Java и апплетов (которые уже не поддерживаются), которое я бы отнес к крайним случаям.


Если же говорить про серверную часть, которой все-таки большинство в мире Java, я вот после предыдущего комментария задумался, что я за уже много лет в индустрии я не видел, что несколько приложений деплоились в общую среду и могли шарить JVM. Обычно это либо контейнер, либо виртуалка, либо выделенная железяка per app. Так что для таких случаев выбор нужной версии Java не проблема.

Меня пугает такой частый релиз, что будет с не Java языками не очень понятно. Они обычно итак отстают от релизов на пару лет.

Ну я думаю, что все это делается с прицелом поубавить количество таких языков. Ибо если все будет внедряться более менее быстро в java, то и куча языкового зачем?

UFO just landed and posted this here

обычно так поступают взрослые и достаточно зрелые продукты

Sign up to leave a comment.

Articles

Change theme settings