The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Исполнительный комитет JCP не утвердил модульную систему в J..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от opennews on 09-Май-17, 23:06 
Исполнительные комитет 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.ru/opennews/art.shtml?num=46519

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –10 +/
Сообщение от Владислав Никифоров on 09-Май-17, 23:06 
Java давно не торт. Мы всем отделом (200 человек) переписали наш софт на Python и сэкономили за год $1.5 млн. Python выигрывает в скорости разработки, гибкости и поддержке.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –18 +/
Сообщение от Отражение луны (ok) on 09-Май-17, 23:38 
В свою очередь нода выигрывает у питона. Но с первоначальным утверждением согласен.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

73. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +5 +/
Сообщение от anonymous (??) on 10-Май-17, 15:32 
а PHP выигрывает у ноды
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

80. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +8 +/
Сообщение от 123452345345 on 10-Май-17, 20:36 
А Perl выигрывает у всех выше перечисленных.
Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

117. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +9 +/
Сообщение от Vitaliy Yakovchuk on 11-Май-17, 21:08 
Ну и конечно Java выигрывает у perl :)
Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

132. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от anonymous (??) on 15-Май-17, 10:17 
в твоих бредовых фантазиях она и у машкода выигрывает
Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

133. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +2 +/
Сообщение от scorry (ok) on 16-Май-17, 11:57 
Круг замкнулся, как водится. Камни-ножницы-бумагу никто не отменял!
Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

13. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –5 +/
Сообщение от Аноним (??) on 10-Май-17, 00:19 
Переписали бы на Ruby, выиграли бы ещё больше, так ещё и были бы готовы работать на американском или немецком рынке веб-разработки :)
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

15. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Lolwat on 10-Май-17, 00:33 
Тут ruby давно не модно. Все хотят nodejs.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

16. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Lolwat on 10-Май-17, 00:34 
> Тут ruby давно не модно. Все хотят nodejs.

Тут = USA

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 01:07 
Про всех статистика не показывает https://trends.google.com/trends/explore?cat=5&date=all&q=/m...
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

20. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от о6какатрон on 10-Май-17, 01:19 
https://trends.google.com/trends/explore?cat=5&date=today 12-m&q=/m/0505cl,/m/06y_qx,/m/0bbxf89,phyton

так более информативно

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

23. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –2 +/
Сообщение от Аноним (??) on 10-Май-17, 01:27 
> так более информативно

я не знаю, кто такой phyton, но ясно, что за пределами РФ на Python веб разработки почти нет и не будет :)

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

45. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +2 +/
Сообщение от . on 10-Май-17, 04:49 
Ясно только то, что _ты_ за пределами РФ никогда не был. :-)
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

46. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Аноним (??) on 10-Май-17, 04:55 
ага. Именно поэтому сижу за рабочим местом (если в РФ, то ночью) и мониторю ветку :)
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

50. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от SkyNet email(??) on 10-Май-17, 08:12 
> я не знаю, кто такой phyton, но ясно, что за пределами РФ
> на Python веб разработки почти нет и не будет :)

Моня, Мир таки не Одесса, так можно и утро пропустить, на Привозе https://www.tiobe.com/tiobe-index/ гутарят, шо Питон таки сделал Шарп, ой, шо деиться, куда катятся триклятые америкосы, мне таки страшно за Вас!

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

77. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от northbear (??) on 10-Май-17, 16:58 
Чушь. По востребованности более чем сравнимо js/nodejs... По фриланс-биржам это тоже хорошо заметно.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

71. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от amonymous on 10-Май-17, 14:29 
Вот так ещё интереснее:
https://trends.google.com/trends/explore?cat=5&date=today�...
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

24. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Аноним (??) on 10-Май-17, 01:44 
Ахаха, руби в данный момент используется ТОЛЬКО для быстрого выпуска прототипов (из-за низкого порога вхождения), а потом... потом обратно на жава/скала/го. С разморозкой
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

28. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 02:02 
вот про низкий порог вхождения на руби обычно говорят те, кто в него так и не смог войти.... Эффективный код на руби - это функциональный стиль. Хоть и под истинно объектным языком. Под него мозги перестравить надо.

А вот то, что на нём удобно писать - это да.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

39. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Аноним (??) on 10-Май-17, 04:13 
вы оба правы и не правы. На Ruby очень удобно писать dsl, это поистине замечательно делает твой код лаконичным и красивым и супер читабельным. Но дьявол кроется в деталях. После того как ты не трогал проект долгое время и всё что ты налабал уже выветрелось из головы, что бы понять что делает твой замечательный dsl тебе нужно пересмотреть дофига кода. Притом чем более запутанный(магический) dsl вы написали тем больше нужно приложить усилей. И тут встает вопрос плох или хорош dsl, а вот это уже зависит от того как вы его написали, размера и сложности проекта. Именно поэтому сейчас многие переходят на Go который простой как табуретка. Ну и немного не по теме, ruby для перестройки мышления в функциональную парадигму не лучший выбор.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

41. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 04:27 
>> После того как ты не трогал проект долгое время и всё что ты налабал уже выветрелось из головы,

