Как стать автором
Обновить

Комментарии 51

«Jigsaw» — обычно означает пазлы, но здесь, скорее всего, имеет место второе значение — лобзик (пила), из-за разделения на части. Релиз, кажется, на год задержали или больше?
Как раз элементами пазлов обычно и представляют модули. Так что пазл — самое то.
Но ведь только лобзиком можно что-то запилить или выпилить
поэтому головоломка и называется Jigsaw puzzle — распиленная головоломка.
в том то и дело, что речь не о самих модулях, а о процессе разделения платформы на части
ну тогда это слово стоит воспринимать как глагол: лобзикование.
Вот да :) Всё-таки чисто лобзик — достаточно многогранная штука.
ну почемуже.
именно пазлы имеется в виду.
разбиение на кусочки.
ИМХО
Пазл тут вполне себе в тему, т.к. как раз разделено уже на части и больше отражает суть, чем лобзик. Лично у меня лобзик вообще ассоциируется с уроками труда, а отнюдь не с разделением на части.

Чуть больше года, насколько я помню. Переносы с прошлого лета пошли.
Благодарю за статью!
А можно рассказать о причинах перевода термина " logging" как протоколирование?

P.S.: Пишу не в личку, поскольку считаю причины выбора такого перевода полезными не только для меня.
А можно рассказать о причинах перевода термина " logging" как протоколирование?

А у вас какие предпочтения? Регистрация? Журналирование?
Для этих двух вариантов есть омонимы, которые вспоминаются сходу.
А для «протоколирование» я омонима даже и не вспомню.
логгирование, например.
Хм. Внезапный вопрос… Вообще просто чаще используется в работе, поэтому привычнее протоколирование, чем, например, прямая транслитерация.
Принято, спасибо.
Сначала прочитал Jshell как JS Hell, а не J Shell…
Плюсанул бы, если б мог.

Отличное название, я считаю.
И так недостаточно людей в околопрограммистской тусовке путают Java и JavaScript.
«А Слава КПСС — это вообще не человек...»
уже репер=человек
Попробуй прочесть KeePass.
Всё б хорошо, да только я так понимаю пользовательских value type так и нет? В Swift они есть. Я всегда предпочитал C# во многом из-за этого, но что мне не нравилось, что там константы возможны лишь для предопределённых типов. Ещё не совсем освоил Swift, особенно новинки 4-го, но, там, кажется со всеми этими моментами порядок. Java по мне определённо хорош классическим синтаксисом, а в C# зато обработка исключений сделана мягко говоря не лучшим образом, но в плане возможностей на фоне Swift 4 по мне это меркнет.

Хотя, кажется, появляются ещё какие-то языки программирования, что я ещё освоить не успел. У понравившегося мне в своё время D чувствую шансов прижиться уже немного, но, впечатление, что улучшенные варианты уже есть. Вот только упомянутое в начале ограничение, насколько я понимаю, относится ко всему JVM.

У D вылезти на большую арену шансов уже очень мало. Особенно учитывая, что он не смог это сделать за полторы декады.

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

Т.е. вы это на полном серьезе утверждаете? Что только Java 8-й версии «предоставила разработчикам возможность создавать решения для самых разных секторов бизнеса, включая финтех, здравоохранение и другие индустрии.»? FacePalm… Маркетологи погубят этот мир…
Можно ли запустить java9 на windows xp?
Вот не пробовали, если честно :) А это актуально?
Да
А для чего?
хотя, быть может, альтернативные реализации и смогут.

Я слышал, что с выходом Java 9 появится AOT-компиляция. Она в итоге появилась или я что-то напутал?

Ahead Of Time Compilation (AOT) openjdk.java.net/jeps/295 действительно попала в java9, и доступна сейчас в OpenJDK jdk.java.net/9
Это статическая компиляция java кода в нативный

В последней сборке Oracle JDK (9.0.1) AOT отсутствует
Утилита называется jaotc
На телефонах Nokia была похожая вещь. Они компилировали jar и потом пускали бинарники. Это мягко говоря было ужасно.
НЛО прилетело и опубликовало эту надпись здесь
Еще о новшествах: где скачать Java9 JDK для 32bit windows?
Официально, вероятно, нигде.
И под ARM-ы не будет?
Я так понял что java9 это не LTS, а морковка. Т.е. переходить на неё не стоит, надо подождать нормальную версию или использовать проверенную.
image
после 9й все релизы будут частыми.
Официального 32bit JDK нет. Можно попробовать собрать самому как советует Марк Рейнхольд.
Для кого эта статья? Если для программистов, то неплохо было бы привести примеры кода «до» и «после».
Это обобщённая статья для всех и, разумеется, не последняя. В следующих как раз рассмотрим практические примеры по разным аспектам
>и, разумеется, не последняя

Надеюсь последующие статьи будут писать не маркетологи, а технари…
G1, который был представлен в Java 7 и был разработан для лучшей поддержки куч размером более 4GB. Он вызывает меньше GC пауз, но если они все же происходят, то длятся дольше.

ШТА?! G1 старается держать паузы предсказуемыми и их может быть больше или меньше в зависимости от параметра MaxGCPauseMillis. И эти паузы могут быть запросто меньше, чем в старых gc типа CMS. G1 на основе предыдущих сборок оценивает сколько регионов он сможет обработать при очередной сборке.

Стоит добавить, что чисто маркетоидное "http/2 быстрее" очень спорно. Особенно, если не уточнить в каком смысле и при каких условиях. Там в первую очередь интересна экономия сокетов, мультиплексирование, приоритизация мультиплексированных потоков, потенциальное уменьшение latency и server push.

http/2 у нас как раз в первую очередь пойдёт на отдельную заметку и практику. Так что там будет более подробно это раскрыто.
В рамках такой сравнительной статьи, разумеется, не хватает глубины по каждому пункту, но это поправим в следующих выпусках.

Это, извините, выглядит не как "не хватает глубины по каждому пункту", а как вопиющая некомпетентность. Как с тем же G1GC.

Вы не упомянули о переходе класса String на работу с byte[] вместо char[], что может существенно уменьшить JVM heap если символы в строках можно уместить по таблице ASCII по 1 byte.

Да, приятная штука. У нас потребление памяти на части софта упало на 10-20%.

CompressedOops уже были включены? Или не подходят по специфике?

Обычно да, кучи меньше 32 GiB. Если больше, то часто включены + увеличен ObjectAlignmentInBytes, но это бывает не сильно часто.

Какой выигрыш дают CompressedOoops в вашем кейсе, если не секрет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий