Я столкнулся с тем, что если у некоторых компонентов (отдельных java проектов) файл build.gradle (да и сам gradle) не обновлялся достаточно давно, то задействование bom с помощью platform (и тем более force platform) приносит кучу проблем, по сути ломая механизм разрешения зависимостей. Так что лучше перед использованием bom избавиться от зоопарка версий gradle (если он конечно есть), а также привести скрипты build.gradle к "общему знаменателю" - убрать, например, compile/runtime и другие устаревшие штуки.
Мне кажется стоило добавить о коллекциях и sequence в kotlin, о их влиянии на performance, и о том, что некоторые операции .collect() при совпадении ключа, в java вызовут ошибку, которая призовет к использованию другого, соответствующего коллектора (где можно указать, что делать в такой ситуации), а то время как в Котлин все отработает "молча", но не всегда так, как нужно автору кода. По моему опыту, это частые подводные камни при подобном переходе.
Аудио без потерь по-прежнему сжимает файлы, но использует специальный алгоритм, который может минимизировать размер ущерба для детализации. Это серьезное заявление во всех смыслах, особенно в техническом.
У нас в компании он используется, но чем он удобнее бесплатного Google drawings, https://app.diagrams.net/ и им подобным, как то пока не совсем не очевидно.
Начитавшись здесь о разных методах коррекции, я какое-то время назад находил, что ближайшие ко мне (Одесса) клиники, делающие коррекцию по методу SMILE - это либо Москва, либо Вена.
Да, по этой теме информации мало, либо она частично устарела (относится к е3, хотя многие компоненты из е3 ещё можно использовать).
Проблема в том, что ничего другого, сопоставимого по возможностям, среди инструменты разработки для desktop на java, просто нет. Да, есть в живых ещё JavaFX и его kotlin вариант totnadoFX, там с документацией и примерами получше, но Eclipse RCP это целая платформа, а не просто фреймворк. Для больших приложений по сути единственный выбор.
Мне кажетсяя этим "грешит" в том числе и gradle плагин 'application', он генерирует файлы запуска java приложения (*.sh и *.bat) которые в Windows не работают, из-за ошибки "Input line too long". Но этого можно избежать, добавив в build.gradle нехитрую регулярку (не сильно разбираюсь в groovy, но она работает))
/* Workaround for Windows cmd "Input line too long" bug */
startScripts {
doLast {
def windowsScriptFile = file getWindowsScript()
windowsScriptFile.text = windowsScriptFile.text.replaceFirst(/set CLASSPATH=%APP_HOME%\\lib\\.+/,"set CLASSPATH=%APP_HOME%\\\\lib\\\\*;")
}
}
т.е. просто заменив перечисление всех файлов в classpath на * wildcard in classpath. Кажется эту возможность добавили еще в java 6, но этот плагин по-прежнему её не использует. Возможно таким способом можно и gradle-jmh plugin "починить" ))
Да, и кроме того — иногда забывают, что ArrayList (по сути массив) занимает непрерывную область памяти и если попытаться создать такой список очень большого размера, то вполне реально упасть с ошибкой выделения памяти.
Уж не помню точно, но упрощённо говоря смысл "полезности" троичной системы состоит в том, что отношение количества цифр в системе счисления к количеству разрядов необходимых для записи конкретного числа в пределе даёт е, т.е. 2.7182818284… Но работать в системе счисления с нецелым основанием подсилу только математикам, а ближе всего к этой величине основание 3.
Видел подобные тесты, которые показывают, что т.н. новый "reflection API" в Java 8 и выше, довольно быстр, что не может не радовать. Но MethodHandle (конкретно в Oracle JDK 8 build 65) вызывал у нас в проекте ошибку OutOfMemory, аналогично ситуации, описанной здесь: https://bugs.openjdk.java.net/browse/JDK-7021343.
Пришлось отказаться от его использования.
Я столкнулся с тем, что если у некоторых компонентов (отдельных java проектов) файл build.gradle (да и сам gradle) не обновлялся достаточно давно, то задействование bom с помощью platform (и тем более force platform) приносит кучу проблем, по сути ломая механизм разрешения зависимостей. Так что лучше перед использованием bom избавиться от зоопарка версий gradle (если он конечно есть), а также привести скрипты build.gradle к "общему знаменателю" - убрать, например, compile/runtime и другие устаревшие штуки.
Ну лично мне эта статья показалось очень иллюстративной
https://typealias.com/guides/when-to-use-sequences/
Мне кажется стоило добавить о коллекциях и sequence в kotlin, о их влиянии на performance, и о том, что некоторые операции .collect() при совпадении ключа, в java вызовут ошибку, которая призовет к использованию другого, соответствующего коллектора (где можно указать, что делать в такой ситуации), а то время как в Котлин все отработает "молча", но не всегда так, как нужно автору кода.
По моему опыту, это частые подводные камни при подобном переходе.
Можно (и зачастую нужно) идентификаторы операторам назначать в коде. Они не изменятся при добавлении новых.
Если хотя бы абзац про целевую аудиторию вынести в самое начало (и желательно шрифтом в пол экрана), то этот текст имел бы хоть какой-то смысл
@vvvphoenix кажется в списке ссылок часть 8,9,10 это одно и то же
Чем?
У нас в компании он используется, но чем он удобнее бесплатного Google drawings, https://app.diagrams.net/ и им подобным, как то пока не совсем не очевидно.
Начитавшись здесь о разных методах коррекции, я какое-то время назад находил, что ближайшие ко мне (Одесса) клиники, делающие коррекцию по методу SMILE - это либо Москва, либо Вена.
Может вас просто обманули?
Да, по этой теме информации мало, либо она частично устарела (относится к е3, хотя многие компоненты из е3 ещё можно использовать).
Проблема в том, что ничего другого, сопоставимого по возможностям, среди инструменты разработки для desktop на java, просто нет. Да, есть в живых ещё JavaFX и его kotlin вариант totnadoFX, там с документацией и примерами получше, но Eclipse RCP это целая платформа, а не просто фреймворк. Для больших приложений по сути единственный выбор.
Мне кажетсяя этим "грешит" в том числе и gradle плагин 'application', он генерирует файлы запуска java приложения (*.sh и *.bat) которые в Windows не работают, из-за ошибки "Input line too long". Но этого можно избежать, добавив в build.gradle нехитрую регулярку (не сильно разбираюсь в groovy, но она работает))
т.е. просто заменив перечисление всех файлов в classpath на * wildcard in classpath. Кажется эту возможность добавили еще в java 6, но этот плагин по-прежнему её не использует. Возможно таким способом можно и gradle-jmh plugin "починить" ))
хде? ))
Да, и кроме того — иногда забывают, что ArrayList (по сути массив) занимает непрерывную область памяти и если попытаться создать такой список очень большого размера, то вполне реально упасть с ошибкой выделения памяти.
Уж не помню точно, но упрощённо говоря смысл "полезности" троичной системы состоит в том, что отношение количества цифр в системе счисления к количеству разрядов необходимых для записи конкретного числа в пределе даёт е, т.е. 2.7182818284… Но работать в системе счисления с нецелым основанием подсилу только математикам, а ближе всего к этой величине основание 3.
Видел подобные тесты, которые показывают, что т.н. новый "reflection API" в Java 8 и выше, довольно быстр, что не может не радовать. Но MethodHandle (конкретно в Oracle JDK 8 build 65) вызывал у нас в проекте ошибку OutOfMemory, аналогично ситуации, описанной здесь: https://bugs.openjdk.java.net/browse/JDK-7021343.
Пришлось отказаться от его использования.