У меня Java вызывает библиотеку C ++ / CLR через JNA.При подключении к C # DLL (используя #using) C # DLL ДОЛЖНА находиться в System32, больше ничего не будет делать, в противном случае JVM падает (по очевидным причинам).
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_windows_x86.cpp:149), pid=9932, tid=7464
# guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result from topLevelExceptionFilter
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode windows-amd64 compressed oops)
# An error report file with more information is saved as:
# (log dir)
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Звучит как проблема с путём, верно?Хорошо, вот где это смешно:
Это работает:
C:> set PATH = C: \ Program Files \ Java \ jre6 \ bin; C: \ workspace \ bin\ plugins \ 64; c: \ Windows \ System32
Это не:
C:> set PATH = C: \ Program Files \ Java \ jre6 \bin; C: \ workspace \ bin \ plugins \ 64
Да, библиотека находится в c: \ workspace \ bin \ plugins \ 64
Обратите внимание, что если system32 включен впуть, он находит мою библиотеку, поэтому он правильно копает каталоги PATH (или так кажется), однако, если я отбрасываю его непосредственно там, где моя DLL находится в моей рабочей области, он не запускается.Я сомневаюсь, что это из-за того, что это .NET DLL (регистрация в GAC не может это исправить, хотя, если это не удалось), и у меня есть ощущение, что это просто проблема поиска библиотеки.
Я что-то упускаю из-за того, что Java может делать с путями поиска в моей библиотеке?Я не могу гарантировать, что у меня есть возможность писать в System32 (не говоря уже о том, что мне нужно сделать некоторые автоматизированные действия и я хотел бы держаться подальше от каталогов ОС).
Редактировать 1:
Это не сработает, если моя C # DLL не находится в c: \ Windows \ System32, а вместо этого находится в C: \ workspace \ bin \ plugins \ 64, поэтому, исходя из своего глупого предположения, я мог бы прогнать System32 из уравнения.
C:> set PATH = C: \ Program Files \ Java \ jre6 \ bin; C: \ workspace \ bin \ plugins \ 64; c: \ Windows \ System32
Перемещение DLL обратно в c: \ windows \ system32 позволяет ей работать.
Редактировать 2:
Если это имеет какое-то значение, он вообще не будет запускать , еслион запускается из Eclipse вместо командной строки ... System.getenv ("PATH"), запускаемый из Eclipse, показывает мой полный путь, и удаление C # DLL из C ++ / CLR DLL позволяет ему работать.
Так что это полностью .NET DLL, запускающая Java из командной строки. .NET DLL должна быть в System32 и вообще не работать в Eclipse.
IЕсли вы отбрасываете .NET DLL из C ++ / CLR DLL, она может работать где угодно в любое время.
Редактировать 3:
Кажется, что работает нормально при регистрации в GAC (время чувствовать себя плохо,Клянусь, раньше это не работало) и связано с этой проблемой:
Вызов сборки .NET из Java: сбой JVM
Теперь, чтобы посмотреть, смогу ли я получитьAssemblyResolve для работы на C ++ / CLR, что чрезвычайно сложно из-за того, что это библиотека.