Я читаю здесь, что Spring и многие другие популярные библиотеки будут разбиты, если Oracle удалит sun.misc.Unsafe в Java 9. Однако есть нет статических ссылок на этот класс в Spring или Hibernate. Итак, это утверждение верно?
Кстати, в Java 8 есть 64 ссылки на Unsafe, но если Oracle удаляет этот класс, они будут обновлять все из них, и никакая библиотека не будет затронута (если они не используют непосредственно Unsafe).
Марк Рейнхольд говорил на JVM Language Summit 2015 под названием "Тайная история и трагическая судьба sun.misc.Unsafe" . Хотя на этих переговорах есть много оговорок, вы можете увидеть предлагаемый подход в 10:23, который описан в JEP260.
Общая идея:
Unsafe, которые были замененыВот какой-то соответствующий текст из JEP260 (взятый с 20 октября 2015 года):
В JDK 9 мы предлагаем:
Инкапсулировать все некритические внутренние API по умолчанию: модули, которые их определяют, не будут экспортировать свои пакеты для внешнего использования. (Доступ к таким API-интерфейсам будет доступен, в крайнем случае, с помощью флага командной строки как во время компиляции, так и времени выполнения, если эти API не будут пересмотрены или удалены по другим причинам.)
Инкапсулировать критические внутренние API-интерфейсы, для которых поддерживаемые замены существуют в JDK 8, таким же образом и с использованием того же метода обхода последнего пути. (Поддерживаемая замена - это часть, которая является либо частью стандарта Java SE 8 (например, в пакете java. * Или javax. *), Либо специфична для JDK и аннотируется с помощью @jdk.Exported(обычно в com.sun. * или jdk. *).)
Не инкапсулировать критические внутренние API-интерфейсы, для которых поддерживаемые замены не существуют в JDK 8, и, кроме того, обесценить те, которые поддерживали замены в JDK 9, с целью их инкапсуляции или, возможно, даже их удаления, в JDK 10.
...
Критические внутренние API, для которых в JDK 9 заменены замены, будут устаревать в JDK 9 и либо инкапсулированы, либо удалены в JDK 10.
Возможно, ссылки не находятся в ядре Spring или Hibernate, но где-то еще. В связанном документе говорится о Spring
Spring Структура (через Objenesis, с отступлением)
Я попытался выполнить поиск Unsafe в проекте, над которым я сейчас работаю, поэтому есть все еще некоторые библиотеки, которые могут сломаться.
результат быстрого поиска:
Этот ресурс обеспечивает правильное понимание текущего состояния JDK 9 и его возможностей. Сообщество начало обсуждение, посвященное Unsafe и его будущему в будущем java. Данный документ представляет собой попытку сообщества отреагировать на JEP-260, в котором предлагается скрыть некоторые внутренние API, но оставив доступным некоторые критические API, среди ведьм Unsafe, Как извлечено из самого документа:
Критические внутренние API, предлагаемые оставаться доступными в JDK 9, следующие:
sun.misc.Cleaner
sun.misc. {Сигнал, SignalHandler}
sun.misc.Unsafe(Функциональность многих методов в этом класс теперь доступен с помощью дескрипторов переменных (JEP 193).)
sun.reflect.Reflection:: getCallerClass (Функциональность этого метод может быть предоставлен в стандартной форме через JEP 259.)
sun.reflect.ReflectionFactory
Итак, чтобы заключить, по крайней мере, исходя из с учетом JEP, Unsafe должен оставаться.
Ответ указан в связанном документе. Spring не имеет прямой зависимости от Unsafe, но Spring зависит от Objenesis и Objenesis зависит от Unsafe.
Зависимость для Objenesis на Unsafe: https://github.com/easymock/objenesis/blob/master/main/src/main/java/org/objenesis/instantiator/sun/UnsafeFactoryInstantiator.java
Spring зависимость от Objenesis сама по себе немного странная. Spring build script извлекает двоичный код Objenesis и производит изменения уровня байт-кода с помощью инструмента JarJar. Вы можете увидеть, что он делает в следующей сборке script: https://github.com/spring-projects/spring-framework/blob/master/build.gradle (на момент написания см. Строки 326-343 и 347).
Это по существу означает, что двоичный файл Spring "spring -core" заканчивается тем, что содержит нагрузку классов в структуре пакета org.springframework.objenesis. *, но эти классы были первоначально сохранены в источнике в Objenesis GitHub, опубликованном как двоичный файл команды Objenesis, полученной во время сборки Spring, переупаковкой в пакеты org.springframework. *, а затем переиздан как часть Spring. Вот почему вам не удается найти их.
Spring использует Unsafe (через Objenesis) для создания классов без первого вызова конструктора.