Unsafe продолжает жить в Java 9

    С началом работы над Java 9 было анонсировано удаление критически важных классов из пакетов sun.* (понятное дело Sun, а в последствии и Oracle заявляли, что их использование является собственным риском компаний и проектов), что вызвало шквал критики и недовольства со стороны сообщества (ибо highload решения для которых производительность это все, используют скрытые возможности sun.*). Предыстория началась 15 лет назад с выходом версии языка 1.4, за это время большое количество библиотек, фреймворков, приложений успели внедрить закрытый код в свой.

    socmetr.unsafe.image

    Вот только не полный перечень проектов, которые у всех на слуху: 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).

    • +20
    • 10,5k
    • 4
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 4
    • 0
      По моей памяти речи про удаление Unsafe и прочего в Java 9 никогда и не шло — речь шла о том, что классы типа Unsafe перестанут быть доступными (by default), а станут именно что внутенними классами (что совершенно логично с учетом Jigsaw), но будут доступны при добавлении дополнительного флага. Т.е. если хочешь Unsafe — стартуй JVM с флагом.

      Что касается удаления вообще (после Java 9) — нужно понимать, что Unsafe нужны были для выполнения некоторых сугубо внутренних трюков. В Java 9 некоторые вещи в той или иной степени уже сделаны без Unsafe (например через VarHandles). Костыли в виде Unsafe уже не нужны, но увы, их нужно поддерживать, так как их уже используют библиотеки. А раз нужно поддерживать, то в итоге усложняется (и частично замедляется) та самая логика, которая стоит за Unsafe и VarHandles. Т.е. если бы Unsafe можно был выкинуть, то, возможно, JVM можно было бы в некоторых случаях сделать быстрее.

      С другой стороны — доступ к Unsafe без флага в Java9 будет для большинства удобнее.
      • 0
        разработчики как из open jdk, так и из Oracle
        Странная фраза…
        upd В данном случае это не одно и то же? Это какие такие разработчики из open jdk, которые не являются при этом разработчиками из оракла могли как-либо повлиять на создание JEP?
        • 0
          OpenJDK разрабатывает не только Oracle. Как минимум, есть еще SAP, а также множество других.
          • 0
            Из крупных ibm ещё, это-то понятно, но рулит на уровне JEP я думал только Oracle, ну ок.
            Про странность фразы я сказал, т.к. она контекстом показывает, что open jdk это не oracle как будто, но все разработчики из оракла это разработчики и из open jdk, т.к. oracle jdk это по сути open jdk (которая есть референсная реализация) давно, нет?

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.