Это не Хаскель. Если код написан нормально, а не в последнюю ночь перед сдачей проекта (у меня сейчас вечер, если что :-) ), то нормально он поддерживается. Надо знать принципы работы руби, тогда и найти где конкретно реализована та или иная фича DSL - не сложно.

На счёт go, то вроде как рекомендация идти на rust. Даже попытки ML на него перетащить уже есть - http://weld.stanford.edu (проект от бывших питонистов-скалистов)

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

42. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 04:33 
> Ну и немного не по
> теме, ruby для перестройки мышления в функциональную парадигму не лучший выбор.

Чем плох? Тем что блок - только одна функция? Традиционную схему преобразования данных на map/select/reduce на нём очень хорошо показывать. Концепция отложенных вычислений с неявными callback - тоже хорошо демонстрируется.

Ну да, помним, что руби не функциональный язык и сворачивать сам цепочки функций не умеет. В остальном как мягкий переход к функциональному программированию - вполне годится.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

48. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 07:18 
>На Ruby очень удобно писать dsl

Мда. Понятно, насколько крут ваш руби. В то время как все остальные уже перешли на PEG-подобные-движки, и пишут dsl на этих движках (которые покрывают 95% задач), вы все еще пишите на руби.

google://parsing expression grammar

Не благодари.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

49. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 07:39 
> google://parsing expression grammar

сам понял, что написал? Разницу между DSL и DSEL слышал?
Я не тот Аноним, который написал о DSL в первый раз, но опыт использования и написания своих DSL/DSEL на руби действительно имею. Впрочем и опыт написания парсеров на Ragel и ANTLR тоже имею. Собрать на руби DSEL действительно удобно и быстро в силу гибкости языка. Сравниться с ним может разве что скала, но у неё свои проблемы.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

51. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 08:41 
>> 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 вы тоже забываете? Так пользуйтесь тем, что стандартизированно (хоть как-то) и нигде ничего не будете забывать.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

53. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 09:54 
Действительно, PEG на руби пишется красиво https://github.com/nathansobo/treetop
Впрочем, как и другие DSL...
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

97. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Вареник on 11-Май-17, 10:18 
> На Ruby очень удобно писать dsl, это поистине замечательно делает твой код лаконичным и красивым и супер читабельным.

WriteOnlyCode получается. На Скале с этим каждая попробовавшая команда обжигается. DSL сносит крышу и у каждое либы получается свой собственный язык.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

114. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 11-Май-17, 20:24 
Не надо сравнивать скалу и руби. В случае скалы большая часть кода - write only
Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

30. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +8 +/
Сообщение от qsdg (ok) on 10-Май-17, 02:08 
А мы (в Google) -- наоборот, переписали с Python на Java, и очень рады, что теперь не нужно писать (и самое главное -- мэйнтэйнить) десятки юнит-тестов на каждый юнит, т.к. Java статически типизирована. Раньше test/code ratio по строчкам кода доходил иногда до трёх. В Java -- около единицы теперь.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

31. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от qsdg (ok) on 10-Май-17, 02:09 
PS: А скорость разработки страдает только у тех, кто не умеет пользоваться современными IDE.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

40. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Аноним (??) on 10-Май-17, 04:16 
> PS: А скорость разработки страдает только у тех, кто не умеет пользоваться
> современными IDE.

Отчасти вы правы, idea очень сильно помогает, но эта ситуация не только у java.


Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

55. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от слон on 10-Май-17, 10:41 
>А мы (в Google) -- наоборот, переписали с Python на Java

почему не Go или Dart?

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

58. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +3 +/
Сообщение от Аноним (??) on 10-Май-17, 10:58 
Потому что го и дарт для страдания конкурентов, а им самим надо чтобы просто работало
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

95. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Вареник on 11-Май-17, 10:13 
>>А мы (в Google) -- наоборот, переписали с Python на Java
> почему не Go или Dart?

Потому что для себя используют лучшее, а для клиентов - впаривают бренд-лояльное.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

135. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Аноним (??) on 16-Май-17, 22:33 
> В Java -- около единицы теперь.

А с какой стороны?

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

43. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Аноним (??) on 10-Май-17, 04:40 
Ага, особенно умиляет отсутствие упоминания конкретного интерпретатора — вы хоть, надеюсь, не будете утверждать, что что-то сэкономили за счёт использования апстримного питона?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

78. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Comdiv (ok) on 10-Май-17, 18:09 
Можете рассказать, какова была методика оценки экономии?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

99. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Вареник on 11-Май-17, 10:24 
> Java давно не торт. Мы всем отделом (200 человек) переписали наш софт
> на Python и сэкономили за год $1.5 млн. Python выигрывает в
> скорости разработки, гибкости и поддержке.

Многократный бред и победа НЛП над разумом.

На питоне больше писанины тестов, больше дебагинга, хуже с фреймворками.
Где-то лучше с либами (научный софт), где-то хуже (серверный).

Т.е. вы поменяли шило на мыло, при этом вместо рефакторинга - все переписывая.
Но руководство проекта так всем запудрило мозги, что это расточительство сочли "экономией", да еще с подсчитанной цифрой (как будто рефакторинг без переписывания вышел бы дороже, что абсурд).

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

118. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +2 +/
Сообщение от КО on 11-Май-17, 21:36 
Экономия 625 баксов в месяц на программиста. Дешевы же програмеры на Питоне.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

134. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Аноним (??) on 16-Май-17, 22:28 
Вы сделали дополнительную работу - "переписали наш софт" и сэкономили?
Вы, все 200 человек, приплачивали за возможность писать на питоне?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –7 +/
Сообщение от Аноним (??) on 09-Май-17, 23:27 
Забавно смотреть на попытки расшевелить то что двигаться не способно от рождения. Раскол уже на принятии решения, надо думать что потом будет если примут. Потом думаю будет Go или Rust.
С другой стороны, жалко немного Жабу. Многому она меня научила. Свой первый серьезный проект я сделал как раз на Java.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 00:13 
Если они не угадают - будет не Go и не Rust, а .NET, так что лучше уж пусть осторожничают
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

25. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Аноним (??) on 10-Май-17, 01:49 
Судя по массовому вовлечению разработчиков со стороны создателей языка и дикому восторгу хипстеров от айти, скорее таки go.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

96. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –2 +/
Сообщение от Вареник on 11-Май-17, 10:15 
> Судя по массовому вовлечению разработчиков со стороны создателей языка и дикому восторгу
> хипстеров от айти, скорее таки go.

Ужас. Лучше уж .NET, если не Java.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

100. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Igor1986 email on 11-Май-17, 10:27 
> Забавно смотреть на попытки расшевелить то что двигаться не способно от рождения.
> Раскол уже на принятии решения, надо думать что потом будет если
> примут. Потом думаю будет Go или Rust.
> С другой стороны, жалко немного Жабу. Многому она меня научила. Свой первый
> серьезный проект я сделал как раз на Java.

Да не переживай ты так за Java, она будет живее всех остальных живых!!!

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +2 +/
Сообщение от mimocrocodile on 09-Май-17, 23:31 
сколько они лет уже этот jigsaw теребят?
микрософт уже успел .net опенсорснуть и под линукс выпустить.
воистину https://en.wikipedia.org/wiki/Design_by_committee
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Avator (ok) on 10-Май-17, 01:59 
Можно поинтересоваться причем тут .Net.
При том что под Linux похоже его используют три калеки (и не так уже  важно OpenSource он или нет).
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –4 +/
Сообщение от Аноним (??) on 09-Май-17, 23:47 
Как на JVM выполнить аналог питоновского :
python -m SimpleHTTPServer 8080
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +5 +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 00:14 
Не надо ездить на карьерном самосвале за хлебом. На легковушке, впрочем, тоже щебень возить не стоит.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

17. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Аноним (??) on 10-Май-17, 00:53 
В смысле сервера не надо писать на Java? Да вы не Crazy а Mad или Nut.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

27. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –2 +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 01:59 
В смысле джава - не для "simple server". И вообще не для simple. А вот в сложных вещах ей самое место.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

38. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +6 +/
Сообщение от Аноним (??) on 10-Май-17, 03:54 
Ну и дурик ты.
groovy -l 80 SimpleWebServer

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

56. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 10:46 
Java от Groovy не отличаем?
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

59. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +4 +/
Сообщение от Аноним (??) on 10-Май-17, 10:59 
> Java от Groovy не отличаем?

Вопрос был про jvm, а не именно про жабу, так что проходи мимо

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

62. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 11:53 
Хм, да, чего это я. Впрочем, на кой так извращаться - всё равно не понимаю. Энтерпрайзы с десятками миллионов строк, тысячами типов бизнес-объектов, навороченной бизнес-логикой, масшатабированием и т.д. - понятно, там стерпишь и многословность, и потерю производительности - лишь бы этой горой кода хоть как-то управлять. А однострочник...
Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

65. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +2 +/
Сообщение от Аноним (??) on 10-Май-17, 12:55 
Твоё узкое мировоззрение не позволяет адекватно смотреть на факты
Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

69. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Аноним (??) on 10-Май-17, 14:05 
> Твоё узкое мировоззрение не позволяет адекватно смотреть на факты

Часто повторяемые мантры "жабка/JVM НЕ ТОРМОЗЯТ" еще не факты и на реальность не влияют.


Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

79. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от iZEN (ok) on 10-Май-17, 20:35 
Какими конкретными программами на Java ты пользовался?

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

127. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от symply (ok) on 13-Май-17, 07:10 
Например, Windchill.
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

126. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от й on 13-Май-17, 01:57 
Caught: java.io.FileNotFoundException: /Users/me/SimpleWebServer (/Users/me/SimpleWebServer)
Groovy Version: 2.4.11 JVM: 1.8.0_131
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

52. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Аноним (??) on 10-Май-17, 09:39 
Типичный Java программист. Нехрена не знает языка, зато считает что именно на нем должны писаться сложные вещи.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

63. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 11:55 
Я сишник, мне можно :-) А говорю о том,ч то вижу кругом, в кровавых энтерпрайзах... Большое пишется либо на джаве, либо на C#, всё остальное и 10% хором не наберёт.
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

72. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от QuAzI (ok) on 10-Май-17, 15:01 
Ты, конечно, про большие распилы, а не ехать?
Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

75. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 16:41 
Я про ехать. Джава - довольно простой, но громоздкий язык, и всё там такое же. На любой чих будут простыни - но в этих простынях редко бывает что-то сложное. Простой (хоть и объёмный) код, готовая поддержка жизненного цикла, саппорт со стороны больших контор, поддержка средствами разработки, стабильная экосистема с горой софта любых масштабов, куча разрабов достаточного уровня по цене, которую массовый заказчик готов платить. Для больших проектов это важнее, чем эффективность языка. Потому что одно дело - если тормозит, другое - если не взлетело вообще.
Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

102. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Igor1986 email on 11-Май-17, 10:30 
> В смысле сервера не надо писать на Java? Да вы не Crazy
> а Mad или Nut.

на Java стоит писать сервера!!! Как бы там не гавкали, Java всем покажет ещё зубы, на что она способна!!!!


Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

47. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +5 +/
Сообщение от лютый жабист__ on 10-Май-17, 06:46 
"Как на JVM выполнить аналог питоновского"

Написал бы, что оно делает. Ну, вебсервер на 8080 порту запускается и что он делает? Ничего? И?!

Формально, в javaEE пустой сервлет тоже не надо кодить, только проект создать в IDE и артифакт. Несколько секунд. Этим надо гордиться?

Я лично жабку люблю не за пустой вебсервер за 1 секунду, а за то, что я за несколько часов могу сделать backend который будет сервить данные из базки под терабайт для нескольких килоклиентов с временем ответа в единицы милисекунд. Без ЛАМПовых костылей в виде memcached, redis итд И что когда моя контора дорастет до хайлоада, я на той же жабе буду делать распределенные системы. Может и питон это может, флаг в руки, мне не жалко.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

74. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от anonymous (??) on 10-Май-17, 15:44 
> могу сделать backend который будет сервить данные из базки под терабайт для нескольких килоклиентов с временем ответа в единицы милисекунд. Без ЛАМПовых костылей в виде memcached, redis итд И что когда моя контора дорастет до хайлоада, я на той же жабе буду делать распределенные системы.

рецепт дадите? может я что-то не знаю про жабу... чем вы замените кеши типа memcасhed/redis? как вы впилите горизонтальное масштабирование? я создаю горизонтально масштабируемые системы но не на жабе, можете объяснить как это сделать на жабе простыми словами и конкретными примерами?

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

83. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Dmitry77 (ok) on 10-Май-17, 22:54 
Задавайте конкретные вопорсы вам ответят.
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

104. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от anonymous (??) on 11-Май-17, 10:33 
конкретные вопросы как храните данные, как масштабируете хранение данных, как добаляете сервера хранения данных в подсистему хранения, как исключаете сервера хранения данных из подсистемы хранения данных, как перераспределяете данные в подсистеме хранения данных?

сам серверный код можно на чем угодно писать, но залог производительности в масштабируемости. как масштабировать хранение данных? что используют в java те кто как утверждается пишут на ней hiload?

SQL со своими велосипедами роутинга и шардирования но с транзакциями и локами?
mongodb без транзакций и локов но с шардированием?
cassandra с brain split?
что-то свое волшебное?

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

109. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Igor1986 email on 11-Май-17, 11:09 
> SQL со своими велосипедами роутинга и шардирования но с транзакциями и локами?

В наши дни пока SQL играет немаловажную роль, он вроде не такой уж сильно загроможденный, даже XQuery XPath почему-то больше времени занимают, у них свои характеристики работы.


Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

111. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от лютый жабист__ on 11-Май-17, 11:51 
> конкретные вопросы как храните данные, как масштабируете хранение данных, как добаляете
> сервера хранения данных в подсистему хранения, как исключаете сервера хранения данных
> из подсистемы хранения данных, как перераспределяете данные в подсистеме хранения данных?

Это не конкретные вопросы. Данные в жабе не храним, ей их обрабатываем. Упарываться по транзакционности стараемся не. 8) Поэтому в основном Монго.

Кстати, для особенно кровавых ынтырпрайзщиков в жабе есть спецификация JTA на тему распределенных транзакций. Можно взять данные в Postgres, обработать, положить в Oracle в рамках атомарной операции. На Пистоне так можно?

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

113. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от anonymous (??) on 11-Май-17, 13:03 
те ваш ответ JTA это серебрянная пуля для hiload, так?
Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

110. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от лютый жабист__ on 11-Май-17, 11:43 
>чем вы замените кеши типа memcасhed/redis

В качестве локального кеша банальный HashMap просто разрывающе быстрее и удобнее.
FastUtil ещё быстрее, заметно экономнее с ОЗУ с примитивными типами.

Распределенный кеш - Infinispan есть в моём AS. Куча других нативных решений.

В чём заключается незаменимость redis? Кеш как внешнее решение это просто нонсенс.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

112. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от anonymous (??) on 11-Май-17, 13:02 
>Кеш как внешнее решение это просто нонсенс.

кеш как внешнее решение необходимость для доступа к одному кешу из множества воркеров

Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

128. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от yo on 14-Май-17, 03:46 
Описанная конфигурация - не highload. Распределять и масштабировать (в JVM) ничего не нужно на таких нагрузках. Кешей хватает внутренних. А все упомянутые вами инструменты появляются на более высоких нагрузках, и там у Java все как у всех. Никакой магии.
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

54. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от MVK (??) on 10-Май-17, 10:31 
HttpServer server = HttpServer.create();
server.bind(new InetSocketAddress(8080), 0);
server.createContext("/", new SomeHandler())
server.start();
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

66. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Аноним (??) on 10-Май-17, 12:57 
Думал, запустите этот сервер на питоне. Он там еще сервит файлы в текущй папке.


Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

70. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Ан (??) on 10-Май-17, 14:22 
Проще говоря занимается не тем чем должен. :)
Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

76. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 16:49 
>>> python -m SimpleHTTPServer 8080
>> Он там еще сервит файлы в текущй папке.
> Проще говоря занимается не тем чем должен. :)

А чем должен заниматься _простой_ httpserver? Неужели только жрать ЦПУ и раму, но абсолютно ничего не делать? o_O


Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

119. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от КО on 11-Май-17, 21:40 
$CATALINA_HOME/bin/startup.sh :)
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +3 +/
Сообщение от Аноним (??) on 09-Май-17, 23:51 
Перевожу бекенд с Java на D, ИМХО в плане С-синтаксиса альтернатив нет. А жаль
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +3 +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 00:16 
Вау, и как? Неплохо было бы услышать о практическом опыте. В идеале - в виде статьи...
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

18. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от D on 10-Май-17, 01:03 
D торт, на мой взгляд незаслужено замалчиваемый, для веб есть vibe.d который уделывает ноду, из минусов - парадигм много - как следствие куча вилосипедов с разными парадигмами, кто-то предпочитает писать либы без изключений, кто-то наборот. Таких удобных шаблонов нигде не видел (из компилируемых). Кранее время наблюдается появление в С++ иногих фич из D, но по мощи шаблонов С++ до D далеко.

Например на этапе компилицяци считать файл в строку

auto fileContent = import("some_file.data");

Распарсить, и динамически сформировать какой либо код

char[] generatedCode = ...

Подключить сгенерированый код

mixin(generatedCode);

Этот код будет скомпилирован так же как весь остальной написаный вручную

Симпатичен Go пробовал на нем писать, рулит для написания небольших демонов, статическая линковка в 1 бинарь, хотелось бы такое в D, но после D никак не идет, многословен

Пробовал Rust - замудреный, но хотелось бы возможности в D иметь подсчет ссылок вместо GC

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Ан (??) on 10-Май-17, 01:25 
> Пробовал Rust - замудреный, но хотелось бы возможности в D иметь подсчет ссылок вместо GC

Там есть весьма интересная штука Rocket. Хотя он написан с использованием фич из nightly. А сама замудрённость не проблемна как мне кажется.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

34. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от D on 10-Май-17, 02:36 
>> Пробовал Rust - замудреный, но хотелось бы возможности в D иметь подсчет ссылок вместо GC
> Там есть весьма интересная штука Rocket. Хотя он написан с использованием фич
> из nightly. А сама замудрённость не проблемна как мне кажется.

Rust многословен, на то время что я его смотрел не было аналогов mixin, static if из D

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

29. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +1 +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 02:04 
Что такое D я и сам могу рассказать :-) Интересен опыт его внедрения в реальной системе, о описанием плюсов, граблей и способов их обхода.

А так - да, пул потоков из двадцати строчек, мини-орм из сотни и так далее - писал, и было на редкость приятно. Вот vibe.d как-то не оценил, роутер был какой-то совершенно убогий. Но давно это было, там наверняка давно допилили его. По сравнению с плюсами, конечно, небо и земля - писать проще, гибкость больше. Один UFCS чего стоит.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

33. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от D on 10-Май-17, 02:34 
Все что нужно есть так или иначе, на крайняк можно прикрутить 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 подобный, шаблоны компилятся вместе с проеком =)

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

36. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Crazy Alex (ok) on 10-Май-17, 02:53 
Хм, ясно, спасибо
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

94. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Вареник on 11-Май-17, 10:06 
Интересный эксперимент. Но после Вас все это придется переписывать, рано или поздно.

Как это обычно бывает. Посмотрят на количество велосипедов и...

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

8. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от vitalif (ok) on 09-Май-17, 23:55 
jigsaw это наконец-то разделяемые библиотеки для явы?

блин, да дайте две, нет, дайте стопицот!!! зачем отменили, гады!!!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Sw00p aka Jerom on 10-Май-17, 00:20 
чтобы бардака как в случае js не было
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

21. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Ан (??) on 10-Май-17, 01:21 
Там как раз бардак начался из-за отсутствия стандарта.
И Java судя по статье в не меньший бардак способна скатиться учитывая JBoss Modules, OSGi.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

9. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 00:12 
Java - серьезный продукт для серьезных решений.
Никаких недоделок не должно быть.
За это я его и уважаю и буду сидеть на нем еще 100500 лет  ))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

61. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +4 +/
Сообщение от Аноним (??) on 10-Май-17, 11:43 
... кроме тех, которые нужны для совместимости
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

44. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 04:45 
Всё правильно сделали. Что Jigsaw — зашквар, стало ясно уже когда при обсуждении спецификации полностью проигнорировали OSGI. Рейнхольда — на мыло!

