My application uses authentication through a LDAP server over SSL. This requires installation of certificates in the bundled JRE's keystore. I use a script to do it through Java code and in the process need to find the location of the installed JRE. This script is executed at the end of the installation.
On Windows, it's relatively simple: I just use context.getInstallationDirectory() and then add jre\lib\security\cacerts.
On Mac OS, however, the JRE is installed in a different location and I would need to use the actual sys.preferredJre or the java.home property. The problem is that I can't access them from the scripts. The context object doesn't seem to have the corresponding methods. System.getProperty("java.home") returns a temporary location where the JRE is probably first unpacked and not the final path.
context.getCompilerVariable("sys.preferredJre") returns null.
As a side note, there doesn't seem to be any logging from inside the scripts. All I get is a brief message about the script succeeding or failing. I had to write to a custom file to get any information.
Can you suggest a way to handle this? Ideally, I would like to do it in OS-independent way and just get the Jre directory.
Thanks in advance
Sasha
After the "Install files" action has run, the sys.preferredJre installer variable is set to the directory where the bundled JRE has been installed. You can get this variable by calling
context.getVariable("sys.preferredJre")
In your question, you use getCompilerVariable, which is not correct because it returns values of compiler variables.
Related
The install4j variable sys.installationDir on MacOS (not the folder) returns just /Applications.
This makes sense since technically the directory the application was installed in was "/Applications" but I've used this variable inside my VM options to point to certain dependencies. This is causing me to have runtime errors. Is there another variable I should be using for this?
I've looked and I don't see any other options except to verify the platform and include the rest of the path.
You should use the installer variable ${installer:sys.contentDir} for that purpose, it always points at the directory where the distribution tree is installed.
I have a Java program that uses vlcj to play videos and that packages the VLC libs in the jar. At runtime, the VLC libs are extracted to the user's home, let's say path A. The normal way to indicate this path to vlcj is through the jna method:
NativeLibrary.addSearchPath(RuntimeUtil.getLibVlcLibraryName(), "A");
This works under Windows and MacOSX but not Linux where it throws a UnsatisfiedLinkError.
After some trial and error, I found that the only to get this to work under linux was by using
export LD_LIBRARY_PATH=A
prior to execution and despite the JNA documentation, none of these worked in JVM settings:
-Djava.library.path=A
-Djna.library.path=A
-Djna.platform.library.path=A
My problem with using LD_LIBRARY_PATH is that it is not something I can set at runtime (can I?) which I need to do. Does anyone know of a way to get around this?
I never found an ideal solution to this myself, but this is what I found during my trials with my own vlcj projects.
If you build VLC yourself on Linux you will see these warnings:
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
None of those things it suggests can you do from within your JVM, at least not without calling native code with privilege escalation.
So, in general what you are left with is: -Djna.library.path=LIBDIR should work; alternatively in code System.setProperty("jna.library.path", "LIBDIR"); should also work.
In fact I just tested that with my own native library that I happen to use in my own vlcj projects and both of those approaches worked just fine.
However, it seems it is not so easy with VLC itself, probably because of the way VLC loads its plugins.
In theory, if you structure your directories correctly, the plugins should get discovered automatically so you only need to point jna.library.path to the directory that contains the libvlc and libvlccore shared objects. In my build of VLC, the directory structure looks like this:
VLCDIR
VLCDIR/libvlc.so
VLCDIR/libvlc.so.5
VLCDIR/libvlc.so.5.4.0
VLCDIR/libvlccore.so
VLCDIR/libvlccore.so.7.0.0
VLCDIR/vlc/plugins
If this still fails then, again in theory, you can set the VLC_PLUGIN_PATH environment variable to point to the directory containing the VLC plugins. The problem is that this must be set for the native process, it will not work if you set it as a system property from inside your Java application.
I can only really suggest you generate a shell-script file that sets up the environment correctly when you install your application, or if you want to do it programmatically inside the JVM you could maybe have a bootstrap application that prepares the native environment and then kicks off a new Java process for your actual application - but it's messy to do things that way.
What I have also seen on Linux is that the library paths seem "baked in" to the ".so" files, and you can't just copy those files anywhere and still expect it to work. That is why you must use e.g. LD_LIBRARY_PATH or libtool or one of the other proposed solutions.
And this does not even touch on what you do with all the other libraries that VLC and its plugins may depend on at run-time - are you going to ship all those too?
My recommendation really is just to have the user install VLC first, or have your installer application install VLC first, by using the OS native package installation commands. Not ideal, but it works.
I am using install4J to distribute my application . However i am using serial port in my program therefore i will need the below file to be copied to the target JRE folder
%JAVA_HOME%/lib/ext/comm.jar
%JAVA_HOME%/bin/win32com.dll
%JAVA_HOME%/lib/javax.comm.properties
Is there any way i can do it by getting the Java Home Path via Install4J ?
Thanks
Since JAVA_HOME is not a Windows variable, it will be tricky to get it, and Install4J does not have a JAVA_HOME variable to my knowledge. While JAVA_HOME could be set on some computers, it is not safe to assume it is set on all computers.
What I would do, personally, is not touch the user's JRE. Bundle your own custom JRE with those files included into your install file generated with Install4J. That way, your program will always work with its own custom JRE that is independent of the system's JRE.
Copy the files to
${installer:sys.javaHome}
This is the JRE that the installer and subsequently your launchers run with. If you bundle a JRE, the value of this variables changes after the "Install files" action runs.
I have a Windows application based on Java, that I should like to install with Java bundled. The installation framework is NSIS. The application executable should be guaranteed to invoke the bundled Java, so there's no clash with other Javas installed in the system.
What's the best way to achieve my goal? I haven't tried to solve this kind of problem before, and have little experience with Java, so I don't know which solutions are out there. I think I'd prefer Java to be embedded in the application's executable, if feasible, otherwise I guess Java could be installed along with it (with the executable pointing to said Java).
Edit:
This project already generates an executable (.exe), via NSIS. The executable will by default use the system Java, but apparently it'll prefer a JRE in the same directory (i.e. bundled) if present.
Edit 2:
The scenario that made me want to bundle Java with this application was that I received an executable for it built with 32-bit Java, which failed (silently) on my system which has 64-bit Java.
Are you absolutely sure you don't want to use the computer JRE? In most cases it's preferable.
You can see here (and the included link) some examples with installers that check JRE number and install it (globally) if necessary.
If you really prefer to include your own JRE in the installer and always use it - what prevents you from doing it? It's just a matter of your main program point having some way of konwing the JRE location and forcing to use it. That depends on how you pack/invoke your Java program. Normally, it would be feasible, perhaps with a simple .bat file - perhaps to be created at installation time.
The solution we used(A few years ago, but still I think the best way).
Find a program which can generate an exe file from a jar file(Google is your friend, I can't remember the name). Note that this .exe file will still need a jre. It is just a smart way to make an exe which contain your .jar file, and which start the java process automatic. (This also allows you to set a custom icon on your .exe file).
The java sdk which you use to develop/compile your java application, also contains a folder called jre, which contain a copy of the jre.
Include this folder with the installer, so the jre folder is located in the same folder as the .exe file. Then the .exe file will use the included jre, and the jre will not be installed on the computer, so you prevent any problems.
Well one extremely simple solution that works actually quite nice if you don't have to get an executable, is just using a simple Windows Batch file that starts the jar and having a shortcut to it so you get your preferred icon on it. For the average user there's no real difference - after all the default is to suppress known extensions on Windows (horrible default but well) - and for people who do know what an exe is, the solution should be quite apparent anyways.
That way you can also easily start the included java or better yet offer both versions and just change a variable in an ini file, which really is much nicer - nobody wants or needs X different JRE versions that are outdated and are nothing more than security problems. Still can't harm to offer a version that includes the JRE for people without a java install to make it as simple as possible for them.
One example for this behavior would be weka..
launch4j seems to offer to bundle an embedded JRE.
This question already has answers here:
How can I get the latest JRE / JDK as a zip file rather than EXE or MSI installer? [closed]
(30 answers)
Closed 8 years ago.
I have seen many products bundeled with JDK, I wonder if there is a way where one can install JDK by simply unzipping contents to a directory, so there is no icon created in add/remove programs, no registry entries etc.
Also in this case:
How can we configure Java plugin for browsers?
And how can we configure settings as seen via Control Panel entry for Java?
According to this, I created a batch script to build jdk archives automatically.
The essential parts of the link are:
Create working JDK directory ("C:\JDK" in this case)
Download latest version of JDK from oracle (for example "jdk-7u7-windows-i586.exe")
Download and install 7-zip (or download 7-zip portable version if you are not administrator)
With 7-zip extract all the files from "jdk-[6-7]u?-windows-i586.exe" in directory "C:\JDK"
In command shell (cmd.exe) do the following:
change directory to directory C:\JDK.rsrc\JAVA_CAB10
execute command: extrac32 111
Unpack C:\JDK.rsrc\JAVA_CAB10\tools.zip with 7-zip
In command shell (cmd.exe) do the following:
change directory to C:\JDK.rsrc\JAVA_CAB10\tools\
execute command: for /r %x in (*.pack) do .\bin\unpack200 -r "%x" "%~dx%~px%~nx.jar" (this will convert all pack files into jar)
Copy whole directory and all subdir of c:\JDK.rsrc\JAVA_CAB10\tools" where you want your JDK to be and setup manually JAVA_HOME and PATH to point to your JDK dir and its BIN subdir.
Yes, you can create a zipped up JDK, unzip it on the target machine and run java, javac, etc. from that directory to your heart's content.
The easiest way to create such a zip file is to install the JDK on a machine and then zip up the contents of the JDK directory. We do this in certain circumstances where we need to control exactly what configuration of Java will be used in our deployments. In that case, our scripts just point JAVA_HOME (or the equivalent) to our internally bundled JDK instead of relying on a sysadmin to install exactly what we need prior to arrival.
In terms of integrating with the browsers, that can be a bit more problematic. The short answer is no, you can't integrate directly with the browser without some sort of installer.
You could use SysInternals RegMon and FileMon (now owned and dist by MS) to see exactly what is modified by the Java installer. I believe there will be a number of reg entries that you will want to create. Products like WISE installer, for example, also use this sort of approach under the hood to repackage product installations (e.g. as MSI).
Please be careful since there are also some dynamic decisions made by the installer which may affect what gets installed (e.g. on XP v.s. W2K3 server). I was bitten by this once regarding installed codepages. I do not recall the precise details, but the effect was that a codepage file was missing in my embedded JRE + JDK (legally redistributable portion only). This caused a very bizarre and seemingly nonsensical runtime error in my code. It goes without saying that the same applies to Server v.s. client JVM DLLs.
Really, no, at least if you want to use it from Windows and not from, say, cygwin. Windows depends too much on the registry; you could simulate the registry updates necessary, but software that moves the files to the right place and updates the registry is called "an installer"; you'd just be reinventing the installer.
I believe this at least used to be feasible to a limited extent with earlier versions of Java - I don't know if it still is.
Most of the registry entries are used for things like browser plugins, as you mentioned in the question. If you just want to be able to run Java (e.g. from a batch file), that's one thing - but really installing it is a different matter. Even if you're just wanting to run it, you'll need to be careful to always explicitly use the one you intend, rather than using the installed one accidentally for part of your application.
What's your actual use case? Do you actually need a browser plugin? What aspect of the configuration are you interested in? A lot of the control panel configuration is to do with updates and browser integration. Many other aspects can be controlled using command line options to set specific system properties.
If you just want to provide a JVM with your application is fine, but more than that I would not recommend.
If you just want to have the JDK (JRE) files, you can run the installer within sandboxie. Once installed in the sandbox, just copy the files from c:\sandbox and you are done.
I'm using this to compile and run legacy java applications which cannot be migrated easily to a newer version of java. I can point Eclispe to this JDKs and tell it to be compliant to Java 1.3.
Just down load the Windows server version of Java from the Oracle downloads page. Setup JAVA_HOME and PATH variables on your own.