I have a working JNLP application which I need to distribute to various non-technical end users.
If the user's machine has a recent JVM installed, everything is fine. They just double-click the JNLP file I send them and Java Web Start does the rest.
Now I would like to distribute something that works with or without a JVM, e.g. a .exe file that auto-downloads a compatible JVM if none is present, then invokes javaws.exe to download the .jar files and launch the application.
Launch4J is the closest match I have found, but it cannot launch a program through javaws.exe. The only options are java and javaw
I would like a product that can:
Generate a self-contained .exe file that does not require a JVM to be pre-installed
Parse the .jnlp file and determine the correct JVM to download if necessary (I know Java Web Start can download a JVM if necessary, but I want to avoid having to download two, the first to bootstrap Java Web Start and the second to run the application which may require a specific but different JVM.)
Download and install the JVM automatically, not simply direct the user to a Java download page or open a new installation wizard.
Prompt for an admin password if necessary (for permissions to install the JVM. I don't think this is built into the Sun JVM installers.)
Show only one security dialog (I would like to prompt the user just once, to confirm they trust the generated .exe, but I do not want a second prompt to confirm they trust the .jar file which will be from the same source and signed with the same certificate.) I assume this will require the auto-downloader to install the certificate before launching JWS.)
(not essential) Download application resources (e.g. .jar files) in the background simultaneously with the JVM. This would require the cache to be running before the JVM is installed, so the cache would have to be implemented in native code and the DownloadService would later interface to it using JNI.
Does a product like this exist? I suspect it does not but It's worth a shot.
Update I found this article which has solutions to some related problems, though it is designed for offline installation and I am mostly concerned with online installation.
I have been able to do this & use it in production.
write a simple bootstrap class, jar it, and Launch4j the jar.
here's the main for the simple bootstrap class:
public static void main(String[] args) {
try {
final File jnlp = File.createTempFile("temp", ".jnlp");
final URL url = new URL("http://yourjnlp-wherever-youre-hostingit.jnlp");
yourCopyStreamMethodYouWrote(url.openStream(),new FileOutputStream(jnlp));
Desktop.getDesktop().open(jnlp);
} catch (final Throwable t) {
// do something useful here
}
}
You can also consider compiling your project with Excelsior JET. Apart from everything else it also creates a self-sufficient distribution of reasonable size.
I've run into the same problem. I ended up with a BAT, a Shell and eventual a DMG for Macs.
I found this comment on automaded JRE installation for Windows using Nullsoft installer:
http://nsis.sourceforge.net/Java_Launcher_with_automatic_JRE_installation
I think outside JNLP you will find hard to get automation for all platforms. However on my project, up for two year, I haven't seen complains about users having to get java by themselves. I believe most machines will have it already. Windows user complained about not having a shortcut, but that is easy to do using vbs.
Also on the Mac DMG AppBundle, their is way to specify the JRE. Mac will have the lastest version, unless the are older PowerPC based machines. In that case no Java6.
Of you end up with several launcher, I would recommend an automated update strategy.
Another approach might be also distributing a Sun JRE with a .BAT-file invoking it with the /S switch, which cause a silent install.
I have not seen anything else allowing for a completely silent Java install combined with invoking javaws.
Ok i get what you are trying to do but why don't you want use javaws? Launch4J looks like a good option as alternate to having java installed, as it will allow seamless usage of the jar file.
javaws is more or less uses java.exe with security permissions and some launch options. But the security permissions can be disabled if you use a certificate that the user trusts.
Also i am unsure when javaws was introduced but i am sure it was available in java 1.5 which i near EOL. So unless your user has not had a java installed for many years i doubt getting them to launch jnlp would be a problem. Even if they are running an older version you can add a required version of java to the jnlp and this will be automatically downloaded for that application only.
Though not free for non-commercial use, Install4j offers a native installer system for Java applications. JRE bundling is supported. I am not sure it can parse JNLP automatically, but it may be something worth checking out.
As an sample use case, the Java-based Integrated Genome Browser gets distributed with an installer generated by this tool. See its install4j configuration file.
Related
I have an OS X objective-c app which programmatically invokes the Java command to run a Java program.
If I'm correct, Java is no longer installed by default on OS X. I want to ship my app and not force users to download Java before they can use the app.
How can I ship a copy of the java executable along with the runtime (rt.jar). Of course I can copy rt.jar in the app bundle of course but what about the java binary? Can I just copy this as well?
I think in your case, the best option would be to include the Java Installer Kernel (small install that downloads and installs the latest version of Java, if necessary).
The main problem with bundling the binaries per-se in your app is basically, security. Vulnerabilities are discovered routinely in the JRE and patched. If you bundle an specific version and a vulnerability is discovered after your release, you will be basically weakening the security of the machines where your application is installed. As you obviously don't want to do that, it is better to try to include logic to detect if a compatible version is present, or otherwise properly install the right version. Many installer packages include options like this: For example, OpenOffice/LibreOffice are native apps but they require Java to be present, and they use a similar installation method as the one described above.
Each self-contained application package includes the following items:
Application code, packaged into a set of JAR files, plus any other application resources (data files, native libraries)
Copy of the JRE, to be used by this application only
Native launcher for the application, multiple launchers for a single package are supported
Metadata, such as icons
Multiple package formats are possible. Built-in support is provided for several types of packages. You can also assemble your own packages by post-processing a self-contained application packaged as a folder, for example if you want to distribute your application as a ZIP file.
--
Self-contained application packages have the following drawbacks:
"Download and run" user experience
Unlike web deployment, the user experience is not about "launch the application from the web." It is more one of "download, install, and run" process, in which the user might need to go through additional steps to get the application launched. For example, the user might have to accept a browser or operating system security dialog, or find and launch the application installer from the download folder.
Larger download size
In general, the size of self-contained application packages is larger than the size of a standalone application, because a private copy of the JRE is included.
Package per target platform
Self-contained application packages are platform-specific and can only be produced for the same system on which you build. To deliver self-contained application packages on Windows, Linux, and OS X, you must build your project on all three platforms.
Application updates are the responsibility of developer
Web-deployed Java applications automatically download application updates from the web as soon as they are available. The Java Autoupdate mechanism takes care of updating the JRE to the latest secure version several times every year. Self-contained applications do not have built-in support for automatic updates.
You can ship a JRE with your app (see licensing). To give the user a copy of JRE, put one in and let them install it themselves or make a application bundle.
OK, I’m still a little overwhelmed by all the choices for deploying an application. My case is really simple. I have a Java program that’s now working in NetBeans on Win7. I want to run it on another Windows desktop that doesn’t have NetBeans.
The method presented here: https://netbeans.org/kb/docs/java/native_pkg.html produces a single .exe file that installs the application on the Win desktop. But, that file is huge because it includes all required portions of the JRE.
The method presented here https://netbeans.org/kb/articles/javase-deploy.html uses the JRE already installed on the Win desktop so the distribution is very small. But, it requires you to distribute both a .jar file and a lib folder.
So, finally, the question. Is there a method that uses the already installed JRE and only requires the distribution of one (small) file?
Thanks.
Since that second option has everything you need to run the app (provided that a JRE is available), you can use that with a third party install packager like izpack
The Problem
Currently I use exe4j 4.4.2 to wrap our client app in a Windows native executable, but the result does not integrate with Windows 7 so well.
For example: When I right click in the task bar it only offers a pop-up to close the application but no pinning. Eclipse' Equinox launcher on the other hand does that with bravado.
I'm looking for a java exe launcher which has the following features:
Wraps jars in Windows native executables (no Java Web Start or similar)
Doesn't extract the jar from the executable
Doesn't need write access in "Program Files"
Uses executable filename as process name (only one process)
Integrates well with Windows 7 (esp. pinning in the taskbar)
Allows setting of JVM arguments (esp. heap size)
Flexible customization for JRE search
Lightweight
Actively maintained
Integrates well in Ant build
Preferably free
I have checked the following:
exe4j
Windows 7 integration lacking
It's not expensive but ordering and
distribution of licenses to the build machines is a pain.
JRE search not flexible enough
Eclipse Equinox
Not lightweight
Seems to do everything I want, except that I have no idea how
to use it with a non-eclipse-based app.
Can I use it outside of OSGI, PDE-Build world?
WinRun4J
JRE search not well documented
Seems not widely used despite incredible feature set, what am I missing?
Launch4J
Doesn't support setting the process name in Windows 7 (Bug ID 3353972).
There is a patch (Bug ID 1670471) but it has been rejected with reference
to jliftoff which is dead.
JRE search not flexible enough.
JSmooth
Seems not to be actively maintained.
Latest release is from 2007, well before Windows 7.
Are there any other options?
Is there a chance to use the Eclipse launcher with a non Eclipse-base application?
Try Advanced Installer http://www.advancedinstaller.com/java.html (There is a free edition available in this).
I'm happy with WinRun4J. The JRE search works fine for me. It sometimes chokes especially on 64bit systems if multiple JREs and JDKs are installed and registered in the Windows registry, but this can usually be fixed by supplying the correct path in the corresponding .ini file.
I did not use Launch4J because it creates a new (temporary) .exe in the JRE installation folder which seems a bit strange to me. The advantage of that method is, that it can use a single .exe for both 32 and 64 bit JVMs though
It sounds to me like you just need to go with Launch4J. The process name matches the .exe name that you launch with. A great example of a program that is wrapped this way is "Keystore Explorer 4.01".
I would create a bat file. Wrap this bat file into a exe. You can create an exe with an icon and everything. Try this bat to exe converter:
http://download.cnet.com/Bat-To-Exe-Converter/3000-2069_4-10555897.html
In this way, you have better control. The size of the exe is very small.
Edit: Also, the creation of the exe is one time thing.
I make my executable jar in exe format, but I want to add JRE with this because if JRE is not present in their machine, they can use it with this included JRE.
But I do not want to install this JRE in their machine. This JRE is only used by this application only. It will just like game or other application. I use launch4j to make jar to exe but i did not find any option from where it can attach JRE and it has no option from where I can link my jar dynamically.
How do I achieve that?
If there is other free installer then mention it, and please give the procedure with example.
Since it has been established that your app. has a GUI, I will suggest Java Web Start as the answer.
But I do not want to install this JRE in their machine.
That is not a sensible requirement. The user might already have a usable JRE installed, if they don't they probably also don't want every Java based application to be installing its own 'private' JRE.
Oracle's deployJava.js can do the checking, and help guide the user through the steps of installing (which basically comes down to click 'OK' when prompted).
I make my executable jar in exe format,..
If you only intend to support Windows, what is the attraction of coding in Java? JWS supports any platform for which Java is available. That brings a lot more potential customers for the app.
I want to use free installer.
JWS is entirely free. Just like the JRE.
..please give the procedure with example.
Do you run an IDE? If not, do you otherwise have Ant installed? If that is a yes to either one, check out my small JNLP API examples. Each comes with complete source and a build file (an Ant build.xml).
Within a couple of keystrokes & a few moments, you can see the app. installed and launched on your desktop. For the end user, it is even simpler. Just click a link in a web page, and it all happens automatically (possibly with a security prompt - for the protection of the user).
I like JSmooth. You can give it a try here:
http://jsmooth.sourceforge.net/features.php
Flexible automatic Java VM detection
Detects the location of any Sun JVM installed. The wrappers use
several strategies to detect all the JVM available on a computer,
using windows registry, environment variables, windows path.
Detects
and uses Microsoft's JView (for 1.0 and 1.1 Java applications), if
available.
The JVM search sequence is fully customizable using the
GUI. You can force the executable to search in the path first, and in
the registry last, or in JAVA_HOME first. We have all the flavours!
Sometimes it's more convenient to bundle a JRE with your application.
JSmooth can deal with that too, you just need to define in which
folder the JRE is expected. It falls back nicely to a standard JVM
search if the JRE is not where it should be.
Specify which versions of
the JVM are compatible with your software. You can set a minimum
version, but also a maximum JVM version.
Documentation: http://jsmooth.sourceforge.net/docs/jsmooth-doc.html
Take a look at launch4j.
I had to use it, and it worked out very well.
You can set a minimum version of a needed JRE, bundle a JRE, or if a JRE is not found (and not bundled) the launcher may lead the user to a download location of an appropriate JRE.
There are various further features launch4j offers, and as opposed to another suggestion here, launch4j is activly developed
http://launch4j.sourceforge.net/
I've got a Java application that I'm writing an installer for. We're using the AdvancedInstaller program to create our installer (well, we're evaluating it currently, but will definitely purchase a license soon), and although it has special support for Java applications, it is geared more towards repackaging them as desktop-type apps, and our software is a series of Java services and other utilities which doesn't make sense to distribute in EXE-wrappers. The target audience for this software is very specific, and we know that our software will probably be automatically distributed on freshly-imaged Windows 2003 Server machines. So requiring Java as a prerequisite basically makes more work for some poor sysadmin, and I'd rather avoid that if at all possible by repackaging the JRE's installer inside of our own.
I discovered that if I tried to execute the JRE's installer as a pre-install step from my MSI, it complains that another installer is already running (mine, of course), so it bails out. When I try to add the JRE installer as a software prerequisite in the AdvancedInstaller project (as a bundled EXE, not a URL link), it never seems to actually get installed, despite me trying to force-install it.
What's the best way to repackage the JRE? I'm not really a Java guy, so I don't know too much about how other developers deal with this same problem, short of requiring their users to hunt out and install the JRE on their own. The ideal solution here would be for us to find a EXE installer which can be executed from inside of another MSI installer, or if it's possible, to just package all of the files inside of the JRE and then create the appropriate registry and environment variables. How should I go about doing this?
I have not idea if this is "the way" to do it, but confronted with a somewhat similar problem, we simply archive an installed JRE with the rest of our application files and make sure that all our start scripts don't use java ..., but rather ..\..\jre\bin\java ... or similar. The JRE is unpackaged as part of our installation process in a subdirectory of where we install and that's that.
I agree with bdumitriu's answer:
a simple zip of a jre is enough, unless you want to link that jre to:
default java (meaning you must add java.exe of the unzipped jre to the path, before any other java path references)
default java for some script (you could define JAVA_HOME as referencing your new unzipped jre, but that may have side effects on other script also using JAVA_HOME before that new JRE)
file associations like .jnlp or .jar files (this requires some registry modifications)
browser java plugin registration (which requires also registry modifications)
If the last two points do not interest you on the desktop concerned by this deplyment, a simple zip is enough.
http://www.syswow64.co.uk/2013/05/java-7-update-21-1721-enterprise.html
The issue on many blogs and articles is around creating the 'deployment.config' and 'deployment.properties' files for an enterprise deployment. In my case i wanted to set the security level to 'Medium', but everytime I open the Java control panel it was set to the default HIGH setting.