|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
Java 14 должна выйти позже в этом месяце — с рядом изменений. Какие изменения планируется включить в обновление: JEP 305: сопоставление шаблонов для «instanceof» (предварительная версия). Сопоставление шаблонов позволяет выражать обычную логику «кратко и безопасно». Согласно документации OpenJDK, сейчас существуют только специализированные решения для сопоставления шаблонов, поэтому авторы посчитали, что пришло время существенно расширить использование сопоставления шаблонов в Java. JEP 343: упаковщик (инкубатор). Этот инструмент позволяет создавать установочные пакеты для автономных Java-приложений. JEP 345: выделение памяти с поддержкой NUMA для G1. Предполагается, что это улучшит производительность G1 на больших машинах. JEP 349: потоки событий JFR. Это позволит непрерывно считывать данные профилировщика JDK Flight Recorder. JEP 352: сопоставленные байтовые буферы в энергонезависимой памяти. В этом выпуске добавлены новые режимы сопоставления файлов, которые позволяют использовать API-интерфейс FileChannel для создания экземпляров MappedByteBuffer, ссылающихся на энергонезависимую память. JEP 358: полезная информация в исключениях NullPointerException. Теперь исключения NullPointerException, генерируемые виртуальной Java-машиной, будут указывать, какая переменная оказалась «null». JEP 359: записи (предварительная версия). Записи дают синтаксис для объявления классов, действующих как удобные и понятные хранилища неизменяемых данных. Одна из основных претензий к Java в том, что приходится писать слишком много кода, особенно когда речь идет о классах. В документации OpenJDK говорится, что из-за этого разработчики иногда пытаются изловчиться и облегчить себе работу, что приводит к проблемам в будущем. JEP 361: «switch» как выражение. Теперь «switch» можно использовать и как оператор, и как выражение. Это упростит использование Java и заложит фундамент для реализации сопоставления шаблонов в «switch». Ранее эта функция была представлена в виде предварительной версии в JDK 12 и JDK 13. JEP 362: устаревание портов на Solaris и SPARC. Начиная с этого выпуска, данные порты будут считаться нерекомендуемыми к использованию, а в одном из следующих выпусков будут полностью удалены. JEP 363: удаление сборщика мусора (GC), работающего по алгоритму маркировки и очистки (CMS). Сборщик мусора CMS уже более двух лет считается устаревшим — с тех пор внимание было обращено на улучшение других сборщиков. В частности, были представлены два новых: ZGC и Shenandoah. Команда разработчиков считает, что теперь CMS можно спокойно удалять, и ожидает, что будущие улучшения в других сборщиках мусора еще больше снизят потребность в CMS. JEP 364 и 365: ZGC в macOs и Windows. Сборщик мусора ZCG был портирован на macOS и Windows. JEP 366: устаревание комбинации алгоритмов сбора мусора ParallelScavenge + SerialOld. По словам команды разработчиков, эта комбинация используется редко, но требует значительных усилий по поддержке. Они считают, что такая комбинация полезна только при развертывании, которое сочетает в себе очень большой сборщик мусора нового поколения и очень маленький старого поколения. JEP 367: удаление API и инструментов Pack200. Эти инструменты считаются устаревшими с версии Java SE 11. JEP 368: текстовые блоки (вторая предварительная версия). Добавлены текстовые блоки — многострочные строковые литералы, которые можно использовать без escape-последовательностей. Это позволяет обеспечить предсказуемое поведение форматирования строк и контролировать их отображение. JEP 370: API доступа к внешней памяти (инкубатор). Этот API даст возможность приложениям безопасно и эффективно получать доступ к внешней памяти («foreign memory») вне «кучи» Java. https://m.habr.com/ru/news/t/491378/ https://builds.shipilev.net/backports-monitor/release-notes-14.txt С уважением, Валентин ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2020, 09:27 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
прикольно. еще через десяток итераций они наконец, родят патернматчинг. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2020, 12:20 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
JEP-305 - это не паттерн матчинг. Сомнительно. Судя по примерам которые там приводят. Это кусок говна. Навроде сахара. К реальному паттерн-матчингу он не имеет отношения. Просто некоторым очень хочется этот сахар так назвать. Настоящий паттерн-матчинг это дефиниция функции с разными условиями аргументов. По сути сет функций которые рассматрвиаются как единая функция для разных условий. И я не понимаю почему там (jep-305) нет всеохватывающего примера которые это показывает. Какие-то игры с рефлексией. Но это не про это! ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2020, 12:51 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
JEP 363: удаление сборщика мусора (GC), работающего по алгоритму маркировки и очистки (CMS) Я это не одобряю. Я думаю что CMS рельно проживет дольше. Существуют рекомендации по использованию его как аварийного спасательного круга для ПО Apache Ignite когда ноды выпадают из кластера по сетевому таймауту. А таймаут обусловлен тем что потоки приостановлены G1Gc. И настройки не помогают. Тоесть на коротких дистанциях бегун CMS бежит лучше чем G1. Была также кастомизация JetBrains и разных UI приложений через CMS чтобы сделать работу пользователя комфортной. Я охотно верю в то что Шенандох и ZGC проектировались как более улучшенные версии но если читать между строк то все улучшения уменьшают среднее квадратическое от лага но не максимальное время ожидания. Я нигде не увидел (ни в одном уборщике мусора) гарантий того что поток будет остановлен на не более чем заданный интервал времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2020, 13:40 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
JEP 368: текстовые блоки (вторая предварительная версия). Добавлены текстовые блоки — многострочные строковые литералы, которые можно использовать без escape-последовательностей. Это позволяет обеспечить предсказуемое поведение форматирования строк и контролировать их отображение. Это хорошая и приятная штука. Ее надо было внедрить еще лет 15 назад. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2020, 13:46 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
mayton Это хорошая и приятная штука. Ее надо было внедрить еще лет 15 назад. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2020, 15:47 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
JEP 349: потоки событий JFR. Это позволит непрерывно считывать данные профилировщика JDK Flight Recorder. Это вообще шикарно. Я люблю софт для тонкой диагностики перформанса. Старый JVisualVM Profiler который базировался на дампе стектрейсов был очень грубый и гранулярный. Я надеюсь что флайт рекордер пофиксит эти недостатки. Кроме того (поправьте меня кто в курсе) кажется флайт был платным продуктом. Если его вывели в домен OpenJdk то это означает что платить за лицензии не надо. (Когда это случилось? С какого года? Подскажите кто следил за новостями) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2020, 16:15 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
https://openjdk.java.net/jeps/328 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2020, 16:31 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
По поводу JEP 370: API доступа к внешней памяти (инкубатор). Как говорил Чебурашка - строили мы строили и наконец построили. Мы шли к этому давно. Еще с первой версии. Кто-то решал через JNI. Hazelcast и другие кеши которым нужна кучка без управления возможно используют ByteBuffers. Но суть одна. Хотят. Очень хотят память которая не обрабатывается механикой GC. Надеюсь что средства диагностики (MBean) будут просто трекать этот сегмент чтоб хотя-бы примерно представлять как он растет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2020, 17:20 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
А чего вы там собрались трекать, если "иностранная" память это память, которую явно запрашивает приложение??? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2020, 17:25 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
Сколько всего выделено. Разве вам не интересно? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2020, 18:16 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
Valentin Kolesnikov устаревание комбинации алгоритмов сбора мусора...что такая комбинация полезна только при развертывании, которое сочетает в себе очень большой сборщик мусора нового поколения и очень маленький старого поколения. то есть почти весь Web Когда 99.99% объектов живут максимум на время Request'а и "старого поколения" вообще нафиг не сдалось ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2020, 22:35 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
mayton Сколько всего выделено. Разве вам не интересно? Управление памятью - задача сильно не тривиальная. Вопрос "сколько всего выделено", с другой стороны - настолько примитивен, что ответ на него неинтересен до тривиальности. Foreign Memory API (FM API) позволит реализовать всякие хитромудрые системы управления памяти, которые, по факту, будут настолько сложны, что примитивы FM API будут упакованы в обёртки. Т.е. JEP 370 - сильно не для прикладных программистов. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2020, 22:50 |
|
Вышел openjdk 14
|
|||
---|---|---|---|
#18+
Когда смотрел пару лет назад direct ByteBuffer был тормозной аж до невозможности. Чтение любого байта - проверки на выход за пределы массива, оптимизации JIT отправлены в топку. Получилось ли что-то вменяемое сейчас - не знаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2020, 23:04 |
|
|
start [/forum/topic.php?fid=59&msg=39941739&tid=2120857]: |
0ms |
get settings: |
4ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
32ms |
get topic data: |
2ms |
get forum data: |
1ms |
get page messages: |
232ms |
get tp. blocked users: |
0ms |
others: | 303ms |
total: | 581ms |
0 / 0 |