Я слышал, груви попал в апачи фондейшн и там умер!

ну, @bsideup, думаю не согласится

я хз кто сейчас на груви пишет что-то, кроме флоу для дженкинса

ты забыл про билдскрипты для грейдла.

ты забыл про билдскрипты для грейдла.

есть же kts

ты забыл про билдскрипты для грейдла.

Ваша собака умеет делать больно иным способом!

есть же kts

ну он там мало чем отличается, по большому счету.

да и я бы не стал переписывать все билдскрипты на kt ради kt.

ну он там мало чем отличается, по большому счету.

так и не надо чтобы отличался) но уже не груви)

да и я бы не стал переписывать все билдскрипты на kt ради kt.

я бы вообще ничего не стал переписывать) но новое писать вполне)

ты забыл про билдскрипты для грейдла.

ну, учитывая что сейчас есть блю оушен

Про груви-то, про груви давайте!

На груви некоторые люди пишут скрипты

Например, я

Еще спок есть

Еще спок есть

вот это да, но я его только в петпроекты втянуть мог

Например, я

Please don't

а так есть кукмбер

А я в продакшен смог

а для спринга контекст описывать

на грувях

но помойму и там уже побывал котлин

но помойму и там уже побывал котлин

не видел

не видел

еще как есть, в 5ом, контекст на kotlin dsl

hi

Why string strings are immutable

Туда же. Правильно я понимаю, что lazySet — это не-volatile-чтение?

покопался в сорцах, на хотспоте судя по всему везде идет volatile, то есть никаких отличий нет

``` UNSAFE_ENTRY(void, Unsafe_SetOrderedLong(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jlong x)) UnsafeWrapper("Unsafe_SetOrderedLong"); #if defined(SPARC) || defined(X86) // Sparc and X86 have atomic jlong (8 bytes) instructions SET_FIELD_VOLATILE(obj, offset, jlong, x); #else // Keep old code for platforms which may not have atomic long (8 bytes) instructions { if (VM_Version::supports_cx8()) { SET_FIELD_VOLATILE(obj, offset, jlong, x); } else { Handle p (THREAD, JNIHandles::resolve(obj)); jlong* addr = (jlong*)(index_oop_from_field_offset_long(p(), offset)); ObjectLocker ol(p, THREAD); *addr = x; } } #endif UNSAFE_END ```

Чтобы не быть голосовым, выше подтверждение

И еще туда же: http://dev.cheremin.info/2011/10/atomicxxxlazyset.html

ну, @bsideup, думаю не согласится

Могу точно сказать что хуже проекту не стало =)

это как в пословице про припарку?

не, это как в мире который доверяет Apache Foundation (куда можно в любой момент денег занести) гораздо больше чем Pivotal. Такой мир ещё Enterprise Software называется =) Повалили как на горячие пирожки =)

тут одно время OCI че то притихли, я аж прям начал думать на тёмную сторону их переманили (ну, там, кококотлин например), ан нет, оказывается в тайне свой http://micronaut.io пилили. Идея compile time фреймворка давно уже в воздухе витает, вот походу у них получилось. А зная compile time фичи Groovy (включая ту, за которую меня в проект взяли) - это может быть очень быстро и легковесно. Я на всякий случай напомню правило "чем более динамичен язык тем больше вещей делается в compile time", как бы на первый взгляд это не звучало противоречиво

В Groovy можно делать всякие дикие штуки типа compile time JSON views. Например вот это я наваял на коленке (в прямом смысле слова, с ноутбуком на коленях) пока слушал Graeme по поводу нового Grails год назад на Greach conf: https://github.com/bsideup/macro-methods-workshop/blob/8119bace0775fce74c2a0f51ac42f2666cf8baaf/src/test/groovy/com/example/MacroJSONTest.groovy#L27 здесь "macroJSON" после компиляции заменится на конкатенацию строк. Фактически самый быстрый JSON генератор для JVM =)

в Java можно делать Dagger-ы всякие, но упираешься в ограничения annotation processing-а джавы. В Groovy compile time фичей ну просто на порядки больше, представьте сколько всего можно сделать при желании?

не смотря на то, что Groovy - самый "взрослый" альтернативный JVM язык, у него ещё многое впереди и некоторые его возможности начали по-настоящему раскрывать только недавно. Micronaut - лишь малый пример того, что можно сделать "не напрягаясь"

И еще туда же: http://dev.cheremin.info/2011/10/atomicxxxlazyset.html

Вот это интересно. Спасибо, теперь бы разобраться в этом)

В Groovy можно делать всякие дикие штуки типа compile time JSON views. Например вот это я наваял на коленке (в прямом смысле слова, с ноутбуком на коленях) пока слушал Graeme по поводу нового Grails год назад на Greach conf: https://github.com/bsideup/macro-methods-workshop/blob/8119bace0775fce74c2a0f51ac42f2666cf8baaf/src/test/groovy/com/example/MacroJSONTest.groovy#L27 здесь "macroJSON" после компиляции заменится на конкатенацию строк. Фактически самый быстрый JSON генератор для JVM =)

Где можно бенчмарки посмотреть?

Где можно бенчмарки посмотреть?

спроси у Шипилёва бенчмарки string concatenation на JVM

Где можно бенчмарки посмотреть?

А ты любитель побенчмаркать

А ты любитель побенчмаркать

А то, особенно если это касается json или вебсервера

Где можно бенчмарки посмотреть?

там реально на выходе будет код вида: var fooString = ... var myInteger = ... String result = "{\"foo\":\"" + escape(fooString) + "\", \"bar\":" + myInteger + "}"

спроси у Шипилёва бенчмарки string concatenation на JVM

Так json можно генерить без конкатенации строк

можно и без них, любой самый быстрый способ в JVM вернуть строку из нескольких строк

там реально на выходе будет код вида: var fooString = ... var myInteger = ... String result = "{\"foo\":\"" + escape(fooString) + "\", \"bar\":" + myInteger + "}"

Ну так это не так быстро как могло бы быть

Ну так это не так быстро как могло бы быть

я говорю о том, что любой, самый крутой runtime json генератор, проиграет, т.к. он будет байткод собирать в рантайме (даже если он генерирует байткод как оптимизацию), в то время как Groovy этот байткод в compile time подставит

тут уже выигрышь будет только на стадии инициализации, понятное дело

но поинт был именно в compile time подходе

я говорю о том, что любой, самый крутой runtime json генератор, проиграет, т.к. он будет байткод собирать в рантайме (даже если он генерирует байткод как оптимизацию), в то время как Groovy этот байткод в compile time подставит

Приду домой - буду бенчмаркать)

девушку тебе надо......

У меня есть

Приду домой - буду бенчмаркать)

я надеюсь ты не пойдёшь код по той ссылке бенчмаркать, там всё же PoC (вот в Grails по-моему они уже сделали нормальный), так что советую за материалом на benchhub пойти вместо этого )

А ещё у меня есть свой стринг-билдер, который быстрее дефолтного

А ещё у меня есть свой стринг-билдер, который быстрее дефолтного

можно исходники?)

вот значит его можно заинлайнить на стадии compile time и превратить в чистый байткод, сэкономив пару method call-ов :)

а значит - быстрей :troll:

а что исходники, наверное аллоцирует 4Г памяти сразу

btw, дефолтный код для str1 + str2 + str3 будет new SB().append(str1)(...).toString(), а можно было бы new SB(str1.length() + ...)(...).

можно исходники?)

https://github.com/wizzardo/tools/blob/master/modules/tools-misc/src/main/java/com/wizzardo/tools/misc/ExceptionDrivenStringBuilder.java

опять Миша пиарит свои велосипеды

Оно быстрее, если кешировать билдер

https://github.com/wizzardo/tools/blob/master/modules/tools-misc/src/main/java/com/wizzardo/tools/misc/ExceptionDrivenStringBuilder.java

о, прикольно. А чего не CharSequence?

опять Миша пиарит свои велосипеды

Велосипеди Миши офигительны.

о, прикольно. А чего не CharSequence?

Сорри, не понял вопроса

Сорри, не понял вопроса

implements CharSequence было бы неплохо

Честно, не помню какой у него апи, но в принципе можно добавить

Я тут кстати почти оформил бенчмарки для https://www.techempower.com/benchmarks/ много времени ушло на оптимизацию пайплайнинга

Можно ли java-приложение опубликовать в Apple App Store? Поиск в интернете показал, что в 2014 году это было возможно. Как сейчас обстоят дела?

В Groovy можно делать всякие дикие штуки типа compile time JSON views. Например вот это я наваял на коленке (в прямом смысле слова, с ноутбуком на коленях) пока слушал Graeme по поводу нового Grails год назад на Greach conf: https://github.com/bsideup/macro-methods-workshop/blob/8119bace0775fce74c2a0f51ac42f2666cf8baaf/src/test/groovy/com/example/MacroJSONTest.groovy#L27 здесь "macroJSON" после компиляции заменится на конкатенацию строк. Фактически самый быстрый JSON генератор для JVM =)

те груви в компайл тайме перефигачивает dsl в стринг и пихает в констант пул?

в райнтаймеж тоже самое можно сделать, а на выходе в asme будет всеравно все одно и тоже

или я чего-то не понял

Привет! Более опытные товарищи, подскажите пожалуйста, пытаюсь профилировать долгое выполнение метода. Запустил профилирование на 15 секунд, сделал запрос, который выполнялся 13 секунд, получил вот такой профиль. На нём три зоны, средняя и самая маленькая собственно интересующий метод, про две других зоны только догадки. Кто то может подсказать, что они символизируют? Возможно, что то не показывается в профиле, что?

Бд есть?

угу

запрос в базу там внутри

Если есть кривая работа с бд/ медленный запрос

Это я вангую

Jdbc?

да-да

Проставь fetch size

План запроса посмотри

запрос в базе руками выполняется мгновенно

даже если чередовать запросы программные и руками ( как будто бы не кеш базы)

Значит fetch size поможет

Мб пул соединений закончился

Если есть кривая работа с бд/ медленный запрос

а почему семплов так мало туда попало?

Хз)

Мб вообще не база

во во

Я бы начал с базы

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

У тебя на этой картинке точно нужный тред?

это постоянно воспроизводится или под нагрузкой только?

это постоянно воспроизводится или под нагрузкой только?

постоянно

продебаж