Java Microbenchmark Harness 1.12

mvnrepository.com

ОП, ты не местный что ли? Оф. поиск в центральном мавене живет по адресу search.maven.org . А мвнрепозитори - это левый сайтик от васяна, с кучей рекламы и обновляется через пень-колоду.

По сабжу - это очень сильное колдунство, но пользовать просто достаточно.

но версию 1.12 уже можно прописывать в pom.xml

Прочитал как:

но версию 1.12 уже можно прописывать в porn.xml

-____-

Так получилось, что у этого сайтика от Васяна очень высокий вес в Гугле, поэтому первые эдак 3 позиции поиска Гугла ведут на него. Возможно, это как-то связано с тем, что на search.maven.org совершенно упоротый поиск. Anyway, упоминание убрал, потому что всё уже проиндексировалось.

очень высокий вес в Гугле

Вся суть жабакодеров.

поиск на mvnrepository еще более упоротый кстати

Вот говорят, что Java — это самый популярный язык программирования в мире, а специалисты Java — получают самые большие зарплаты в отрасли.

Но мне довольно неловко становится, когда я слышу вышеуказанные вещи и вспоминаю еще никем не опровержимый факт того, что приложения на Java — долго запускаются, тормозят и потребляют много памяти, а GUI на Java — это просто кошмар.

Как соотносятся эти вещи, непонятно.

Вот говорят, что Java — это самый популярный язык программирования в мире, а специалисты Java — получают самые большие зарплаты в отрасли.

Как соотносятся эти вещи, непонятно.

Одно слово - «ынтырпрайз» :)

Месье много серверных приложений запускал на оной?

еще никем не опровержимый факт того, что приложения на Java — долго запускаются, тормозят и потребляют много памяти, а GUI на Java — это просто кошмар.

Ну тогда лови: «Java в современном мире используется только для server-side разработки»

P.S. Android ПОКА не Java

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

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

А то, что приложения на Java долго запускаются, (якобы) тормозят и потребляют много памяти означает лишь то, что их пользователей это устраивает и они не готовы платить больше денег, чтобы это исправить. JVM запускается доли секунды, всё остальное это уже на совести разработчиков. Ничего не мешает написать приложение, которое будет стартовать за доли секунды и не жрать память. Есть некоторые особенности JVM, которые объективно увеличивают потребление памяти в 2-5 раз в сравнение с идеально оптимизированным C++, например. Но в разумные рамки нескольких десятков мегабайтов можно уложить очень много функционала.

Звучит разумно, если постараться, то даже можно извлечь рациональное зерно.

JMH вообще клевый и незаменимый инструмент.

Что это за хрень и кому это вообще может понадобиться?

В общем, как всегда с новостями об OSS — либо это монстр вроде ff/oo/lo/kde/..., либо очередной плеер, либо непонятная yзкоспециализированная хрень, которая ещё и глючит (вспоминаем нейросеть от gnu). Тонны программ в репозиториях, говорили они. Ага, как же.

Очевидно, джавистам, которые не хотят, чтобы их приложения тормозили.
А о чем делать новости, если не об этом?

Гуй на джаве - нормальный, если его писали люди, хоть немного ппедставляющие, что они вообще делают.
А тормоза - в энтерпрайзе гигабайт не память, минута не время, вот и переносят привычки на гуй. Но, опять же, кроме tuxguitar и minecraft я прикладных юзерских приложений на джаве не знаю.

Eclipse, FreeMind, Vuze.
http://www.infoq.com/presentations/java-vs-c-performance

Eclipse - говно, в таком случае, я бы idea и netbeans использовал для лучшего примера. Freemind тоже довольно специализированная штука, как yed и gephi.
Vuze подойдет, вполне можно считать «софтом для обычного юзера»

[ПетросянMode=on] рот.xml

Так и скажи, что завидуешь.

приложения на Java — долго запускаются, тормозят и потребляют много памяти

Компания Васи написала корпоративный портал на Java, докупила необходимое для комфортной работы оборудование и уже заняла себе нишу, получая прибыль. Компания Пети, нанявшая себе менеджером проекта оторванного от реальности Кепа, все еще разрабатывает свою идеальную систему на чрезвычайно эффективных по производительности языках, которая года через три обязательно разуплотнит своим могуществом все окружающее пространство. Может быть. Если у компании деньги не закончатся.

Классическая сказочка, ты еще мне про разогрев спой.

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

какая разница сколько оно запускается. хоть минуту, хоть две. Если тебе нужно ребутать сервак чаще чем раз в неделю, с твоим кодом что-то не так.

Сами серверы, может, и нет (хотя если серверы с оплатой квантами меньше дня, то это совсем неправда), а приложения иногда обновлять хочется. Я считаю, что обновлять приложение несколько раз в день — это нормально, и далеко не всегда можно просто забить на время запуска.

Как соотносятся эти вещи, непонятно.

С Вашим ником, Кэп, стыдно не осознавать, что первое напрямую следует из второго :)

Но, опять же, кроме tuxguitar и minecraft я прикладных юзерских приложений на джаве не знаю.

Azureus же (который потом стал vuze). Я им даже когда-то пользовался, причём на довольно скромной по нынешним меркам машинке. Оперативку жрал только в путь, но работал довольно надёжно.

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

Он еще, поди, на говнод и быструю загрузку системы дрочит...

Похоже, что это десктопный одмин холокоста...

