В джаве нельзя просто так взять и написать дженерик с такой вот сигнатурой:
<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 указывает тебе на ошибки в твоих же программах
тимлид уходя с работы вскользь спросил, как я смотрю на переход с IBM JDK на Oracle JDK. чую, просрал IBM свои некогда охуительные гарбаж коллекторы
эпичный пример квиксорта, который падает со StackOverflowError на отсортированном массиве: http://grepcode.com/file/repo1.maven.org$maven2@org.apache.pdfbox$pdfbox@1.8.8@org$apache$pdfbox$util$QuickSort.java#68
Всё таки в плюсцах есть одна удобная штука по сравнению с жавой. Куда удобнее и короче писать
enterprise_object_factory factory(arg1, arg2, arg3);
чем
EnterpriseObjectFactory factory = new EnterpriseObjectFactory(arg1, arg2, arg3);
величайшей трагедией интерфейса Comparable является то, что в коллекции объектов реализующих этот интерфейс вовсе не гарантируется одинаковость реализации .compareTo(...) у всех объёктов коллекции. в этом плане использование внешнего компаратора куда меньше режет глаз истинным перфекционистам
сидишь и обновляешь страницу http://www.ibm.com/developerworks/java/jdk/linux/download.html в надежде что появится Java 8
вдогонку к #CN7EZY
восемь килобайт — предельный размер блока записи в FileOutputStream, который не требует аллокаций памяти. использоваться будет массив на стеке. если больше восьми килобайт, то перед вызовом GetByteArrayElements, сначала malloc'ом будет выделен блок памяти равный размеру массива
раньше я думал, что запись в Socket блоков данных больше 8KB приводит к большому оверхеду за счёт выделения временных DirectByteBuffer. Оказывается это не так, никаких магических 8KB нет в коде jvm. Независимо от размера блока будет вызываться Util.getTemporaryDirectBuffer(size) которые выдаст DirectByteBuffer нужного размера и при необходимости удалит первый попавшийся из своего ThreadLocal кэша, чтобы новый буфер в этот кэш положить.
twf наступаешь на багу в jvm. ладно бы это была безобидная бага, так ведь она RuntimeException заворачивает Error что убивает нить исполнения к хуям
идемпотентность функций правильно делать не через 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-функции заюзать
Если известно, что obj != null, то лучше писать sb.append(obj.toString()), чем sb.append(obj), чтобы избежать лишнего вызова String.valueOf(obj)
error: a generic class may not extend java.lang.Throwable
