С началом работы над Java 9 было объявлено об удалении критически важных классов из пакетов sun.* (разумеется, Sun, а впоследствии и Oracle, заявили, что их использование является собственным риском компаний и проектов), что вызвало шквал ажиотажа.
критики и недовольства со стороны сообщества (потому что высоконагруженные решения, для которых производительность решает все, используют скрытые возможности sun.*).
Предыстория началась 15 лет назад с выходом версии языка 1.4, за это время большое количество библиотек, фреймворков и приложений успели реализовать закрытый код в свой собственный.
Вот лишь неполный список проектов, которые у всех на слуху: Scala, Kafka, Akka, Hadoop, Cassandra, Hazlecast и другие.
Вроде новость за неделю, но нам постоянно приходится сталкиваться с тем, что люди не в курсе и ожидают диких проблем с новым API в java 9 (может, конечно, не без этого, однако.
)
Реальность
Как ни странно, разработчики как из open jdk, так и из Oracle согласились встретиться с сообществом, и документ был принят. ДжЭП 260 В двух словах: решено оставить некоторые критичные и широко используемые внутренние API, которым пока нет замены, но это не значит, что их совместимость будет гарантирована.Таким образом, было решено оставить следующий API: sun.misc.Сигнал sun.misc.SignalHandler обеспечивает поддержку работы с сигналами (собственно IRC), может сообщать об асинхронном событии вне JVM. sun.misc.Небезопасно раньше работал напрямую с памятью (обещают, что можно будет частично использовать API от JEP 193: переменные ручки , еще говорят, что некоторые операции будут эффективнее).
sun.reflect.Reflection::getCallerClass(int) сообщает нам, какие классы находятся в стеке вызовов (с выходом Java 9 частично можно перейти на JEP 259: API обхода стека ) sun.reflect.ReflectionFactory.newConstructorForSerialization на самом деле мастер-фабрика по созданию объектов отражения Некритичный API, для которого уже существует замена, будет помечен как @Deprecated, начиная с Java 9, а начиная с Java 10 он будет удален из языка.
JDK9 Early Access уже доступен по состоянию на 24.02.2017, последняя сборка b158 ( jdk9.java.net/скачать , jdk9.java.net/jigsaw ) и если заглянуть внутрь, то можно найти все классы, перечисленные выше в модуле jdk.unsupported, а также найденные вместе с ними: com.sun.nio.file.ExtendedCopyOption com.sun.nio.file.ExtendedOpenOption com.sun.nio.file.ExtendedWatchEventModifier com.sun.nio.file.SensitivityWatchEventModifier предоставление дополнительных возможностей при работе с операциями ввода-вывода.
Общий
Производители прислушались к сообществу, и как следствие переход с пакетов sun.* обещает быть плавным и некритичным, а в случае проблем можете спать спокойно с 8 версией, буду рад ответить на вопросы (б.
Теги: #java #java 9 #небезопасно #программирование #java
С началом работы над Java 9 было объявлено об удалении критически важных классов из пакетов sun.* (разумеется, Sun, а впоследствии и Oracle, заявили, что их использование является собственным риском компаний и проектов), что вызвало шквал ажиотажа.
критики и недовольства со стороны сообщества (потому что высоконагруженные решения, для которых производительность решает все, используют скрытые возможности sun.*).
Предыстория началась 15 лет назад с выходом версии языка 1.4, за это время большое количество библиотек, фреймворков и приложений успели реализовать закрытый код в свой собственный.
Вот лишь неполный список проектов, которые у всех на слуху: Scala, Kafka, Akka, Hadoop, Cassandra, Hazlecast и другие.
Вроде новость за неделю, но нам постоянно приходится сталкиваться с тем, что люди не в курсе и ожидают диких проблем с новым API в java 9 (может, конечно, не без этого, однако.
)
Реальность
Как ни странно, разработчики как из open jdk, так и из Oracle согласились встретиться с сообществом, и документ был принят. ДжЭП 260 В двух словах: решено оставить некоторые критичные и широко используемые внутренние API, которым пока нет замены, но это не значит, что их совместимость будет гарантирована.Таким образом, было решено оставить следующий API: sun.misc.Сигнал sun.misc.SignalHandler обеспечивает поддержку работы с сигналами (собственно IRC), может сообщать об асинхронном событии вне JVM. sun.misc.Небезопасно раньше работал напрямую с памятью (обещают, что можно будет частично использовать API от JEP 193: переменные ручки , еще говорят, что некоторые операции будут эффективнее).
sun.reflect.Reflection::getCallerClass(int) сообщает нам, какие классы находятся в стеке вызовов (с выходом Java 9 частично можно перейти на JEP 259: API обхода стека ) sun.reflect.ReflectionFactory.newConstructorForSerialization на самом деле мастер-фабрика по созданию объектов отражения Некритичный API, для которого уже существует замена, будет помечен как @Deprecated, начиная с Java 9, а начиная с Java 10 он будет удален из языка.
JDK9 Early Access уже доступен по состоянию на 24.02.2017, последняя сборка b158 ( jdk9.java.net/скачать , jdk9.java.net/jigsaw ) и если заглянуть внутрь, то можно найти все классы, перечисленные выше в модуле jdk.unsupported, а также найденные вместе с ними: com.sun.nio.file.ExtendedCopyOption com.sun.nio.file.ExtendedOpenOption com.sun.nio.file.ExtendedWatchEventModifier com.sun.nio.file.SensitivityWatchEventModifier предоставление дополнительных возможностей при работе с операциями ввода-вывода.
Общий
Производители прислушались к сообществу, и как следствие переход с пакетов sun.* обещает быть плавным и некритичным, а в случае проблем можете спать спокойно с 8 версией, буду рад ответить на вопросы (б.Теги: #java #java 9 #небезопасно #программирование #java
-
"Как..."
19 Oct, 24 -
Интервью С Сергеем Прокоповым
19 Oct, 24 -
Дополнительные Объединения В Sql-Запросах
19 Oct, 24