Интересно, а почему голосование происходит только сейчас? Либо Оракл просто использует эту кашу как предлог не мержить ветку jigsaw (т.е. решение не релизить его было принято уже давно), либо у них всё так плохо с коммуникацией внутри коммитета, что это уже не смешно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

57. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 10:55 
так Oracle вроде как проголосовал "ЗА". Позиция RedHat в принципе понятна, им придется пилить прослойку для совместимости с JbossModules (если они именно "развалятся" из-за jigsaw). А вот позицию IBM еще бы понять... Скорее всего, там тоже что-то не так с каким-то из их продуктов
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

60. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +2 +/
Сообщение от Аноним (??) on 10-Май-17, 11:39 
Естественно "ЗА", - кто в здравом уме признается в некомпетентности своих разработчиков?

И дело здесь вовсе не в политике (вообще). 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 в разных класслодерах), сломали, задокументировали это как ожидаемое поведение, и делают вид, что так и надо.

Эту хрень нужно не временно отклонять до пересмотра, а выкидывать нахрен из языка, пока оно там не укоренилось и не начало давать метастазы.

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

64. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 12:03 
хз, я читал и положительные и отрицательные отзывы на этот jigsaw. нужно оно в таком виде или нет - сказать сложно. да и большинства разработчиков все эти недостатки коснуться не должно. в любом случае, если его улучшат, пусть даже ценой задержки релиза - я не против. а если его выкинут... что тогда вообще в java9 останется?
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

68. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +/
Сообщение от Аноним (??) on 10-Май-17, 13:41 
"Большинство разработчиков" обнаружат, что

1. setAccessible не работает
2. Unsafe накрылся медным тазом (а вместе с ним и все либы, которые его используют)
3. Ресурсы из других модулей не читаются
4. bootclasspath исчез *без какой-либо альтернативы* (вместе с rt.jar)
5. Встроенные класслодеры больше не наследуются от URLClassLoader

И выключат jigsaw куда-подальше (если будет соответствующий переключатель). Или останутся сидеть на Java 8. Единственная полезная фича jigsaw - возможность изоляции модулей друг от друга. Но ни всего вышеперечисленного, ни множества других багов (см. ссылку) оно не стоит.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

93. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Вареник on 11-Май-17, 10:00 
> Интересно, а почему голосование происходит только сейчас? Либо Оракл просто использует
> эту кашу как предлог не мержить ветку jigsaw (т.е. решение не
> релизить его было принято уже давно), либо у них всё так
> плохо с коммуникацией внутри коммитета, что это уже не смешно.

Архитектурные решения были приняты два-три года назад, но откатить их решили когда вся JSR имплементирована. Это что-то эпичное.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

67. "Исполнительный комитет JCP не утвердил модульную систему в J..."  +2 +/
Сообщение от iZEN email(ok) on 10-Май-17, 13:29 
Модуль в Java - это .class файл, бинарник. Ничего выдумывать не надо. Всё остальное - перепаковка.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

81. "Личное мнение о Java 9"  –1 +/
Сообщение от Igor1986 on 10-Май-17, 21:15 
Сколько паники вокруг 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, приспосабливаться нужно ко возможным изменениям.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

84. "Личное мнение о Java 9"  –2 +/
Сообщение от Dmitry77 (ok) on 10-Май-17, 23:05 
одно из главных проимуществ java - обратная совместимость. вы можете взять класс скомпилированный 20 лет назад и запустить на современной JVM. "приспосабливаться" - это значит ценность в java заметно уменьшится.
Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

86. "Личное мнение о Java 9"  –1 +/
Сообщение от лютый жабист__ on 11-Май-17, 08:29 
> одно из главных проимуществ java - обратная совместимость. вы можете взять класс
> скомпилированный 20 лет назад

Есть официальная статистика скольким это надо, запускать классы 20летней давности?

"главное проимущество" по идее, это то что надо большинству. Соответственно, плюсы жабы совсем в другом.


Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

88. "Личное мнение о Java 9"  +/
Сообщение от Igor1986 email on 11-Май-17, 09:18 
>> одно из главных проимуществ 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 - эти языки пригодны сейчас в том, в отношении чего они применяются, может область их применения со временем расшириться, я только ЗА.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

89. "Личное мнение о Java 9"  –1 +/
Сообщение от Igor1986 email on 11-Май-17, 09:40 
Я даже признаю и вижу, что Java "нуждается" в свежем глотке новизны, НО... но это не значит, что ORACLE перечеркнет всё, за счёт связанного на Java API работало и запускалось.

Я обязательно буду отслеживать и наблюдать за Eclipse Foundation, каковы будут их меры и действия касаемо предвещаемых "Jigsaw улучшений" и модульности Java 9.

Товарищи не паниковать!!!

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

92. "Личное мнение о Java 9"  –1 +/
Сообщение от Вареник on 11-Май-17, 09:55 
>> одно из главных проимуществ java - обратная совместимость. вы можете взять класс
>> скомпилированный 20 лет назад
> Есть официальная статистика скольким это надо, запускать классы 20летней давности?
> "главное проимущество" по идее, это то что надо большинству. Соответственно, плюсы жабы
> совсем в другом.

Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с написанием (или переписывать на новое API, или заново отлаживать, с новыми глюками) - не каждому бизнесу понравится. С#, Qt, Python считают нормальным переписывания, Java для тех кто ценит уже потраченные усилия.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

