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

пытаюсь сделать через feature

пытаюсь сделать через feature

Feature? Эм, что это?

future, очепятка по фрейду

Feature? Эм, что это?

фича же)

фича же)

Ты контекст не учёл) А так, да, ясное дело.

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

или то, что разные аннотации для инжекта дают разный перфоманс

Где ты такое вычитал? Можешь поделиться? P. S. Это, наверное, в jvm-чат.

https://jira.spring.io/browse/SPR-13610

https://jira.spring.io/browse/SPR-13086

https://jira.spring.io/browse/SPR-8767

а еще xml-конфиги быстрее джава

https://www.youtube.com/watch?v=cou_qomYLNU&feature=youtu.be&t=1h5m12s

или то, что разные аннотации для инжекта дают разный перфоманс

это же происходит на стадии старта приложения когда контекст формируется

так что наверное срать

https://www.youtube.com/watch?v=cou_qomYLNU&feature=youtu.be&t=1h5m12s

Хм, Женя утверждает, что Resource медленнее Autowired/Inject. Даже микробенчмаркам доверять нельзя)

Хм, я что-то раньше, смотря видео, не обратил внимания. new по времени занимает столько же, сколько и вызов метода (3.3 нс)? Я один ожидал иного результата?

А кому-то важно сколько стартует приложение?

Если это в пределах разумного, конечно же

у микросервисов важно

В каких кейсах?

Не думаю что кто-то завязываетется на этом.

ну когда для них scale делаешь

Ну я уточнил, в пределах разумного. Было бы странно, если бы микросервис деплоился с пяток минут.

При тестировании это важно

Это уже как-то не микро. А разница в пару секунд, кажется не очень большой платой в сравнении с бенефитами которые дает Java config.

Эм, конкретно спрашуй у ребят из penchat.net

аааа, т.е. надо ждать пока penchatовцы одобрят, понятно.

впервые на redmain

кто знает чатик по админству всяких wildfly-ев c tomcat-ами?

Вот за эту инфу спасибо

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

Да и сам синтаксис богат и лаконичен. Но двусмысленен по началу. JS как-то по прямолинейней.

ну конечно, в руби целых 3 вида lambda - proc,bloc lambda - синтаксис богат

Ой, не туда

хватит всякое говно мамонта поддерживтаь своим вниманием типа гвт

Посоны, подскажите, если кучу не используемого говна положить в .classpath, /lib, jvm будет больше памяти жрать? Медленнее работать?

Да

А подробнее?

кто-то юзал https://www.dynatrace.com/ ?

А ну не используемого нет. Если в класлоадер попадут да

Создаю допустим класс Example e = new Exemple(); Добавили много объектов в этот класс. При e=null; так же уничтожит все объекты в Example при сборке мусора?

если на них никто больше не ссылается

Создаю допустим класс Example e = new Exemple(); Добавили много объектов в этот класс. При e=null; так же уничтожит все объекты в Example при сборке мусора?

Свой gc пишешь?

если на них никто больше не ссылается

Ну да другие классы не будут ссылаться. Т.е мне в Exemple занулять не надо объекты, сами пропадут?

Да

Тип софт референс?

Я думаю парню этого не нужно)

Помню был какой-то интересный пример с массивами где GC не подчищал элемент и он оставался висеть в памяти. Кто знает киньте ссыль или код :)

там не с массивами) а с мапами скорее всего)

в Блоха было с массивами

Помню был какой-то интересный пример с массивами где GC не подчищал элемент и он оставался висеть в памяти. Кто знает киньте ссыль или код :)

ну меморилик всегда можно сделать))

например добавив груви в джава проект ?

например добавив груви в джава проект ?

:3 жиза

когда они это пофиксят интересно

ну так они это фиксят с переменным успехом. просто там не один мемори лик

вообще, мне кажется, груви пора закапывать

В пользу чего?

котлина?)

ERROR: S client not available

в пользу здорового сна

а если серьезно, то смотря где груви грутится

если тесты, то для тестов можно и оставить

грейдл скрипты на котлин

продакшен на джаву

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

грейдл лучше на груви. имхо очень толковый dsl получается на груви - лучше чем всякие json даже

а котлин не нужен

разве что на мобайле, где нету нормальной джавы

разве что на мобайле, где нету нормальной джавы

+

в Блоха было с массивами

не помню у Блоха этого))

Камрады, а чет я туплю :) Вот есть у меня такое Map<String, Boolean> как сделать чтоб он на неициализированные значения false выдавал? Если заменить Boolean на boolean - ошибку выдает

@Medvedych если объекта нет с таким ключом, то null вернёт. Вот и всё.

ну это то понятно, а есть какой-нибудь обходной вариант? А то на null и false разом проверять - не красиво

ну это то понятно, а есть какой-нибудь обходной вариант? А то на null и false разом проверять - не красиво

Ну если он не final, отнаследуйся)

HM, в смысле

Да не, не финал я туда напихиваю все что нашел, а потом проверяю что из нужного нашлось

Да не, не финал я туда напихиваю все что нашел, а потом проверяю что из нужного нашлось

в смысле, сделай свой HashMap

и переопредели get

хм, интересная мысль ?

ну это то понятно, а есть какой-нибудь обходной вариант? А то на null и false разом проверять - не красиво

Boolean.TRUE.equals()

containsKey чем не угодил?

class BooleanHashMap extends HashMap<String, Boolean> { @Override public Boolean get(Object key) { Boolean v = this.get(key); if (v == null) return false; return v; } }

containsKey чем не угодил?

ну дык один 2 вещи проверять, что так, что так

Камрады, а чет я туплю :) Вот есть у меня такое Map<String, Boolean> как сделать чтоб он на неициализированные значения false выдавал? Если заменить Boolean на boolean - ошибку выдает

java7: Boolean value = map.get(1); value = value != null ? value : false java8: Boolean value = map.getOrDefault(1, false);

где-то (скажем, внутри переопределенного класса) все равно надо будет проверять

groovy: def value = map.get(1) ?: false

kotlin: val value = map[1] ?: false

containsKey чем не угодил?

ну дык один фиг 2 проверки делать, а там разницы уже нет что containsKey, что !=null