Во-первых есть штуки вроде JRebel, которые позволяют обновлять код без рестарта приложения в 99% случаев. Во-вторых можно поставить второй сервер (если у тебя критичное к аптайму приложение, это надо делать в любом случае) и перезапускать их по очереди.

Вот чего хотелось бы — чтобы в JVM из коробки была перезагрузка кода на уровне JRebel хотя бы, чтобы не нужно было платить лишних денег, это да.

в 99% случаев

ну это ты, мягко говоря, преувеличил :))

Не на уровне JRebel, но у JVM по дефолту очень хорошие возможности обновления кода. Если меняется код методов, без добавления функций/классов, то идея в режиме дебага автоматом обновит приложение по Ctrl+F9.

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

Нет, это не нормально. Так часто разве что UI меняется, шаблоны и прочий Javascript. А их можно при каждом запросе читать с диска, не впиливая намертво в classpath-ресурсы. Вот тебе и обновление без перезапуска.

Как минимум, DCEVM не умеет в Java8. Ваня что-то там пофиксил, но не до конца. Как простым способом сделать, чтобы всё работало - непонятно (если тебе понятно - расскажи). Пообщался с парой разработчиков JVM, их позиция (неофициальная) в том, что такая функнциональность должна делаться агентом, и помогать в улучшении DCEVM они не будут.

А кто хоть раз эту крутую штуку в жизни встречал?

Такое чувство, что она в первую очередь нужна для Java-докладчиков, чтобы вставить слайд «Используйте микробенчмарки, это круто!» А на практике и System.currentTimeMillis() вполне хватает.

Эх, фиговенько. Мне Java8 в таком разрезе не встречалась.

Не на уровне JRebel, но у JVM по дефолту очень хорошие возможности обновления кода. Если меняется код методов, без добавления функций/классов, то идея в режиме дебага автоматом обновит приложение по Ctrl+F9.

Вот это как раз таки очень слабо и такого хватит разве что на простейшие обновления кода. Кстати как оно вообще делается? Знаю, что в томкате такое есть, но как работает, пока не понимаю.

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

Речь о продакшне. Ну и непонятные проекты с непонятным статусом это совсем не то же, что официальный проект от производителя.

ну это ты, мягко говоря, преувеличил :))

Я JRebel активно использовал пару лет и у меня примерно такая статистика была. Очень редко приходилось перезапускать, в основном, когда менялись конфиги.

Пообщался с парой разработчиков JVM, их позиция (неофициальная) в том, что такая функнциональность должна делаться агентом, и помогать в улучшении DCEVM они не будут.

Плохая позиция, жалко, если так. На проект уровня JRebel коммьюнити не хватит, там много чёрного вуду, насколько я понимаю и даже с ним 100% релоад они не сделали. А фича для серверной жавы была бы ой как востребована.

Ну, как это работает внутрях внутрей — это фиг знает. Но в общих чертах примерно так.

JVM-щики решили не ограничиваться простым дебаггером «посмотрел значение + step into функция», а сбацали целый интерфейс для служебного общения с JVM, Java Virtual Machine Tool Interface. Тут тебе и нативные методы, и агенты, которые слушают эвенты, и сложный дебаг, благодаря которому можно гулять по стеку вверх-вниз (step-into/drop frame), логировать брекпойнты, вычислять произвольные выражения.

Еще этот TI позволяет обновлять информацию о классах:

http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses

Все, что уже вызвано со старыми классами, выполнится как есть. А вот новые вызовы функций получатся со свежим кодом.

Эти плюшки и используется в стандартной поставке IDE, но вот тут всплывают конские ограничения — сигнатуры не меняй, новых функций не накидывай, наследование не трожь. Фиг знает, почему Sun/Oracle такие ПДД установили, скорее всего, из-за потенциальных граблей с тредами, а если их решать, то куча проверок просадит производительность всей JVM.

Но. Это не жесткая спецификация, там есть пометка, что в будущем могут и убрать ограничения.

И тут весь в белом является DCEVM, который и дает кучу перегрузок. Он берет установленную JVM-ку, патчит ее, и появляется в системе еще один JDK, где из ограничений осталось только наследование, что можно пережить. Как понимаю, это сделал чуть ли не один человек, так что на продакшн тащить не стоит. Но при этом везде пишут, что работает все на удивление стабильно, и для девелопера это действительно так.

Но счастье это неполное. В Java куча всего работает в контекстах-контейнерах, Spring, Hibernate, Jetty, Tomcat, ... Обновили мы один класс, а спринг-то и не в курсе, что надо бы весь контекст по новой перестроить, бинов накидать.

Так что к столу присоединяется hotswapagent, http://www.hotswapagent.org/how-does-it-work . Он уже в курсе, кого нужно дергать в конкретной библиотеке при обновлении кода, так что получается практически лафа и коммунизм.

Расеянцы привет вам из стана индусов! Индусы любят жабу.

Я встречал, это больше для низкоуровневого кода, где не millis, а nanos надо мерять на вызовы.

Пасибки. Первый живой пользователь МБ.

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

Там из-за всяких приколов можно получить обратные данные при сравнении. Этот JMH и есть N-е поколение такого подхода в 100500-запусков, где за много лет разработки много граблей собрано и заюзаны вещи, про которые в курсе по большей части только сами разработчики HotSpot-а.

Собственно JMH больше разработчикам самой OpenJDK нужен, например в части стандартных коллекций. Если сам пишешь какие-нибудь коллекции, то это штука тоже пригождается.