В классе java.nio.file.Files присутствуют две статические функции для создания директорий:
createDirectory(Path, FileAttributes...)
createDirectories(Path, FileAttributes...)Активным пользователям mkdir(1) даже не нужно читать доку чтобы знать особенности различия:
Первая создаёт одну папку и ругается если она уже есть.
Вторая создаёт все нужные папки и не ругается если папка уже есть.
В общем, мне было очень приятно обнаружить такую преемственность на уровне флага -p.
Мы обожаем self-descriptive имена у функций. Например, вот три строчки из декларации одного интерфейса:
long intValue();
double floatValue();
String stringValue();пооптимизячил один класс. теперь вся jvm может схлопнуться с сегфолтом, если неправильно использовать класс в однопоточном приложении
днище ебаное
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
Это чувство, когда твой сраный JsonWriter сраные 200тысяч key-value пар общим размером в восемь сраных мегабайт пишет и кодирует из utf-16 в utf-8 целых 250 мс
уж если собрался профилировать скорость, то будь добр -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 указывает тебе на ошибки в твоих же программах
тимлид уходя с работы вскользь спросил, как я смотрю на переход с 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
