Рантаймы не то, чтобы убивают приложение, они убивают поток в приложении. А особенность реализации их в Яве приводит к тому, что это зачастую просто зажевываются. Скажем, что напишет такой код?
runAsync(() -> { throw new RuntimeException(); });
Ничего.
Приложение работает, а часть функционала вдруг перестала работать. Отлично.
Дальше, проверяемые эксепшены заставляют документировать себя в сигнатуре метода. Не все эксепшены должны быть там описаны, но проверяемые ты просто не можешь не вынести в throws, то есть в контракт метода. Да, потом их надо ловить и это уже их минус. Идеально было бы сказать, что ты проверяемый эксепшены в таком то скоупе, например, в моем АПИ ты проверяемый, а вот дальше, у моего клиента уже — нет.
С другой стороны, 8я Ява убила этот холивар. В 7ке и ранее, я был за проверяемые эксепшены, то в 8ке ими просто невозможно пользоваться. Но в итоге, у меня большая проблема на здоровых программах, ибо я никогда не уверен, какой конкретно эксепшен может вылететь из моего АПИ, раньше это делал компилятор.
Там скорее про ускорение вопрос. В горку там, или если по тротуару сквозь пешеходов. Снимает пиковые нагрузки. Ну и в конце концов это обычный велик, просто адово тяжелый и дорогой. У меня тут эко зона куда бензиноскутера не пускают, а велик легко. Плюс на нем можно кататься вместе с обычными велосипедами, социализация. По городу удобно по тротуару сквозь пешеходов. В горы прет круто. А в целом игрушка.
Это не совсем так, то есть они действительно сделали Objects, но явно теоретики ибо допускают глупые косяки, что идею убивает. Например, как раз в тему, статический метод сравнения называется в Гуаве equal, а в Яве equals. И если гуавовскую версию можно сократить статик импортом и писать equal(a, b). То с явой не пройдет изза коллизии с обычным equals, не статическим. А полная форма слижком тяжеловесна. Правда, и в последней Гуаве почемуто этот метод переехал в MoreObjects. Но это так, к слову, ибо не мешает.
Потому что util сокращение от utility, utils не имеет смысла.
А так обычно Lists заведует листами, List это как раз объект листа.
Аналогично есть Collections, Objects, Sets. Часть из них правда в Гуаве, но принцип понятен.
Аналогично Arrays заведует массивами, просто тут аналогичного объекта Array просто нет, но конвенция понятна.
dadget.ru/katalog/zdorove/detektor-uglekislogo-gaza
Вот тут. Потом я таки нашел что есть еще www.9557306.ru/ питерская версия и там доставка в питер удобнее.
При этом, когда я позвонил в питерскую версию, меня кинули на московский саппорт, который не очень понимает, что со всем этим делать.
Я в полной запутанности, вот.
Я вам фидбек кину. Может быть, это я кривой косой, но и такие клиенты бывают.
Я в Питере, поэтому кинула она сразу на какой-то левый сайт. Ничего про доставку и оплату не понять. Прошел регистрацию, без регистрации ни про оплату ни про доставку ничего не написала почему-то.
Пришло письмо, что товара мол всего нет, и сроки поставки и _цены_ будут потом. Каким образом платить тоже непонятно. В общем, очень мутная схема. Я ничего не понял и пошел заказал тоже самое у других ребят, да еще и дешевле.
Зато сразу видно, что текст можно пропускать. Очень удобно. Читаешь в начале статьи, что 400 калорий это очень много, а 3500 калорий скинуть очень сложно и закрываешь статью. И не тратишь время на дальнейшее чтение.
А я вот не нашел. Пользуюсь feedly, но он не дотягивает. Чтоб пояснить масштаб бедствия, я так и не нашел способа с их сайта на айпэде пометить запись как непрочитанную. Вы скажете, что на айпэде есть апп, но он и вовсе работает в половине случаев. Так же нет киллер фичи «рекомендованное», ради чего я собственно и сидел изначально на гугл ридере. Ну и вообще, толи я что-то не понимаю, но если год назад было понятно почему он такой странный, быстро надо было что-то накатать, то сейчас уже удивительно, почему он застрял в этом сыром состоянии. Другие и вовсе не пошли у меня.
Да, у меня тоже от YACов каждый раз ощущение, что это внутренняя конференция Яндекса и она не очень интересна даже инженерам, но из компаний другого типа, чтоли. Как мне кажется, и проблемы с нецелевой аудиторией у них по тем же причинам. Позиционируется конференция совсем иначе, чем на самом деле является. Читаю пост бобука и мне кажется, что я просто идеал их мечтаний, типичный представитель фокус группы, а потом я читаю список докладов и понимаю, что ни одного полезного мне там нет в принципе и буквально 1-2 интересных, для общего развития. Это абсолютно нормально, что Яндекс делает конференцию так как это нравится им, но вот ее позиционирование каждый год меня сбивает с толку. И полагаю, что когда такие как я таки доходят толпами и получается бардак и недопонимание с обеих сторон. Кстати, того же бобука в радио-т очень всегда приятно слушать, то есть он явно понимает и умеет свое понимание доносить, но почему-то в формате YAC это для меня не работает.
Если accessor сделать volatile, то JMM гарантирует вам happens-before между чтением значения и записью значения. А из этого следует happens-before между вызовами метода объекта и его конструктором. Как раз отсутствие этого happens-before и приводит к разным спецэффектам.
Дальше еще ньюанс, даже если конструктор уже закончил инициализацию объекта, то поток, который получил ссылку на этот объект небезопасно может увидеть его побитым. JMM дает гарантии только на final поля, вся остальная грамотная инициализация на совести пользователя. Там еще веселее на самом деле, даже увидев грамотно сконструированный объект, нельзя гарантировать, что в следующем чтении он не станет побитым назад. То есть произойдет откат по времени, JMM допускает такое. Более того, оно так и происходит на некоторых экзотических платформах. Чтение из одной и той же переменной может в любой момент прочитать то, что туда была записано без happens-before, даже если это было далеко в прошлом. Это неочевидно.
Теперь, еще веселее. Если даже мы пометим все методы класса как synchronized, потом весь конструктор положим в synchronized (this) {} и никогда не будем инициализировать непосредственно поля. Даже это не защищает, как я понимаю, объект от вызова методов ДО конструктора. Более того, как я понимаю, мы вообще никак не можем защититься от вызова методов до конструктора ВНУТРИ объекта. Только логикой публикации снаружи. Исключение, это инициализация через final поля и их гарантии пресловутые.
Пример
public static Obj obj;
obj = new Obj();
Если другой объект прочитает этот obj, то у него нет гарантий, что конструктор вообще вызвался. Зато у него есть гарантия, что все его final поля проинициализированы. Но, что особо неочевидно, у него нет гарантий, что volatile поля проинициализированы.
Более того, если другой поток вызовет у объекта метод первый раз он может увидеть хороший объект, проинициализированный. А вот в следующее чтение он его же получит побитым, даже если никакой другой поток этот объект больше не трогал.
Я лично пришел к выводу, что опасная публикация, без happens-before на практике не нужна никогда. Но, есть у нас особо головастые, которым все вышенаписанное уже настолько знакомо и очевидно, что они изредка к ней прибегают. Но это все дикая экзотика для глубоких спецов по Ява многопоточке.
1. Почти. Там много всяких спецэффектов возникает. Исключениями будут скажем иммутабл классы где все поля final. Такие классы вродебы можно небезопасно публиковать. В принципе, можно и мутабл класс написать готовым для unsafe публикации, но это довольно непросто. Но техники есть. Скажем, прокинуть volatile поля в контейнер и добавить его через final reference.
2. Сомневаюсь, что синтетические геттеры повлияют на производительность. Jit должен заинлайнить их по идее, как и обычные. Но мб авторы эклипса что-то такое знают.
1. Есть шанс (и очень высокий), что потоки увидят сразу обновленное поле accessor и никогда не возьмут лок. То есть у них гарантированно не будет happens-before с таким синглетоном. Со всеми вытекающими. Классов, которых можно небезопасно публиковать крайне мало. Скажем, даже AtomicBoolean/Long/Integer уже не такие. new AtomicBoolean(true) может вернуть false, даже если его потом никогда не меняли. Впрочем, есть мысли исправить это в 9й яве: cs.oswego.edu/pipermail/concurrency-interest/2013-November/011966.html
2. Про предупреждение Eclipse это вообще похоже на какой-то бред. Видимость поля, наверное, может иметь какое-то влияние на производительность, но это будет крайне экзотический синтетический тест или какая-то нестандартная JVM. Печально, если Эклипс навязывает такие плохие практики.
3. Ну и странно говорить о правильном использовании антипаттерна. Не бывает правильного singleton. Любое его использование это костыль.
Ну и как итог. По моему, вы придумали, как можно написать стандартный плохой double checking singleton idiom, но очень плохо читаемый и многословный. По сути ваш код делает ровно тоже самое, просто сложнее и потому сложнее увидеть проблемы.
runAsync(() -> { throw new RuntimeException(); });
Ничего.
Приложение работает, а часть функционала вдруг перестала работать. Отлично.
Дальше, проверяемые эксепшены заставляют документировать себя в сигнатуре метода. Не все эксепшены должны быть там описаны, но проверяемые ты просто не можешь не вынести в throws, то есть в контракт метода. Да, потом их надо ловить и это уже их минус. Идеально было бы сказать, что ты проверяемый эксепшены в таком то скоупе, например, в моем АПИ ты проверяемый, а вот дальше, у моего клиента уже — нет.
С другой стороны, 8я Ява убила этот холивар. В 7ке и ранее, я был за проверяемые эксепшены, то в 8ке ими просто невозможно пользоваться. Но в итоге, у меня большая проблема на здоровых программах, ибо я никогда не уверен, какой конкретно эксепшен может вылететь из моего АПИ, раньше это делал компилятор.
Ps идея очень красивая.
А так обычно Lists заведует листами, List это как раз объект листа.
Аналогично есть Collections, Objects, Sets. Часть из них правда в Гуаве, но принцип понятен.
Аналогично Arrays заведует массивами, просто тут аналогичного объекта Array просто нет, но конвенция понятна.
Вот тут. Потом я таки нашел что есть еще
www.9557306.ru/ питерская версия и там доставка в питер удобнее.
При этом, когда я позвонил в питерскую версию, меня кинули на московский саппорт, который не очень понимает, что со всем этим делать.
Я в полной запутанности, вот.
Я в Питере, поэтому кинула она сразу на какой-то левый сайт. Ничего про доставку и оплату не понять. Прошел регистрацию, без регистрации ни про оплату ни про доставку ничего не написала почему-то.
Пришло письмо, что товара мол всего нет, и сроки поставки и _цены_ будут потом. Каким образом платить тоже непонятно. В общем, очень мутная схема. Я ничего не понял и пошел заказал тоже самое у других ребят, да еще и дешевле.
Дальше еще ньюанс, даже если конструктор уже закончил инициализацию объекта, то поток, который получил ссылку на этот объект небезопасно может увидеть его побитым. JMM дает гарантии только на final поля, вся остальная грамотная инициализация на совести пользователя. Там еще веселее на самом деле, даже увидев грамотно сконструированный объект, нельзя гарантировать, что в следующем чтении он не станет побитым назад. То есть произойдет откат по времени, JMM допускает такое. Более того, оно так и происходит на некоторых экзотических платформах. Чтение из одной и той же переменной может в любой момент прочитать то, что туда была записано без happens-before, даже если это было далеко в прошлом. Это неочевидно.
Теперь, еще веселее. Если даже мы пометим все методы класса как synchronized, потом весь конструктор положим в synchronized (this) {} и никогда не будем инициализировать непосредственно поля. Даже это не защищает, как я понимаю, объект от вызова методов ДО конструктора. Более того, как я понимаю, мы вообще никак не можем защититься от вызова методов до конструктора ВНУТРИ объекта. Только логикой публикации снаружи. Исключение, это инициализация через final поля и их гарантии пресловутые.
Пример
public static Obj obj;
obj = new Obj();
Если другой объект прочитает этот obj, то у него нет гарантий, что конструктор вообще вызвался. Зато у него есть гарантия, что все его final поля проинициализированы. Но, что особо неочевидно, у него нет гарантий, что volatile поля проинициализированы.
Более того, если другой поток вызовет у объекта метод первый раз он может увидеть хороший объект, проинициализированный. А вот в следующее чтение он его же получит побитым, даже если никакой другой поток этот объект больше не трогал.
Я лично пришел к выводу, что опасная публикация, без happens-before на практике не нужна никогда. Но, есть у нас особо головастые, которым все вышенаписанное уже настолько знакомо и очевидно, что они изредка к ней прибегают. Но это все дикая экзотика для глубоких спецов по Ява многопоточке.
2. Сомневаюсь, что синтетические геттеры повлияют на производительность. Jit должен заинлайнить их по идее, как и обычные. Но мб авторы эклипса что-то такое знают.
2. Про предупреждение Eclipse это вообще похоже на какой-то бред. Видимость поля, наверное, может иметь какое-то влияние на производительность, но это будет крайне экзотический синтетический тест или какая-то нестандартная JVM. Печально, если Эклипс навязывает такие плохие практики.
3. Ну и странно говорить о правильном использовании антипаттерна. Не бывает правильного singleton. Любое его использование это костыль.
Ну и как итог. По моему, вы придумали, как можно написать стандартный плохой double checking singleton idiom, но очень плохо читаемый и многословный. По сути ваш код делает ровно тоже самое, просто сложнее и потому сложнее увидеть проблемы.