Исполнительные комитет JCP (Java Community Process) отклонил (https://jcp.org/en/jsr/results?id=5959) принятие спецификации JSR 376 (https://www.jcp.org/en/jsr/detail?id=376) (Java Platform Module System), в рамках которой развивалось ключевое улучшение платформы Java 9, релиз которой запланирован на 27 июля 2017 года. JSR 376 отражает изменения, подготовленные в рамках проекта Jigsaw (http://openjdk.java.net/projects/jigsaw/), и предлагает принципиально новые для Java средства разбиения программ и JDK на модули.Против добавление в Java средств для разбиения на модули проглосовало 13 из 23 активных участников комитета. Среди проголосовавших против: IBM, Red Hat, Eclipse Foundation, Hewlett Packard Enterprise, SAP и Twitter. Из участников, голосовавших за принятие JSR 376, можно отметить Intel, Fujitsu, Goldman Sachs, Oracle. В течение 30 дней планируется выставить на голосование обновлённый вариант спецификации, в случае одобрения которого ещё удастся выпустить Java 9 в срок.
По мнению сторонников проекта Jigsaw разбиение кода платформы Java на модули упростит создание, сопровождение и распространение больших приложений, позволив избавиться от наблюдаемых в настоящее время проблем с монолитными JAR и распространением наборов классов. Система модулей даст возможность легко выделять функциональность и формировать настраиваемые конфигурации, адаптируемые как для развёртывания на больших серверах, так и на встраиваемой технике. Модульные приложения, построенные на основе модульной платформы Java, потребуют загрузки меньшего объёма данных и позволят достигнуть более высокой производительности за счёт более эффективной оптимизации специфичных для используемой конфигурации модулей.
Основными противниками принятия JSR 376 стали компании IBM и Red Hat. Остальные в основном присоединились к мнению IBM или проголосовали против, так как среди участников совета не был достигнут консенсус и остаются нерешёнными спорные вопросы. Компания IBM проголосовала против, так как считает (http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2...), что спецификация ещё не готова для утверждения и требует (https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3...) дополнительной доработки.Компания Red Hat полагает (https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...), что внедрение Jigsaw приведёт к нарушению работы уже существующих приложений и, как следствие, инициирует раскол экосистемы и фрагментацию сообщества: с одной стороны окажутся системы на базе Jigsaw, в с другой все остальные решения, включая Java SE ClassLoader и OSGi. Отмечается также негативное влияние на выпуск Java EE 9, который невозможно будет построить на базе Jigsaw, так как это потребует разорвать обратную совместимость, переносимость и паритет в функциональности с прошлыми выпусками спецификаций Java EE. Оппоненты утверждают, что Red Hat пытает саботировать внедрение Jigsaw, так как данная технология конкурирует с уже поставляемой в платформе WildFly нестанратной системой загрузки модулей JBoss Modules (https://github.com/jboss-modules/jboss-modules), которую трудно будет сохранить в неизменном видео после внедрения Jigsaw.
URL: https://news.ycombinator.com/item?id=14301531
Новость: http://www.opennet.me/opennews/art.shtml?num=46519
Java давно не торт. Мы всем отделом (200 человек) переписали наш софт на Python и сэкономили за год $1.5 млн. Python выигрывает в скорости разработки, гибкости и поддержке.
В свою очередь нода выигрывает у питона. Но с первоначальным утверждением согласен.
а PHP выигрывает у ноды
А Perl выигрывает у всех выше перечисленных.
Ну и конечно Java выигрывает у perl :)
в твоих бредовых фантазиях она и у машкода выигрывает
Круг замкнулся, как водится. Камни-ножницы-бумагу никто не отменял!
Переписали бы на Ruby, выиграли бы ещё больше, так ещё и были бы готовы работать на американском или немецком рынке веб-разработки :)
Тут ruby давно не модно. Все хотят nodejs.
> Тут ruby давно не модно. Все хотят nodejs.Тут = USA
Про всех статистика не показывает https://trends.google.com/trends/explore?cat=5&date=all&q=/m...,/m/06y_qx,/m/0bbxf89
https://trends.google.com/trends/explore?cat=5&date=today 12-m&q=/m/0505cl,/m/06y_qx,/m/0bbxf89,phytonтак более информативно
> так более информативноя не знаю, кто такой phyton, но ясно, что за пределами РФ на Python веб разработки почти нет и не будет :)
Ясно только то, что _ты_ за пределами РФ никогда не был. :-)
ага. Именно поэтому сижу за рабочим местом (если в РФ, то ночью) и мониторю ветку :)
> я не знаю, кто такой phyton, но ясно, что за пределами РФ
> на Python веб разработки почти нет и не будет :)Моня, Мир таки не Одесса, так можно и утро пропустить, на Привозе https://www.tiobe.com/tiobe-index/ гутарят, шо Питон таки сделал Шарп, ой, шо деиться, куда катятся триклятые америкосы, мне таки страшно за Вас!
Чушь. По востребованности более чем сравнимо js/nodejs... По фриланс-биржам это тоже хорошо заметно.
Вот так ещё интереснее:
https://trends.google.com/trends/explore?cat=5&date=today�...,PHP,%2Fm%2F0bbxf89,Python
Ахаха, руби в данный момент используется ТОЛЬКО для быстрого выпуска прототипов (из-за низкого порога вхождения), а потом... потом обратно на жава/скала/го. С разморозкой
вот про низкий порог вхождения на руби обычно говорят те, кто в него так и не смог войти.... Эффективный код на руби - это функциональный стиль. Хоть и под истинно объектным языком. Под него мозги перестравить надо.А вот то, что на нём удобно писать - это да.
вы оба правы и не правы. На Ruby очень удобно писать dsl, это поистине замечательно делает твой код лаконичным и красивым и супер читабельным. Но дьявол кроется в деталях. После того как ты не трогал проект долгое время и всё что ты налабал уже выветрелось из головы, что бы понять что делает твой замечательный dsl тебе нужно пересмотреть дофига кода. Притом чем более запутанный(магический) dsl вы написали тем больше нужно приложить усилей. И тут встает вопрос плох или хорош dsl, а вот это уже зависит от того как вы его написали, размера и сложности проекта. Именно поэтому сейчас многие переходят на Go который простой как табуретка. Ну и немного не по теме, ruby для перестройки мышления в функциональную парадигму не лучший выбор.
>> После того как ты не трогал проект долгое время и всё что ты налабал уже выветрелось из головы,Это не Хаскель. Если код написан нормально, а не в последнюю ночь перед сдачей проекта (у меня сейчас вечер, если что :-) ), то нормально он поддерживается. Надо знать принципы работы руби, тогда и найти где конкретно реализована та или иная фича DSL - не сложно.
На счёт go, то вроде как рекомендация идти на rust. Даже попытки ML на него перетащить уже есть - http://weld.stanford.edu (проект от бывших питонистов-скалистов)
> Ну и немного не по
> теме, ruby для перестройки мышления в функциональную парадигму не лучший выбор.Чем плох? Тем что блок - только одна функция? Традиционную схему преобразования данных на map/select/reduce на нём очень хорошо показывать. Концепция отложенных вычислений с неявными callback - тоже хорошо демонстрируется.
Ну да, помним, что руби не функциональный язык и сворачивать сам цепочки функций не умеет. В остальном как мягкий переход к функциональному программированию - вполне годится.
>На Ruby очень удобно писать dslМда. Понятно, насколько крут ваш руби. В то время как все остальные уже перешли на PEG-подобные-движки, и пишут dsl на этих движках (которые покрывают 95% задач), вы все еще пишите на руби.
google://parsing expression grammar
Не благодари.
> google://parsing expression grammarсам понял, что написал? Разницу между DSL и DSEL слышал?
Я не тот Аноним, который написал о DSL в первый раз, но опыт использования и написания своих DSL/DSEL на руби действительно имею. Впрочем и опыт написания парсеров на Ragel и ANTLR тоже имею. Собрать на руби DSEL действительно удобно и быстро в силу гибкости языка. Сравниться с ним может разве что скала, но у неё свои проблемы.
>> google://parsing expression grammar
>сам понял, что написал?1. https://en.wikipedia.org/wiki/Parsing_expression_grammar
2. http://dl.acm.org/citation.cfm?id=964001.964011>Разницу между DSL и DSEL слышал?
PEG-движок может работать и там и сям. Все исходит от задачи, а не от реализации. Человек жаловался, мол код забывается. Вот, BNF вы тоже забываете? Так пользуйтесь тем, что стандартизированно (хоть как-то) и нигде ничего не будете забывать.
Действительно, PEG на руби пишется красиво https://github.com/nathansobo/treetop
Впрочем, как и другие DSL...
> На Ruby очень удобно писать dsl, это поистине замечательно делает твой код лаконичным и красивым и супер читабельным.WriteOnlyCode получается. На Скале с этим каждая попробовавшая команда обжигается. DSL сносит крышу и у каждое либы получается свой собственный язык.
Не надо сравнивать скалу и руби. В случае скалы большая часть кода - write only
А мы (в Google) -- наоборот, переписали с Python на Java, и очень рады, что теперь не нужно писать (и самое главное -- мэйнтэйнить) десятки юнит-тестов на каждый юнит, т.к. Java статически типизирована. Раньше test/code ratio по строчкам кода доходил иногда до трёх. В Java -- около единицы теперь.
PS: А скорость разработки страдает только у тех, кто не умеет пользоваться современными IDE.
> PS: А скорость разработки страдает только у тех, кто не умеет пользоваться
> современными IDE.Отчасти вы правы, idea очень сильно помогает, но эта ситуация не только у java.
>А мы (в Google) -- наоборот, переписали с Python на Javaпочему не Go или Dart?
Потому что го и дарт для страдания конкурентов, а им самим надо чтобы просто работало
>>А мы (в Google) -- наоборот, переписали с Python на Java
> почему не Go или Dart?Потому что для себя используют лучшее, а для клиентов - впаривают бренд-лояльное.
> В Java -- около единицы теперь.А с какой стороны?
Ага, особенно умиляет отсутствие упоминания конкретного интерпретатора — вы хоть, надеюсь, не будете утверждать, что что-то сэкономили за счёт использования апстримного питона?
Можете рассказать, какова была методика оценки экономии?
> Java давно не торт. Мы всем отделом (200 человек) переписали наш софт
> на Python и сэкономили за год $1.5 млн. Python выигрывает в
> скорости разработки, гибкости и поддержке.Многократный бред и победа НЛП над разумом.
На питоне больше писанины тестов, больше дебагинга, хуже с фреймворками.
Где-то лучше с либами (научный софт), где-то хуже (серверный).Т.е. вы поменяли шило на мыло, при этом вместо рефакторинга - все переписывая.
Но руководство проекта так всем запудрило мозги, что это расточительство сочли "экономией", да еще с подсчитанной цифрой (как будто рефакторинг без переписывания вышел бы дороже, что абсурд).
Экономия 625 баксов в месяц на программиста. Дешевы же програмеры на Питоне.
Вы сделали дополнительную работу - "переписали наш софт" и сэкономили?
Вы, все 200 человек, приплачивали за возможность писать на питоне?
Забавно смотреть на попытки расшевелить то что двигаться не способно от рождения. Раскол уже на принятии решения, надо думать что потом будет если примут. Потом думаю будет Go или Rust.
С другой стороны, жалко немного Жабу. Многому она меня научила. Свой первый серьезный проект я сделал как раз на Java.
Если они не угадают - будет не Go и не Rust, а .NET, так что лучше уж пусть осторожничают
Судя по массовому вовлечению разработчиков со стороны создателей языка и дикому восторгу хипстеров от айти, скорее таки go.
> Судя по массовому вовлечению разработчиков со стороны создателей языка и дикому восторгу
> хипстеров от айти, скорее таки go.Ужас. Лучше уж .NET, если не Java.
> Забавно смотреть на попытки расшевелить то что двигаться не способно от рождения.
> Раскол уже на принятии решения, надо думать что потом будет если
> примут. Потом думаю будет Go или Rust.
> С другой стороны, жалко немного Жабу. Многому она меня научила. Свой первый
> серьезный проект я сделал как раз на Java.Да не переживай ты так за Java, она будет живее всех остальных живых!!!
сколько они лет уже этот jigsaw теребят?
микрософт уже успел .net опенсорснуть и под линукс выпустить.
воистину https://en.wikipedia.org/wiki/Design_by_committee
Можно поинтересоваться причем тут .Net.
При том что под Linux похоже его используют три калеки (и не так уже важно OpenSource он или нет).
Как на JVM выполнить аналог питоновского :
python -m SimpleHTTPServer 8080
Не надо ездить на карьерном самосвале за хлебом. На легковушке, впрочем, тоже щебень возить не стоит.
В смысле сервера не надо писать на Java? Да вы не Crazy а Mad или Nut.
В смысле джава - не для "simple server". И вообще не для simple. А вот в сложных вещах ей самое место.
Ну и дурик ты.
groovy -l 80 SimpleWebServer
Java от Groovy не отличаем?
> Java от Groovy не отличаем?Вопрос был про jvm, а не именно про жабу, так что проходи мимо
Хм, да, чего это я. Впрочем, на кой так извращаться - всё равно не понимаю. Энтерпрайзы с десятками миллионов строк, тысячами типов бизнес-объектов, навороченной бизнес-логикой, масшатабированием и т.д. - понятно, там стерпишь и многословность, и потерю производительности - лишь бы этой горой кода хоть как-то управлять. А однострочник...
Твоё узкое мировоззрение не позволяет адекватно смотреть на факты
> Твоё узкое мировоззрение не позволяет адекватно смотреть на фактыЧасто повторяемые мантры "жабка/JVM НЕ ТОРМОЗЯТ" еще не факты и на реальность не влияют.
Какими конкретными программами на Java ты пользовался?
Например, Windchill.
Caught: java.io.FileNotFoundException: /Users/me/SimpleWebServer (/Users/me/SimpleWebServer)
Groovy Version: 2.4.11 JVM: 1.8.0_131
Типичный Java программист. Нехрена не знает языка, зато считает что именно на нем должны писаться сложные вещи.
Я сишник, мне можно :-) А говорю о том,ч то вижу кругом, в кровавых энтерпрайзах... Большое пишется либо на джаве, либо на C#, всё остальное и 10% хором не наберёт.
Ты, конечно, про большие распилы, а не ехать?
Я про ехать. Джава - довольно простой, но громоздкий язык, и всё там такое же. На любой чих будут простыни - но в этих простынях редко бывает что-то сложное. Простой (хоть и объёмный) код, готовая поддержка жизненного цикла, саппорт со стороны больших контор, поддержка средствами разработки, стабильная экосистема с горой софта любых масштабов, куча разрабов достаточного уровня по цене, которую массовый заказчик готов платить. Для больших проектов это важнее, чем эффективность языка. Потому что одно дело - если тормозит, другое - если не взлетело вообще.
> В смысле сервера не надо писать на Java? Да вы не Crazy
> а Mad или Nut.на Java стоит писать сервера!!! Как бы там не гавкали, Java всем покажет ещё зубы, на что она способна!!!!
"Как на JVM выполнить аналог питоновского"Написал бы, что оно делает. Ну, вебсервер на 8080 порту запускается и что он делает? Ничего? И?!
Формально, в javaEE пустой сервлет тоже не надо кодить, только проект создать в IDE и артифакт. Несколько секунд. Этим надо гордиться?
Я лично жабку люблю не за пустой вебсервер за 1 секунду, а за то, что я за несколько часов могу сделать backend который будет сервить данные из базки под терабайт для нескольких килоклиентов с временем ответа в единицы милисекунд. Без ЛАМПовых костылей в виде memcached, redis итд И что когда моя контора дорастет до хайлоада, я на той же жабе буду делать распределенные системы. Может и питон это может, флаг в руки, мне не жалко.
> могу сделать backend который будет сервить данные из базки под терабайт для нескольких килоклиентов с временем ответа в единицы милисекунд. Без ЛАМПовых костылей в виде memcached, redis итд И что когда моя контора дорастет до хайлоада, я на той же жабе буду делать распределенные системы.рецепт дадите? может я что-то не знаю про жабу... чем вы замените кеши типа memcасhed/redis? как вы впилите горизонтальное масштабирование? я создаю горизонтально масштабируемые системы но не на жабе, можете объяснить как это сделать на жабе простыми словами и конкретными примерами?
Задавайте конкретные вопорсы вам ответят.
конкретные вопросы как храните данные, как масштабируете хранение данных, как добаляете сервера хранения данных в подсистему хранения, как исключаете сервера хранения данных из подсистемы хранения данных, как перераспределяете данные в подсистеме хранения данных?сам серверный код можно на чем угодно писать, но залог производительности в масштабируемости. как масштабировать хранение данных? что используют в java те кто как утверждается пишут на ней hiload?
SQL со своими велосипедами роутинга и шардирования но с транзакциями и локами?
mongodb без транзакций и локов но с шардированием?
cassandra с brain split?
что-то свое волшебное?
> SQL со своими велосипедами роутинга и шардирования но с транзакциями и локами?В наши дни пока SQL играет немаловажную роль, он вроде не такой уж сильно загроможденный, даже XQuery XPath почему-то больше времени занимают, у них свои характеристики работы.
> конкретные вопросы как храните данные, как масштабируете хранение данных, как добаляете
> сервера хранения данных в подсистему хранения, как исключаете сервера хранения данных
> из подсистемы хранения данных, как перераспределяете данные в подсистеме хранения данных?Это не конкретные вопросы. Данные в жабе не храним, ей их обрабатываем. Упарываться по транзакционности стараемся не. 8) Поэтому в основном Монго.
Кстати, для особенно кровавых ынтырпрайзщиков в жабе есть спецификация JTA на тему распределенных транзакций. Можно взять данные в Postgres, обработать, положить в Oracle в рамках атомарной операции. На Пистоне так можно?
те ваш ответ JTA это серебрянная пуля для hiload, так?
>чем вы замените кеши типа memcасhed/redisВ качестве локального кеша банальный HashMap просто разрывающе быстрее и удобнее.
FastUtil ещё быстрее, заметно экономнее с ОЗУ с примитивными типами.Распределенный кеш - Infinispan есть в моём AS. Куча других нативных решений.
В чём заключается незаменимость redis? Кеш как внешнее решение это просто нонсенс.
>Кеш как внешнее решение это просто нонсенс.кеш как внешнее решение необходимость для доступа к одному кешу из множества воркеров
Описанная конфигурация - не highload. Распределять и масштабировать (в JVM) ничего не нужно на таких нагрузках. Кешей хватает внутренних. А все упомянутые вами инструменты появляются на более высоких нагрузках, и там у Java все как у всех. Никакой магии.
HttpServer server = HttpServer.create();
server.bind(new InetSocketAddress(8080), 0);
server.createContext("/", new SomeHandler())
server.start();
Думал, запустите этот сервер на питоне. Он там еще сервит файлы в текущй папке.
Проще говоря занимается не тем чем должен. :)
>>> python -m SimpleHTTPServer 8080
>> Он там еще сервит файлы в текущй папке.
> Проще говоря занимается не тем чем должен. :)А чем должен заниматься _простой_ httpserver? Неужели только жрать ЦПУ и раму, но абсолютно ничего не делать? o_O
$CATALINA_HOME/bin/startup.sh :)
Перевожу бекенд с Java на D, ИМХО в плане С-синтаксиса альтернатив нет. А жаль
Вау, и как? Неплохо было бы услышать о практическом опыте. В идеале - в виде статьи...
D торт, на мой взгляд незаслужено замалчиваемый, для веб есть vibe.d который уделывает ноду, из минусов - парадигм много - как следствие куча вилосипедов с разными парадигмами, кто-то предпочитает писать либы без изключений, кто-то наборот. Таких удобных шаблонов нигде не видел (из компилируемых). Кранее время наблюдается появление в С++ иногих фич из D, но по мощи шаблонов С++ до D далеко.Например на этапе компилицяци считать файл в строку
auto fileContent = import("some_file.data");
Распарсить, и динамически сформировать какой либо код
char[] generatedCode = ...
Подключить сгенерированый код
mixin(generatedCode);
Этот код будет скомпилирован так же как весь остальной написаный вручную
Симпатичен Go пробовал на нем писать, рулит для написания небольших демонов, статическая линковка в 1 бинарь, хотелось бы такое в D, но после D никак не идет, многословен
Пробовал Rust - замудреный, но хотелось бы возможности в D иметь подсчет ссылок вместо GC
> Пробовал Rust - замудреный, но хотелось бы возможности в D иметь подсчет ссылок вместо GCТам есть весьма интересная штука Rocket. Хотя он написан с использованием фич из nightly. А сама замудрённость не проблемна как мне кажется.
>> Пробовал Rust - замудреный, но хотелось бы возможности в D иметь подсчет ссылок вместо GC
> Там есть весьма интересная штука Rocket. Хотя он написан с использованием фич
> из nightly. А сама замудрённость не проблемна как мне кажется.Rust многословен, на то время что я его смотрел не было аналогов mixin, static if из D
Что такое D я и сам могу рассказать :-) Интересен опыт его внедрения в реальной системе, о описанием плюсов, граблей и способов их обхода.А так - да, пул потоков из двадцати строчек, мини-орм из сотни и так далее - писал, и было на редкость приятно. Вот vibe.d как-то не оценил, роутер был какой-то совершенно убогий. Но давно это было, там наверняка давно допилили его. По сравнению с плюсами, конечно, небо и земля - писать проще, гибкость больше. Один UFCS чего стоит.
Все что нужно есть так или иначе, на крайняк можно прикрутить Cишную-либу.Я бы не назвал это граблями, скорее неудобства и отсутсвия опыта.
В реальной системе у нас используется как сетевые демоны, в этом плане стандартная библиотека неудобна, std.socket построен на эксепшенах доступен только select из-за кроссплатформенности, так как у нас на серваках линукс, кросплатформенности не требуется, в качестве сетевого стека используется небольшая обертка над epoll
Для конкурентности и распаралеливания std.(concurency | parallelism) немного не удобны
нужно помнить если распаралеленый блок, не забывать о переменных за пределами блока (распаралеленые блоки - отдельные потоки) thread local накладывает дополнительные неудобства с передачей данных между потоками можно конечно юзать префикс gshared - что-бы глобально, как в сишечке - но очень не советуется. Локи опять же вручную, правда мютекс подобных локов есть блокsynchronized (someMutex)
{
...
}
Так же немного не хватает в стандартной библиотеке нормальной работы с Posix-сигналами например как GoСтандартная некоторая часть стандартной либы не реализована нативно, часто тянет за собой
libcurl, libssl и т.д. что пичалит лишними зависимостями (перфекционизм =)> Вот vibe.d как-то не оценил, роутер был какой-то совершенно убогий
Ранее для веба использовался питонячий Werkzeug/Flask, и после перехода на vibe.d вначале был запилен собственный роутер, а в более поздних проектах привык к встроеному в vibe.d свои задачи вбольшинстве случаев он решает (нет роутинга для поддоменов)
А вот вот с шаблонизатором (diet) я так и не смирился, не хватает наследования - написал свой jinja2 подобный, шаблоны компилятся вместе с проеком =)
Хм, ясно, спасибо
Интересный эксперимент. Но после Вас все это придется переписывать, рано или поздно.Как это обычно бывает. Посмотрят на количество велосипедов и...
jigsaw это наконец-то разделяемые библиотеки для явы?блин, да дайте две, нет, дайте стопицот!!! зачем отменили, гады!!!
чтобы бардака как в случае js не было
Там как раз бардак начался из-за отсутствия стандарта.
И Java судя по статье в не меньший бардак способна скатиться учитывая JBoss Modules, OSGi.
Java - серьезный продукт для серьезных решений.
Никаких недоделок не должно быть.
За это я его и уважаю и буду сидеть на нем еще 100500 лет ))
... кроме тех, которые нужны для совместимости
Всё правильно сделали. Что Jigsaw — зашквар, стало ясно уже когда при обсуждении спецификации полностью проигнорировали OSGI. Рейнхольда — на мыло!Интересно, а почему голосование происходит только сейчас? Либо Оракл просто использует эту кашу как предлог не мержить ветку jigsaw (т.е. решение не релизить его было принято уже давно), либо у них всё так плохо с коммуникацией внутри коммитета, что это уже не смешно.
так Oracle вроде как проголосовал "ЗА". Позиция RedHat в принципе понятна, им придется пилить прослойку для совместимости с JbossModules (если они именно "развалятся" из-за jigsaw). А вот позицию IBM еще бы понять... Скорее всего, там тоже что-то не так с каким-то из их продуктов
Естественно "ЗА", - кто в здравом уме признается в некомпетентности своих разработчиков?И дело здесь вовсе не в политике (вообще). Jigsaw объективно отвратителен. Настолько, что непричастным к его разработке людям это сразу же очевидно после прочтения его документации.
https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri... - подробное объяснение
Вот к примеру фантастическая цитаты:
> In order to support the restrictions imposed by Jigsaw, modules are always loaded and resolved eagerly within a layer - even if there are hundreds or thousands of modules on the module path...
Круто, да?
Или вот ещё:
> The Jigsaw implementation mandates that module descriptors should be established and loaded in bytecode format...
Хочешь отремонтировать бажный дескриптор модуля? Запасайся редактором байткода!
> Service Loading Changes... In Jigsaw, all service interfaces and implementations on the module path are flattened into a single, global namespace...
Каково, а? То, что работало безупречно со времён Java 6 (изоляцию ServiceLoader в разных класслодерах), сломали, задокументировали это как ожидаемое поведение, и делают вид, что так и надо.
Эту хрень нужно не временно отклонять до пересмотра, а выкидывать нахрен из языка, пока оно там не укоренилось и не начало давать метастазы.
хз, я читал и положительные и отрицательные отзывы на этот jigsaw. нужно оно в таком виде или нет - сказать сложно. да и большинства разработчиков все эти недостатки коснуться не должно. в любом случае, если его улучшат, пусть даже ценой задержки релиза - я не против. а если его выкинут... что тогда вообще в java9 останется?
"Большинство разработчиков" обнаружат, что1. setAccessible не работает
2. Unsafe накрылся медным тазом (а вместе с ним и все либы, которые его используют)
3. Ресурсы из других модулей не читаются
4. bootclasspath исчез *без какой-либо альтернативы* (вместе с rt.jar)
5. Встроенные класслодеры больше не наследуются от URLClassLoaderИ выключат jigsaw куда-подальше (если будет соответствующий переключатель). Или останутся сидеть на Java 8. Единственная полезная фича jigsaw - возможность изоляции модулей друг от друга. Но ни всего вышеперечисленного, ни множества других багов (см. ссылку) оно не стоит.
> Интересно, а почему голосование происходит только сейчас? Либо Оракл просто использует
> эту кашу как предлог не мержить ветку jigsaw (т.е. решение не
> релизить его было принято уже давно), либо у них всё так
> плохо с коммуникацией внутри коммитета, что это уже не смешно.Архитектурные решения были приняты два-три года назад, но откатить их решили когда вся JSR имплементирована. Это что-то эпичное.
Модуль в Java - это .class файл, бинарник. Ничего выдумывать не надо. Всё остальное - перепаковка.
Сколько паники вокруг Java 9 и Jigsaw!!! Понять позицию некоторых компаний, как Red Hat можно, что они боятся, что из-за больших изменений в Java их системы перестанут работать или будут работать, но с нарушением. Лично я в Java не разочарован, буквально недавно "переселился" в Eclipse, там лучше чем в NetBeans, я очень сожалею, что раньше не перешел, Eclipse сказка в большей степени, Eclipse Foundation не отстает. Не знаю, кто из вас всех "обновились до jdk8u131, jdk8u121 очень даже тоже хорошо работает. Я не думаю, что в один миг мир откажется от той версии Java синтаксиса, который применялся в Java 6, 7, 8. Я планирую ещё надолго задержаться в Java, в Java есть немало плюсов, немалое количество компаний до сих пор Java применяют, потому как взять на свои (то есть их плечи) внезапно пересесть с Джава на Питон это очень дорогое удовольствие по деньгам и громадным затратам трудового времени. Я так понимаю, что поскольку я в Eclipse, надо будет следить за позицией Eclipse Foundation, каковы будут их меры по обеспечению совместимости с Java 9, я бы советал большинству не паниковать касаемо Java 9, приспосабливаться нужно ко возможным изменениям.
одно из главных проимуществ java - обратная совместимость. вы можете взять класс скомпилированный 20 лет назад и запустить на современной JVM. "приспосабливаться" - это значит ценность в java заметно уменьшится.
> одно из главных проимуществ java - обратная совместимость. вы можете взять класс
> скомпилированный 20 лет назадЕсть официальная статистика скольким это надо, запускать классы 20летней давности?
"главное проимущество" по идее, это то что надо большинству. Соответственно, плюсы жабы совсем в другом.
>> одно из главных проимуществ java - обратная совместимость. вы можете взять класс
>> скомпилированный 20 лет назадДоброго времени суток!!! Дмитрий(Dmitry77) просто приводил основные плюсы, что Java в отличие от .NET позволяет запустить программный код 20-ти летней давности, Dmitry77 не имел ввиду, что мы все должны застрять в ностальгии по временам, когда Java была широко совместима с запуском программ, Майкрософтовский .NET не может похвастаться тем, что можно запустить многолетней давности программы. Если на Windows XP Джава позволяла запустить программы более позднего поколения, а .NET требует более новой Виндоус, чтобы установиться как таковой.
> Есть официальная статистика скольким это надо, запускать классы 20летней давности?
Статистики точной никто не сможет дать, скольким нужно запускать программы 20-летней давности, от себя обращаясь(меня зовут Игорь) скажу следующее: при первой возможности перехожу на очередные выпуски jdk8u..., которые зачастую устраняют уязвимости и прочие проблемы, не надо пытаться вернуться на Java 6,7, желательно "обитать" сейчас в Java 8, она ввела немало нового, но при этом сохранила возможность запускать программы выпущенные 2004-2009 годами, обращаю Ваше внимание, что JVM(Виртуальная Машина Java) за последние годы не раз подвергалась переработкам и изменениям, я думаю, что немалое количество новых и нынешних(я тоже) Java Developers будут "включать" средства и библиотеки с учётом изменений, которые неизбежно будут вводиться в Java 9.
> "главное проимущество" по идее, это то что надо большинству. Соответственно, плюсы жабы
> совсем в другом.У "жабы"(Java) плюсов и других много, Java подходит даже в тех областях бизнес-коммерции, где Python и особенно С++ неуместен. Техсопровождение не такое сильно затратное. Те, кто тут говорят про Dart, Go и Rust - эти языки пригодны сейчас в том, в отношении чего они применяются, может область их применения со временем расшириться, я только ЗА.
Я даже признаю и вижу, что Java "нуждается" в свежем глотке новизны, НО... но это не значит, что ORACLE перечеркнет всё, за счёт связанного на Java API работало и запускалось.Я обязательно буду отслеживать и наблюдать за Eclipse Foundation, каковы будут их меры и действия касаемо предвещаемых "Jigsaw улучшений" и модульности Java 9.
Товарищи не паниковать!!!
>> одно из главных проимуществ java - обратная совместимость. вы можете взять класс
>> скомпилированный 20 лет назад
> Есть официальная статистика скольким это надо, запускать классы 20летней давности?
> "главное проимущество" по идее, это то что надо большинству. Соответственно, плюсы жабы
> совсем в другом.Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с написанием (или переписывать на новое API, или заново отлаживать, с новыми глюками) - не каждому бизнесу понравится. С#, Qt, Python считают нормальным переписывания, Java для тех кто ценит уже потраченные усилия.
> Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с
> написанием (или переписывать на новое API, или заново отлаживатьДавай не будем передергивать и искажать. Ранее было сказано про код 20 летней давности в СКОМПИЛЕННОМ виде. Я далёк от больших ынтырпрайзов, но по прежнему уверен, что 20летний JAR это не необходимость, а просто кусок мамонтового Гэ, от которого потеряли сорцы и/или документацию.
На "главный плюс жабы" ваще не тянет. Рефакторинг полезная штука, хоть и стоит денег.
>> Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с
>> написанием (или переписывать на новое API, или заново отлаживатьДалеко не каждому в кайф переписывать заново API(для не знающих что это такое, - Application Programming Interface - интерфейс прикладного программирования), сколько бы разработчику ни заплатили за написание новой lib (библиотеки), разработчик не может гарантировать, что даже в хорошо и благополучно написанной библиотеке не будет крахов или каких-то других проблем.
Рефакторинг(профилирование кода) штука очень полезная, но и она требует от Java программиста немало усилий по достижению результата.
> Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с
> написанием (или переписывать на новое API, или заново отлаживать, с новыми
> глюками) - не каждому бизнесу понравится. С#, Qt, Python считают нормальным
> переписывания, Java для тех кто ценит уже потраченные усилия.Знаешь, у меня складывается впечатление касаемо C#, Qt, Python что там одни садо-мазохисты, которые любят постоянно что-то переписывать, переиначивать.
Java более длительно не изменяющаяся, но и в этом есть плюс, мне не нужно без конца перестраиваться на новый выпуск с учётом нововведений как в случае у тех, кто с Python работает. Java мне даёт постоянство в её применении, большинство библиотек, включая Swing(Metal UI) а также SWT и JFace(IBM/Eclipse Foundation) тоже не изменяемы, я могу без опасения на них GUI писать.
Я со своей стороны не тороплюсь делать выводы о Jigsaw в Java 9, хоть уже успел просмотреть JSR 376 на openjdk.java.net и уже видел The Java Language Specification Java SE 9 Edition(спецификация к загрузке предлагается в PDF) и могу сказать, что Java SE 9 не такая уж и плохая как о ней говорят, да и ещё, грядут изменения касаемо синтаксиса MANIFEST.MF, JSR 376 чаще упоминает не столько MANIFEST.MF сколько INDEX.LIST.
> Java более длительно не изменяющаяся, но и в этом есть плюс, мне
> не нужно без конца перестраиваться на новый выпуск с учётом нововведений
> как в случае у тех, кто с Python работает.Ох уж эти жабисты. Во первых, обратную совместимость в питонах никто не ломает.
Во вторых, какие-то уж очень странные у вас питоны. Вы точно о ЯП, а не об одной из кучи библиотек?
Ну и наконец, сравнение фиолетового с яблочным.
Питон – это в первую очередь скрипты и прототипы, от силы на несколько тысяч строк.
Это как с мултитулом. Подкрутить им что-то по мелочи будет быстрее, чем сбегать за ящиком с инструментами, но вот чинить или разбирать что-то всерьез – увольте. Хотя любители находятся, да.
> Есть официальная статистика скольким это надо, запускать классы 20летней давности?Каждая платформа обрастает экосистемой библиотек. Если либа не изменялась 5-10 лет - это не значит что она устарела, она может быть даже единственным (уникальным) решением какой-то проблемы.
Если либами нельзя пользоваться толькоп потому что е постоянно (каждый год) не майтенят... то это сильный минус всей платформе. Хотя для бюджета IT департаментов может и хорошо, когда языки совместимость ломают - объем работ на ровном месте больше, там переписать, там заново все тестировать...
Но большие корпорации, уровня IBM-Oracle, не любят кидать на деньги сами себя, поэтому используют стабильную платформу - JDK.
> Но большие корпорации, уровня IBM-Oracle, не любят кидать на деньги сами себя,
> поэтому используют стабильную платформу - JDK.Ты всё правильно сказал относительно IBM и ORACLE, JDK как-никак "рулит", без JDK никуда!!!
В дополнение скажу, не только с Джава на Питон, но и на другие языки. Рэд Хэт уж точно не факт что примется потратить время на переписывание своих систем.
Зачем нужен Jigsaw, когда есть OSGI ?
Дмитрий, я тоже с Вами согласен, есть OSGi, прикол ещё в том, что этот OSGi упоминается и в Eclipse. Судя по всему, ORACLE думает, что разбивка на модули JRE и JDK "облегчит" техническое сопровождение как новых выпускаемых программ на Java Platform так и уже не один и не два года ныне работающих программ. Дмитрий, мне будет очень интересно как Eclipse Foundation будет вести политику по отношению таких "неблагоприятных" изменений, введение которых может поставить под угрозу нормальное функционирование большинства того, что есть в Eclipse IDE(вне зависимости от отдельно выбранного дистрибутива, как для Java, так и для С/С++, и прочее), поскольку для запуска и нормального функционирования таких как Eclipse IDE и даже тем, кто до сих пор с NetBeans необходим JDK. Почему я заговорил об этом, потому что сильные изменения могут нехорошо сказаться на всю Eclipse Platform. Но я думаю, что сейчас пока не стоит паниковать из-за Java 9, первое что могу сказать, - размер загружаемого JDK с может увеличиться со 190 МБ до 200 с копейками МегаБайт, ORACLE сама применяет в своих продуктах Java, думаю они там не дураки, чтобы в один миг отказаться от того, что было в Java 7, 8.
>[оверквотинг удален]
> дистрибутива, как для Java, так и для С/С++, и прочее), поскольку
> для запуска и нормального функционирования таких как Eclipse IDE и даже
> тем, кто до сих пор с NetBeans необходим JDK. Почему я
> заговорил об этом, потому что сильные изменения могут нехорошо сказаться на
> всю Eclipse Platform. Но я думаю, что сейчас пока не стоит
> паниковать из-за Java 9, первое что могу сказать, - размер загружаемого
> JDK с может увеличиться со 190 МБ до 200 с копейками
> МегаБайт, ORACLE сама применяет в своих продуктах Java, думаю они там
> не дураки, чтобы в один миг отказаться от того, что было
> в Java 7, 8.Предварительную версию JDK 9 ещё не смотрели? Тут она: http://jdk.java.net/9/
Там уже всё "модульно" и работает.
По поводу jdk9 я уже в курсе, более того, у меня после распаковки ZIP jdk вместо 256 с копейками Мегабайт "превратились" в 470 Мб. Про работающую "модульность" ты интересно сказал. Кстати, к своему же удивлению я увидел внутри очень похожее как в случае установки jdk8u121-i586.exe, а именно, похожие папки и файлы, которые после установки jdk8u121 или более поздней редакции jdk8u131, которая заходит в Program Files (x86), это всё хорошо, но эту jdk9 просто так не "загнать" в Програм Файлз (x86), хоть и есть права Администратора, Eclipse IDE и NetBeans IDE всё равно "продолжат видеть" те же jdk8u121 или jdk8u131 (в зависимости от установленного JDK), но как вариант, можно попробовать "заставить" Eclipse IDE или NetBeans IDE начать видеть jdk9, и через этот девятый jdk "занырнуть" в модульность. Флаг нам, Javистам в руки и вперёд!!!! С Уважением, Игорь.
Столько радости по поводу Eclipse IDE я давно не видел. Переходите, Игорь, поскорее на IntelliJ IDEA, вообще в экстазе забъетесь ))). И новая JDK туда подключается пятью кликами мышки вне зависимости от того, где JDK лежит и у кого права администратора. (Справедливости ради, и в Eclipse и в NetBeans, думаю тоже легко подключить JDK откуда угодно, но я с ними давно уже не работал)
По хорошему надо было объединить OSGI и JDK, а не строить модульностью отдельно.У них была светлая идея сделать модули - deb пакеты (в формате deb), не понятно зачем это Java. Теперь вообще финт ушами, два года делать, сделать и решить не релизить.
> По хорошему надо было объединить OSGI и JDK, а не строить модульностью
> отдельно.
> У них была светлая идея сделать модули - deb пакеты (в формате
> deb), не понятно зачем это Java. Теперь вообще финт ушами, два
> года делать, сделать и решить не релизить.deb пакеты - да, это странно, НО... для Линукс есть rpm пакет, но дело в том, что этот рпм как и установочный файл для Windows, - jdk8u121-windows-i586.exe служит для процесса установки в ОС (Операционной системе). Следует обратить внимание, что пакеты в Java не одно и то же что rpm, Java packages служат для запаковки Java классов и установления пространства имён и видимости классов.
Отменить модульность за месяц до релиза? Они охренели...
> Отменить модульность за месяц до релиза? Они охренели...Ты обрати внимание, выпуск Java 9 в который раз "переносится", я уж сам думал что начну знакомиться с вкусностями Java 9, дабы понимать, что делать дальше, а тут получается опять "сдвиг" по графику аж на конец июля 2017(и это при условии, что JSR 376 таки одобрят), я пока применяю jkd8u121, - эта версия обновления очень даже чудненько работает.
Мне не менее важно будет пронаблюдать за тем, что Eclipse Foundation будет предпринимать в связи с такими неизбежными Java 9 "улучшениями".
>> Eclipse FoundationЗа 15 лет работя с явой так и не понял этого IDE. NetBeans нормально, IDEA нормально, а Eclipse... не понимаю этого интерфейса, по мне - все неудобно сделано.
>>> Eclipse Foundation
> За 15 лет работя с явой так и не понял этого IDE.
> NetBeans нормально, IDEA нормально, а Eclipse... не понимаю этого интерфейса, по
> мне - все неудобно сделано.Начнём с того, хоть по Eclipse и SWT/JFace (это графическая библиотека для Eclipse) и были выпущены книжные издания, рассказывающие, что и с чем едят SWT/JFace GUI, НО..., если ты заметил, что Java по внешнему виду и поведению (L&F Metal UI, я привык говорить Java Swing) давала возможность получить одинаковый вид что на Виндоус что на Линуксах, а вот в случае с Eclipse IDE идёт обращение к нижележащей ОС, хотя в NetBeans тоже можно было бы добиться вызова через JNI (Java Native Interface) нативных функций к самой ОС, что должно давать более быстрые результаты.
Вам похоже шашечки, а не ехать... Но хотя бы не обманывайте себя - одинаково эклипс выглядит и на винде и в линуксах и в макоси. Так что смысла от того, куда идет какое обращение не много. Быстрее ИДЕИ он если и работает, то не из-за обращения к ОС напрямую, а из-за отсутствия большого количества вспомогательных индексов которые ИДЕЕ позволяют ускорять разработчика.
>>> Eclipse Foundation
> За 15 лет работя с явой так и не понял этого IDE.Сколько ни пробовал разных версий IDEA, но не понял логику контекстных меню в этой IDE. Похоже на то, что об уместности и перечислении пунктов команд меню, возникающего по клику над местоположением курсора мыши, никто не думал. Кроме этого, IDEA часто виснет после нескольких запусков простых проектов - приходится убивать процесс самой IDE и запускать снова.
> Ты обрати внимание, выпуск Java 9 в который раз "переносится", я ужДа, учитывая что они задержали релиз на год, ради модульности...
Такая непоследовательность может вызвать только недоумения.
Но если предложенная модульность не дружит с OSGI - то лучше ее выкинуть, в этом они поступили мудро. Но не понятно почему так запоздало.
> Такая непоследовательность может вызвать только недоумения.
> Но если предложенная модульность не дружит с OSGI - то лучше ее
> выкинуть, в этом они поступили мудро. Но не понятно почему так
> запоздало.Для меня их запоздалость уже не удивление!!!Но всё же ждём вестей, как говорится!!!
>> Отменить модульность за месяц до релиза? Они охренели...
> Ты обрати внимание, выпуск Java 9 в который раз "переносится", я уж
> сам думал что начну знакомиться с вкусностями Java 9, дабы понимать,
> что делать дальше,Пожалуйста, пройдите сюда и попробуйте уже: http://jdk.java.net/9/
> а тут получается опять "сдвиг" по графику аж
> на конец июля 2017(и это при условии, что JSR 376 таки
> одобрят), я пока применяю jkd8u121, - эта версия обновления очень даже
> чудненько работает.Странное желание "прислониться" к новой версии JDK, оставаясь на необновлённой предыдущей версии. Сейчас в моде jdk8u131. Даже на FreeBSD:
% java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)> Мне не менее важно будет пронаблюдать за тем, что Eclipse Foundation будет
> предпринимать в связи с такими неизбежными Java 9 "улучшениями".OSGi Eclipse и модульность новой Java 9 никак не конфликтуют. А бажность эклипсовского фреймворка, когда внезапно после обновления среды оказывается, что модули почему-то не той системы/версии не работают в ней - известная проблема.