написал мегаполезный класс — 440 строк. написал тесты к нему — 312 строк. доволен

ебанулся и написал собственный аналог https://github.com/square/tape с тем чтобы размер файла не был ограничен двумя гигами

днище ебаное

Error Message: In a JIT-compiled Java method, a finally block is
not executed when:

1. A multi-type catch block is used to catch more than one type
of exceptions.

2. An exception is thrown from the try block that matches
anything but the first type in the multi-type catch.

3. An exception is thrown from the catch block. It can be a new
exception, or the caught (re-thrown) exception.

© http://www-01.ibm.com/support/docview.wss?uid=swg1IV68110

Оригинальный разбор полётов здесь:
https://www.ibm.com/developerworks/community/forums/html/topic?id=b660d423-abee-4d81-9a82-450824a26298&ps=25

вот держишь ты данные в файлике и всё заебись — rename на файликах работает атомарно, заменяя один другим. но вот стоит тебе начать держать данные в папках, как сразу начинается ад и погибель, потому что нельзя сделать mv -T a b

уж если собрался профилировать скорость, то будь добр -Xdebug из параметров запуска убрать
inb4: хули я тут удаляю

В джаве нельзя просто так взять и написать дженерик с такой вот сигнатурой:

<T> void f(List<T> list, Callback<? super List<? super T>> cb) {

Жава будет вопить про то что второй аргумент хуйня и шли б все нахуй http://ideone.com/1xQ7dC

Поебавшись некоторое время нашёл вот такой лайфхак:

<T, U extends T> void f(List<U> list, Callback<? super List<T>> cb) {

Который заебись компилится: http://ideone.com/WN1qui

В общем, не знаю кому из вас это может понадобится, но пользуйтесь на здоровье

tfw findbugs указывает тебе на ошибки в твоих же программах

так долго программил под VC++98, что настороженно относишься к установке пакета libICE

tfw rfc7159 разрешил любой value в качестве корневого элемента json. теперь придётся поправить json-parser написанный по rfc4627

опять import'ы перестали в 80 символов влезать

Всё таки в плюсцах есть одна удобная штука по сравнению с жавой. Куда удобнее и короче писать

enterprise_object_factory factory(arg1, arg2, arg3);

чем

EnterpriseObjectFactory factory = new EnterpriseObjectFactory(arg1, arg2, arg3);


величайшей трагедией интерфейса Comparable является то, что в коллекции объектов реализующих этот интерфейс вовсе не гарантируется одинаковость реализации .compareTo(...) у всех объёктов коллекции. в этом плане использование внешнего компаратора куда меньше режет глаз истинным перфекционистам

вдогонку к #CN7EZY
восемь килобайт — предельный размер блока записи в FileOutputStream, который не требует аллокаций памяти. использоваться будет массив на стеке. если больше восьми килобайт, то перед вызовом GetByteArrayElements, сначала malloc'ом будет выделен блок памяти равный размеру массива

раньше я думал, что запись в Socket блоков данных больше 8KB приводит к большому оверхеду за счёт выделения временных DirectByteBuffer. Оказывается это не так, никаких магических 8KB нет в коде jvm. Независимо от размера блока будет вызываться Util.getTemporaryDirectBuffer(size) которые выдаст DirectByteBuffer нужного размера и при необходимости удалит первый попавшийся из своего ThreadLocal кэша, чтобы новый буфер в этот кэш положить.

идемпотентность функций правильно делать не через if (!completed.getAndSet(true)), а через if (completed.compareAndSet(false, true)), ибо первый вариант вызывает второй в цикле

чтобы избежать warning'а при import'е deprecated класса, нужно удалить импорт, а к классу всюду обращаться через fully qualified name, например java.lang.String

осознал что у Map функция get(...) принимает Object. Это значит, что поиске объекта вовсе не обязательно конструировать ключ, достаточно создать объект любого типа с правильными hashCode() и equals(Object). Практическое применение — лукапы в Map<String, ?>, при которых можно избежать конструирования String'а из char[]

а ещё у меня дикая ломка от того что IBM всё никак не выпустит свой билд jvm для восьмой джавы, так уже хочется в лямбдочки попердолиться, да default-функции заюзать

обожаю работу в яндексе. серьёзно. проблемы о которых в других конторах даже не задумываются, в яндексе случаются каждый, сука, день. вот и сейчас выясняется, что не смотря на всякие SO_REUSEADDR, SO_LINGER и прочую еболу, которые админы накрутили в sysctl, перед закрытием сокета нужно таки делать shutdown(2). потому что. и да, к переполнению интовых счётчиков для количества документов на одном сервере мы давно привыкли и починили