Вот только не полный перечень проектов, которые у всех на слуху: Scala, Kafka, Akka, Hadoop, Cassandra, Hazlecast и прочие…
Вроде бы новости без году неделя, однако постоянно приходится сталкиваться c тем, что люди не в курсе, и ожидают диких проблем с новым API в java 9 (может быть конечно и не без этого, однако...)
Реальность
Как ни странно, разработчики как из open jdk, так и из Oracle пошли на встречу сообществу и был принят документ JEP 260, если в двух словах: то решено оставить некоторые критически важные и широко используемые внутренние API, для которых пока не существует замены, однако это не означает, что будет гарантироваться их совместимость.
Таким образом решено оставить следующее API:
sun.misc.Signal
sun.misc.SignalHandler
обеспечивает поддержку работы с сигналами (фактически IRC), может сообщить асинхронное событие вне JVM.
sun.misc.Unsafe
используется для работы непосредственно с памятью (обещают, что частично можно будет воспользоваться API из JEP 193: Variable Handles, также поговаривают что часть операций будет более эффективными).
sun.reflect.Reflection::getCallerClass(int)
говорит нам, какие классы находятся в стеке вызов (с выходом java 9, частично возможен переход на JEP 259: Stack-Walking API)
sun.reflect.ReflectionFactory.newConstructorForSerialization
фактически master фабрика для создания объектов reflection
Не критическое API, которому уже существует замена, будет помечен как @Deprecated, уже начиная с Java 9, а начиная с Java 10 выводится из языка.
Уже сейчас доступна JDK9 Early Access на 24.02.2017 последний билд b158 (jdk9.java.net/download, 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
обеспечивающие дополнительные возможности при работе с i/o-операциями.
Итого
Производители прислушались к сообществу, и в результате переход с пакетов sun.* обещает быть плавным и не критичным, а в случае проблем, можно спокойно спать и с 8 версией, буду рад ответить на вопросы (b.lutovich@socmetr.ru).
Комментарии (4)
barker
01.03.2017 19:37разработчики как из open jdk, так и из Oracle
Странная фраза…
upd В данном случае это не одно и то же? Это какие такие разработчики из open jdk, которые не являются при этом разработчиками из оракла могли как-либо повлиять на создание JEP?
pohab
02.03.2017 08:22OpenJDK разрабатывает не только Oracle. Как минимум, есть еще SAP, а также множество других.
barker
02.03.2017 10:48Из крупных ibm ещё, это-то понятно, но рулит на уровне JEP я думал только Oracle, ну ок.
Про странность фразы я сказал, т.к. она контекстом показывает, что open jdk это не oracle как будто, но все разработчики из оракла это разработчики и из open jdk, т.к. oracle jdk это по сути open jdk (которая есть референсная реализация) давно, нет?
Regis
По моей памяти речи про удаление Unsafe и прочего в Java 9 никогда и не шло — речь шла о том, что классы типа Unsafe перестанут быть доступными (by default), а станут именно что внутенними классами (что совершенно логично с учетом Jigsaw), но будут доступны при добавлении дополнительного флага. Т.е. если хочешь Unsafe — стартуй JVM с флагом.
Что касается удаления вообще (после Java 9) — нужно понимать, что Unsafe нужны были для выполнения некоторых сугубо внутренних трюков. В Java 9 некоторые вещи в той или иной степени уже сделаны без Unsafe (например через VarHandles). Костыли в виде Unsafe уже не нужны, но увы, их нужно поддерживать, так как их уже используют библиотеки. А раз нужно поддерживать, то в итоге усложняется (и частично замедляется) та самая логика, которая стоит за Unsafe и VarHandles. Т.е. если бы Unsafe можно был выкинуть, то, возможно, JVM можно было бы в некоторых случаях сделать быстрее.
С другой стороны — доступ к Unsafe без флага в Java9 будет для большинства удобнее.