2016-06-15 2 views
9

У нас есть ситуация, когда наше приложение включает JRE. Приложение, по ошибке, поставляется с mashup (версия 7.x версии java.exe и 8.x для остальной части JRE).Последствия старой версии Java.exe (7.1) с использованием новой версии runtime (8.x)

Я могу подтвердить, что процесс, выполняющий v. 1.7 java.exe, использует среду исполнения версии 1.8 с использованием Process Explorer. Я удивлен, что среда выполнения или двоичный файл не обнаружили аномалии и отказались от создания JVM!

Каковы последствия того же? Проблемы с безопасностью ? Проблемы стабильности? Я не использовал исходный код для java.exe. Из моих предварительных исследований двоичного кода java.exe я вижу, что это больше, чем заглушка. Он вызывает 100 различных API KERNEL32.DLL, кроме USER32.dll, ADVAPI32.dll, COMCTL32.dll.

Несомненно, мы можем (и мы обязательно) исправить ошибку. Но есть ли последствия для нескольких существующих производственных систем, которые используют вышеупомянутую аномалию? если да, то каковы они?

+0

следующее должно быть довольно полезно https://blogs.oracle.com/java-platform-group/entry/upgrading_major_java_versions_technical – piyushj

+0

@piyushj: спасибо. будет смотреть на него. – anjanb

ответ

1

java.exe является a simple launcher. Он не содержит код JVM или библиотеки классов. Его основная функция - просто найти JRE и загрузить jvm.dll с аргументами, переданными в командной строке.

Вы можете запустить JVM, используя Invocation API, даже без java.exe.

java.c log указывает, что в пусковом устройстве между JDK 7 и JDK 8 изменений очень мало. есть поддержка запуска приложений JavaFX и несколько исправлений для лучшей проверки аргументов. Вот и все. Поэтому, если ваше приложение начнет работать с пусковой установкой JDK 7, о чем, по-видимому, не о чем беспокоиться.

+0

Другими словами: «Это сработало до сих пор. Возможно, вам повезет». –

3

Каковы последствия того же? Проблемы с безопасностью ? Устойчивость вопросов?

Все эти.

JVM binary (java.exe в вашем случае), совместно используемые объекты/библиотеки DLL, которые поставляются вместе с ним, и файлы JAR, реализующие Java-часть всех вещей, входят в комбинированный пакет, который не предназначен и не предназначен для работать как ничего, кроме комбинированного пакета.

Известные списки проблем совместимости между Java 7 и Java 8 известны внешние проблемы между когерентными версиями всего пакета JVM.

Вы добавили внутренние несовместимости с некогерентных установки Java для этой известной внешней несовместимости. Невозможно получить список из них. Почти наверняка никто даже не пытается отслеживать такие вещи.

Вы не представляете, что должно работать, что будет работать, и как долго оно будет работать, даже если оно появляется для работы.

+0

'java.exe' не является двоичным файлом JVM. Это просто [простая пусковая установка] (http://stackoverflow.com/questions/26020872/totally-confused-with-java-exe/26025656#26025656). – apangin

+0

@apangin И как только один файл в том, что предполагается связным пакетом, как оказалось, исходит из неправильного пакета, * каждый * файл в этом пакете является подозрительным. Если у вас возникла проблема с запуском Java 7 'java.exe', а остальная часть установки JVM имеет неизвестное происхождение - как в вопросе - попробуйте подать отчет об ошибке в Oracle. Это * сломано *. Попытка увидеть, как долго вы можете уйти с ним, будучи сломанным *, просто просто * неправильно *. Вы исправите это *, как только сможете, потому что вы не знаете, что произойдет, а затем выясните, что пошло не так, чтобы вы не делали этого снова. –

+0

Вы правы в целом. Однако в этом случае проблема уже возникла, и ОП пытается оценить последствия. Я говорю о том, что последствия не так уж плохи, поскольку пусковая установка представляет собой отдельный компонент JRE, который связывается с JVM через стандартизованный API. Как известно, JVM работает даже без пусковой установки. – apangin

Смежные вопросы