Альтернатива устаревшему механизму отмены утвержденных стандартов и механизму расширения
Примечания к выпуску для Java 8 Update 40 (8u40):
Механизм переопределения утвержденных стандартов и механизм расширения устарели и могут быть удалены в будущем выпуске. Там нет никаких изменений во время выполнения. Существующим приложениям, использующим механизмы отмены утвержденных стандартов или расширения, рекомендуется отказаться от использования этих механизмов.
Существует также проблема, поясняющая, что с Jigsaw (планируется для Java SE 9, AFAIK) это будет как-то заменено модульным подходом:
http://bugs.java.com/view_bug.do?bug_id=8065675
Я понимаю, что Oracle хочет отказаться от этих механизмов сейчас, потому что они больше не могут поддерживать их в Java SE 9.
С другой стороны, не рекомендуется отказываться от чего-либо, не предоставляя альтернативы.
В примечаниях к выпуску говорится: "Существующим приложениям [...] рекомендуется отказаться от использования этих механизмов"
Итак, как вы можете "мигрировать от"
- механизм отмены утвержденных стандартов
- механизм выдвижения
в Java SE 8?
3 ответа
Я обнаружил следующую статью, в которой объясняется, что эти механизмы действительно планируется удалить в Java SE 9:
https://blogs.oracle.com/java-platform-group/entry/planning_safe_removal_of_under
К сожалению, сейчас кажется, что вы мало что можете сделать, например, для библиотек, которые являются частью JRE.
Что делать, если вы затронуты
Хотя большинство приложений не используют утвержденные стандарты или механизм расширения, некоторые приложения используют. Если вы разработчик, рассмотрите возможность предоставления зависимостей как части вашего приложения, а не требуйте настройки внешней системы. Если вы не являетесь разработчиком, обратитесь за помощью к поставщику программного обеспечения.
С Java 8 вы можете продолжать использовать устаревший механизм. Oracle предлагает только способ проверить, использует ли ваше приложение механизм с этим флагом java.exe -XX:+CheckEndorsedAndExtDirs
[ 1] доступно в Java 8 с обновлением 40 и позже.
При обновлении до Java 9, чтобы избежать сбоя приложения Java во время выполнения, с NoClassDefFoundError, вызванным ClassNotFoundException, например
Exception in thread "pool-1-thread-3" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at org.jacorb.orb.ORB._getDelegate(ORB.java:541)
at org.jacorb.orb.ORB.string_to_object(ORB.java:2110)
--snip--
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 26 more
вам нужно обновить командные строки запуска java.exe с помощью аргументов, таких как --add-modules --patch-module -add-exports
Конкретный пример см. В публикации Гжегожа Грзибека в сентябре 2016 года в рассылке jacorb-developer [ 2]. Нам пришлось обновить пакетный файл Windows нашего приложения дополнительными аргументами командной строки Java 9, такими как
java --add-modules "java.corba" --patch-module "java.corba=..\lib\jacorb-omgapi-3.4.jar" --add-exports=java.corba/org.omg.CONV_FRAME=ALL-UNNAMED --add-exports=java.corba/org.omg.CORBA_2_5=ALL-UNNAMED --add-exports=java.corba/org.omg.PortableGroup=ALL-UNNAMED --add-exports=java.corba/org.omg.ETF=ALL-UNNAMED --add-exports=java.corba/org.omg.GIOP=ALL-UNNAMED --add-exports=java.corba/org.omg.SSLIOP=ALL-UNNAMED --add-exports=java.corba/org.omg.CSIIOP=ALL-UNNAMED -jar ourapp.jar
Одна сноска, относящаяся к CORBA и Java, CORBA (и JAXB) намечена для полного удаления в Java 11. См. "JEP 320: Удаление модулей Java EE и CORBA" [ 3] и это сообщение в блоге [ 4].
Ваш запасной вариант сейчас заключается в явном перечислении ваших каталогов classpath и файлов jar при запуске экземпляра java.