Альтернатива механизму переопределения устаревших одобренных стандартов и механизму расширения

В примечаниях к выпуску 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?


java java-8 java-9
person Puce    schedule 11.03.2015    source источник
comment
Где сказано, что это не поддерживается в Java 9?   -  person user207421    schedule 11.03.2015
comment
@EJB Вот что я понял. Например. в выпуске: В дальнейшем мы ожидаем поддержки утвержденных стандартов и автономных API только в модульной форме, посредством концепции обновляемых модулей [2]. Может быть, я тоже что-то читал об этом на других ресурсах. И AFAIK Jigsaw планируется для Java SE 9. Но опять же, это, по крайней мере, мое текущее понимание, не обязательно факт. У вас есть другая информация по этому поводу?   -  person Puce    schedule 11.03.2015
comment
«Вперед» != Java 9. Вы зря паникуете. Они не упомянули целевой выпуск или сроки. Я думаю, вы в безопасности, пока не выйдет хотя бы один основной выпуск с обоими присутствующими механизмами: может быть, два или более.   -  person user207421    schedule 12.03.2015
comment
@EJP, может быть, ты прав. Тем не менее, есть ли способы отказаться от того, что предлагается в примечаниях к выпуску 8u40, чтобы мы могли подготовиться к новой ситуации и избежать использования устаревших функций? Или это возможно только с Jigsaw (но тогда предложение, по крайней мере, в настоящее время сбивает с толку)?   -  person Puce    schedule 12.03.2015
comment
@EJP Некоторая справочная информация: это не только теоретический вопрос, но в настоящее время я нахожусь в ситуации, когда я думаю, что мне нужно использовать одобренную библиотеку в структуре, которую я пишу. Читая эти примечания к выпуску, я понимаю, что буду использовать то, что уже устарело. Итак, мой вопрос: есть ли лучший способ в то время? Связанный с этим вопрос: stackoverflow.com/questions/26769891/   -  person Puce    schedule 12.03.2015
comment
@EJP: их действительно планируется удалить в Java SE 9. Я нашел еще одну статью. Смотрите мой ответ.   -  person Puce    schedule 12.03.2015

Ответы (3)


arrow_upward
3
arrow_downward

Я нашел следующую статью, в которой объясняется, что эти механизмы действительно планируется удалить в Java SE 9:

https://blogs.oracle.com/java-platform-group/entry/planning_safe_removal_of_under

К сожалению, сейчас вы мало что можете сделать, например. для библиотек, которые являются частью JRE.

Что делать, если вы пострадали

Хотя большинство приложений не используют утвержденные стандарты или механизм расширения, некоторые приложения используют их. Если вы разработчик, рассмотрите возможность предоставления зависимостей как части вашего приложения, а не требующих конфигураций внешней системы. Если вы не являетесь разработчиком, обратитесь за поддержкой к отдельному поставщику программного обеспечения.

person Puce    schedule 12.03.2015

arrow_upward
2
arrow_downward

С 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

Конкретный пример см. в сообщении Grzegorz Grzybek от сентября 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].

person buzz3791    schedule 05.05.2017

arrow_upward
-1
arrow_downward

Ваш запасной вариант прямо сейчас заключается в том, чтобы явно перечислить каталоги пути к классам и файлы jar при выполнении экземпляра java.

person Robert Casey    schedule 23.02.2017
comment
Обычный путь к классам не может заменить классы, предоставляемые JRE, AFAIK. - person Puce; 24.02.2017
comment
Те, которые предоставляются JRE, используются по умолчанию. Расширения были добавлены пользователем извне к пути JRE и обычно считаются анти-шаблоном. Я никогда не использовал функцию одобренных каталогов. Все внешние зависимости лучше всего перечислять в пути к классам. Вместо этого все, что у вас есть в расширениях, должно быть предоставлено в виде каталога .jar или класса, а также в пути к классам. Во всяком случае, это мой взгляд на это. - person Robert Casey; 26.02.2017