Сделать мою Java-программу легко распространяемой - PullRequest
0 голосов
/ 20 мая 2011

Я установил Java 3D API на ПК через установщик exe, который просто создал новый каталог с j3dcore.jar, vecmath.jar, j3dutils.jar в подкаталоге lib и j3dcore-ogl.dll в подкаталоге bin.directory.

У Netbeans проблем не было, и мой код компилировался и выполнялся гладко, однако, как только я собрал свой проект и попытался запустить его из командной строки, я получил UnsatisfiedLinkError, говорящий, что no j3dcore-ogl in java.library.path.

Google пришел на помощь и дал мне 3 жизнеспособных решения:

  • , скопировав файл dll в каталог bin моего JRE
  • , добавив путь к dllфайл к пути к библиотеке (java -Djava.library.path=dllpath)
  • загрузить dll в программе с помощью System.load() (на самом деле я не смог заставить его работать)

Мой вопросесть: есть ли элегантное решение этой проблемы, которое я пропустил?

Кажется утомительным, что для каждого отдельного ПК, на котором кто-то хотел бы использовать эту программу, ему пришлось бы либо скопировать dll, либо добавить ее в путь к библиотеке, прежде чем она сможет работать.(Дополнительный вопрос: почему у Netbeans не было проблем с DLL?)

Ответы [ 4 ]

1 голос
/ 20 мая 2011

Создание моей Java-программы, легко распространяемой

Если вы имеете в виду «легко для конечного пользователя», посмотрите Java Web Start .


Прохожий спрашивает:

Можете ли вы упаковать зависимости dll с помощью Web Start?

Да, но намного, намного лучше. Вы можете упаковать нативы для каждой платформы в отдельные Jar-файлы и предоставлять их только той платформе, которая использует этот натив, даже при разделении загрузки между 32- и 64-битными версиями нативов.

JWS помещает нативы в путь класса приложения во время выполнения, готовый для загрузки в код.

Все это происходит автоматически для конечного пользователя, он щелкает ссылку, утверждает диалог (-и) доверия, когда его спрашивают, и приложение устанавливает - возможно, с интеграцией с рабочим столом, и появляется на экране как волшебство.

Приложения JWS. которые используют native должны быть распределены как all-permissions уровень безопасности, потому что JVM не может гарантировать действия чего-либо, что «становится собственным».

0 голосов
/ 17 июня 2011

Редактировать - после повторного прочтения вопроса ваш вопрос звучит иначе.Тем не менее, я могу запустить свою работу так, просто сбросив все dll-файлы в том же каталоге, что и файл .bat, запустив процесс java:

java -classpath ./YourJar.jar; ./ lib / j3dcore.jar; ./ lib / vecmath.jar; ./ lib / j3dutils.jar package.MainClass

И это работает на ПК нескольких пользователей, поэтомуЯ знаю, что простое удаление в рабочий каталог работает.

Я считаю, что это зависит от используемой версии Java - 64-битной или 32-битной.Правильный файл dll (с тем же именем) должен находиться в рабочем каталоге.

Я думаю, что у меня возникала подобная проблема, когда использовался неправильный dll, и он не зависит от ОС (если ваш 64В битовой ОС установлена ​​32-битная Java, вам понадобится 32-битный файл j3dcore-ogl.dll).

Итак, вопрос в том, какую версию Java вы используете (при запуске вневаша IDE) , а какую версию dll вы помещаете (если есть) в рабочий каталог?Мне не нужны никакие dll-файлы в настройках пути, чтобы это работало на компьютерах других пользователей, и я не использовал System.load () и НЕ копировал файлы в каталог JRE / bin моего пользователя - так что я знаю, что это возможно без3 варианта, которые вы упомянули.

0 голосов
/ 20 мая 2011

Я полагаю, что DLL ищутся во всех папках в% PATH% на окнах. (LD_LIBRARY_PATH для разновидностей UNIX)

Не могли бы вы попробовать добавить путь к dll в переменную% path%?

Похоже, вы пытаетесь упаковать продукт со многими банками в качестве зависимостей. Вы можете воспользоваться One-Jar . Он утверждает, что имеет собственную поддержку dll.

0 голосов
/ 20 мая 2011

Если вы поместите dll в тот же каталог, что и Jar, это сработает? Если да, вы можете рассмотреть возможность его распространения следующим образом.

...