120. "Личное мнение о Java 9"  –1 +/
Сообщение от лютый жабист__ on 12-Май-17, 05:32 
> Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с
> написанием (или переписывать на новое API, или заново отлаживать

Давай не будем передергивать и искажать. Ранее было сказано про код 20 летней давности в СКОМПИЛЕННОМ виде. Я далёк от больших ынтырпрайзов, но по прежнему уверен, что 20летний JAR это не необходимость, а просто кусок мамонтового Гэ, от которого потеряли сорцы и/или документацию.

На "главный плюс жабы" ваще не тянет. Рефакторинг полезная штука, хоть и стоит денег.


Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

121. "Личное мнение о Java 9"  –1 +/
Сообщение от Igor1986 email on 12-Май-17, 09:15 
>> Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с
>> написанием (или переписывать на новое API, или заново отлаживать

Далеко не каждому в кайф переписывать заново API(для не знающих что это такое, - Application Programming Interface - интерфейс прикладного программирования), сколько бы разработчику ни заплатили за написание новой lib (библиотеки), разработчик не может гарантировать, что даже в хорошо и благополучно написанной библиотеке не будет крахов или каких-то других проблем.

Рефакторинг(профилирование кода) штука очень полезная, но и она требует от Java программиста немало усилий по достижению результата.

Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

122. "Личное мнение о Java 9"  –1 +/
Сообщение от Igor1986 email on 12-Май-17, 10:16 
> Смотря сколько у вас кода. Реинвестировать каждые 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.  

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

124. "Личное мнение о Java 9"  +/
Сообщение от Аноним (??) on 12-Май-17, 20:01 

> Java более длительно не изменяющаяся, но и в этом есть плюс, мне
> не нужно без конца перестраиваться на новый выпуск с учётом нововведений
> как в случае у тех, кто с Python работает.

Ох уж эти жабисты. Во первых, обратную совместимость в питонах никто не ломает.
Во вторых, какие-то уж очень странные у вас питоны. Вы точно о ЯП, а не об одной из кучи библиотек?
Ну и наконец, сравнение фиолетового с яблочным.
Питон – это в первую очередь скрипты и прототипы, от силы на несколько тысяч строк.
Это как с мултитулом. Подкрутить им что-то по мелочи будет быстрее, чем сбегать за ящиком с инструментами, но вот чинить или разбирать что-то всерьез – увольте. Хотя любители находятся, да.

Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

105. "Личное мнение о Java 9"  –1 +/
Сообщение от Вареник on 11-Май-17, 10:38 
> Есть официальная статистика скольким это надо, запускать классы 20летней давности?

Каждая платформа обрастает экосистемой библиотек. Если либа не изменялась 5-10 лет - это не значит что она устарела, она может быть даже единственным (уникальным) решением какой-то проблемы.

Если либами нельзя пользоваться толькоп потому что е постоянно (каждый год) не майтенят... то это сильный минус всей платформе. Хотя для бюджета IT департаментов может и хорошо, когда языки совместимость ломают - объем работ на ровном месте больше, там переписать, там заново все тестировать...

Но большие корпорации, уровня IBM-Oracle, не любят кидать на деньги сами себя, поэтому используют стабильную платформу - JDK.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

107. "Личное мнение о Java 9"  –1 +/
Сообщение от Igor1986 email on 11-Май-17, 10:53 
> Но большие корпорации, уровня IBM-Oracle, не любят кидать на деньги сами себя,
> поэтому используют стабильную платформу - JDK.

Ты всё правильно сказал относительно IBM и ORACLE, JDK как-никак "рулит", без JDK никуда!!!

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

82. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Igor1986 on 10-Май-17, 21:27 
В дополнение скажу, не только с Джава на Питон, но и на другие языки. Рэд Хэт уж точно не факт что примется потратить время на переписывание своих систем.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

85. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Dmitry77 (ok) on 10-Май-17, 23:07 
Зачем  нужен Jigsaw, когда есть OSGI ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

87. "Дмитрий, доброе время суток"  +/
Сообщение от Igor1986 email on 11-Май-17, 08:41 
Дмитрий, я тоже с Вами согласен, есть 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.
Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

115. "Дмитрий, доброе время суток"  –1 +/
Сообщение от iZEN (ok) on 11-Май-17, 20:35 
>[оверквотинг удален]
> дистрибутива, как для Java, так и для С/С++, и прочее), поскольку
> для запуска и нормального функционирования таких как Eclipse IDE и даже
> тем, кто до сих пор с NetBeans необходим JDK. Почему я
> заговорил об этом, потому что сильные изменения могут нехорошо сказаться на
> всю Eclipse Platform. Но я думаю, что сейчас пока не стоит
> паниковать из-за Java 9, первое что могу сказать, - размер загружаемого
> JDK с может увеличиться со 190 МБ до 200 с копейками
> МегаБайт, ORACLE сама применяет в своих продуктах Java, думаю они там
> не дураки, чтобы в один миг отказаться от того, что было
> в Java 7, 8.

Предварительную версию JDK 9 ещё не смотрели? Тут она: http://jdk.java.net/9/
Там уже всё "модульно" и работает.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

123. "iZEN доброго времени суток!!!"  –1 +/
Сообщение от Igor1986 on 12-Май-17, 19:29 
По поводу 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истам в руки и вперёд!!!! С Уважением, Игорь.
Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

129. "трындец"  –1 +/
Сообщение от yo on 14-Май-17, 04:05 
Столько радости по поводу Eclipse IDE я давно не видел. Переходите, Игорь, поскорее на IntelliJ IDEA, вообще в экстазе забъетесь ))). И новая JDK туда подключается пятью кликами мышки вне зависимости от того, где JDK лежит и у кого права администратора. (Справедливости ради, и в Eclipse и в NetBeans, думаю тоже легко подключить JDK откуда угодно, но я с ними давно уже не работал)
Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

91. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Вареник on 11-Май-17, 09:50 
По хорошему надо было объединить OSGI и JDK, а не строить модульностью отдельно.

У них была светлая идея сделать модули - deb пакеты (в формате deb), не понятно зачем это Java. Теперь вообще финт ушами, два года делать, сделать и решить не релизить.

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

125. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Igor1986 email on 12-Май-17, 21:57 
> По хорошему надо было объединить OSGI и JDK, а не строить модульностью
> отдельно.
> У них была светлая идея сделать модули - deb пакеты (в формате
> deb), не понятно зачем это Java. Теперь вообще финт ушами, два
> года делать, сделать и решить не релизить.

deb пакеты - да, это странно, НО... для Линукс есть rpm пакет, но дело в том, что этот рпм как и установочный файл для Windows, - jdk8u121-windows-i586.exe служит для процесса установки в ОС (Операционной системе). Следует обратить внимание, что пакеты в Java не одно и то же что rpm, Java packages служат для запаковки Java классов и установления пространства имён и видимости классов.

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

90. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Вареник on 11-Май-17, 09:47 
Отменить модульность за месяц до релиза? Они охренели...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

98. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Igor1986 email on 11-Май-17, 10:23 
> Отменить модульность за месяц до релиза? Они охренели...

Ты обрати внимание, выпуск Java 9 в который раз "переносится", я уж сам думал что начну знакомиться с вкусностями Java 9, дабы понимать, что делать дальше, а тут получается опять "сдвиг" по графику аж на конец июля 2017(и это при условии, что JSR 376 таки одобрят), я пока применяю jkd8u121, - эта версия обновления очень даже чудненько работает.

Мне не менее важно будет пронаблюдать за тем, что Eclipse Foundation будет предпринимать в связи с такими неизбежными Java 9 "улучшениями".


Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

101. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Вареник on 11-Май-17, 10:29 
>> Eclipse Foundation

За 15 лет работя с явой так и не понял этого IDE. NetBeans нормально, IDEA нормально, а Eclipse... не понимаю этого интерфейса, по мне - все неудобно сделано.

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

106. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Igor1986 email on 11-Май-17, 10:43 
>>> 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) нативных функций к самой ОС, что должно давать более быстрые результаты.  


Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

130. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от yo on 14-Май-17, 04:15 
Вам похоже шашечки, а не ехать... Но хотя бы не обманывайте себя - одинаково эклипс выглядит и на винде и в линуксах и в макоси. Так что смысла от того, куда идет какое обращение не много. Быстрее ИДЕИ он если и работает, то не из-за обращения к ОС напрямую, а из-за отсутствия большого количества вспомогательных индексов которые ИДЕЕ позволяют ускорять разработчика.


Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

131. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от iZEN (ok) on 14-Май-17, 17:48 
>>> Eclipse Foundation
> За 15 лет работя с явой так и не понял этого IDE.

Сколько ни пробовал разных версий IDEA, но не понял логику контекстных меню в этой IDE. Похоже на то, что об уместности и перечислении пунктов команд меню, возникающего по клику над местоположением курсора мыши, никто не думал. Кроме этого, IDEA часто виснет после нескольких запусков простых проектов - приходится убивать процесс самой IDE и запускать снова.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

103. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Вареник on 11-Май-17, 10:32 
> Ты обрати внимание, выпуск Java 9 в который раз "переносится", я уж

Да, учитывая что они задержали релиз на год, ради модульности...

Такая непоследовательность может вызвать только недоумения.
Но если предложенная модульность не дружит с OSGI - то лучше ее выкинуть, в этом они поступили мудро. Но не понятно почему так запоздало.

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

108. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от Igor1986 email on 11-Май-17, 11:02 
> Такая непоследовательность может вызвать только недоумения.
> Но если предложенная модульность не дружит с OSGI - то лучше ее
> выкинуть, в этом они поступили мудро. Но не понятно почему так
> запоздало.

Для меня их запоздалость уже не удивление!!!Но всё же ждём вестей, как говорится!!!

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

116. "Исполнительный комитет JCP не утвердил модульную систему в J..."  –1 +/
Сообщение от iZEN (ok) on 11-Май-17, 20:45 
>> Отменить модульность за месяц до релиза? Они охренели...
> Ты обрати внимание, выпуск 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 никак не конфликтуют. А бажность эклипсовского фреймворка, когда внезапно после обновления среды оказывается, что модули почему-то не той системы/версии не работают в ней - известная проблема.

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру