I'm considering bundling a JRE with my Java application. I'm using Launch4J. Looking around stackoverflow this seems easy enough to do. What I've not seen any information on is where I get the JRE from in a controlled manner.
I'd like to be able to control from a single place what version of the JRE is bundled. I don't want to be manually updating/installing JRE's on n number of build machines each time we decided to use a different JRE. Placing the JRE under source control seems the most logical option. Our build is done using maven, I assumed there would be some kind of maven plugin that would download a configured JRE version and put it in the target folder for you.
So, what is best practice to control which JRE is bundled with my app?
check the Maven enforcer plugin http://maven.apache.org/enforcer/enforcer-rules/ and in that check for requireJavaVersion http://maven.apache.org/enforcer/enforcer-rules/requireJavaVersion.html . this will add checks to the build that fail when the inapproriate JRE is used.
Related
UPDATE: Looks like it's not possible yet: https://youtrack.jetbrains.com/issue/IDEA-240044
I'll update the question with an answer, once this issue is resolved (this way or the other)
I have a super-special version of the JDK customized to compile and run a desktop client I am providing as an IntelliJ project (with source).
Users of my client can't get it to work with the Java they have installed on their work stations by our corporate IT.
On the other hand, they need that standard Java to run other things. The custom JDK is not good for running the other Java applications our corporate requires (so, I can't just have my JDK as their system-wide JDK).
Also, the work stations of my users do not support containerization.
So, I am thinking to bundle my JDK with the project and configure it to use that SDK. This is going beyond just preparing a "setEnv.bat" script with "JAVA_HOME=/xjdk" for many reasons, like being able to debug using the IDE, when the IDE is debugging code compiled with the special JDK...
I know IntelliJ has places to set up the JDK and JRE but not sure how to do this in a "relative path" way and such that will run on both Mac/Win without them having to configure the project for the absolute path of the bundled JDK?
Assume the project structure is something like this:
ProjectFolder
|_ src
|_ xJDK
What IntelliJ/Maven elements do I need to set to get both compile and run using xJDK?
Does the version of Eclipse affect the version of code? Suppose, developers are using different version of Eclipse for same version of code with same version of JDK. Will it cause any issue?
No, the version of Eclipse does not matter.
Eclipse has extensive configuration for exactly which version of Java you are targeting. For example see the 'Java > Compiler' settings in the Preferences, and the 'Compiler Settings' in the Properties for a Java project.
You can also tell Eclipse which JRE/JDKs you have installed (see the 'Java > Installed JREs' page in the Preferences). You can run your code using any of these JREs, this is completely separate from the version of Java you are using the run Eclipse itself.
You do need to run a version of Eclipse which understands the version of Java you want to use. So for Java 13 you need to use at lease Eclipse 2019-12.
Of course newer versions of Eclipse contain more tools for helping with Java development and more bug fixes so using an up to date version is recommeneded.
Eclipse is simply an IDE (Integrated development environment). It combines debugging, compiling and other convenient tools for development. on the other hand, the Java code itself is separate, and you don't necessarily need eclipse to write the code. In fact, a simple text editor is enough. All you need is a file with a java extension (Example: hello.java).
It depends on what users share. I'm assuming you're using some sort of SCM, in which case the same project (fully shared) on different versions of the IDE can possibly lead to annoying situations.
There would be no issues in general, as far as producing the code is concerned, except in situations where some versions of IDEs don't support the required Java version (or other features). But I see this more as the user being affected rather than the project/code.
Here's what you should keep in mind:
Keep IDE project configuration files (such as .project, .settings, .classpath) ignored by your SCM system
All Java configuration should be based on a build tool. Use Maven/Gradle, etc, and any modern IDE will be able to create a project from its config file. The IDE would derive local configuration files which should not be sent back to shared repositories
This way, all developers are free to use whatever IDE (and whatever version) without causing interference, and CI tools will work off build tools' configuration as well.
I want my program to be usable by systems which do not have a JRE preinstalled.
What I'm a little bit struggling with right now is how can I tell Maven to use an embedded JRE and not the system JRE? Right now to build my application I'm using the maven-assembly-plugin along with the maven-nativedependencies-plugin to resolve native dependencies and the maven-jar-plugin.
My understanding in theory is somewhat of the following:
Copy(?) JRE into my project folder (e.g. a folder with java8)
Zip everything up (Somehow included in my build process)
Tell Maven to use the included JRE
User can unpack and does not need a preinstalled JRE
I assume that I somehow need to tell maven/my application to unpack that shipped JRE and use it? I already read about the Java 9 Deployment guide (I'm using Java8 though) and jlink'ed images, however all of it seems a little bit tricky and I'm not build process expert.
Could anyone share their experiences / thoughts on that topic?
There are few ways to build an executable image:
If you are on Java 9 you can use jlink to build an executable runtime image.
Use launch4j tool to include JRE e.g. as shown in this answer.
Include JRE as a Maven dependency and repackage with assembly plugin. Do note that this dependency is quite outdated.
<dependency>
<groupId>com.oracle.java</groupId>
<artifactId>jre</artifactId>
<version>1.8.0_131</version>
</dependency>
I am putting together my first Java package for distribution to users, and am running into some difficulties. I have jar packages that I've built that users can't run; the error messages vary, but are all "version" something or another. I suspect I'm selecting the wrong build paths, and I'm not quite sure where to start troubleshooting because I don't clearly understand the differences between the Java executable (javaw.exe), the JDK and the JRE; I have some questions that I'd like answered which will help in that understanding. I'm used to the way that C# executables compile in VS; wrapping my head around how executable jar files come together is still a little mysterious to me.
Although I've done a few google searches, most of what I'm finding is how to build a jar file, but not how to manipulate/use/select the Java, JRE and JDK versions appropriately to ensure compatibility. I do understand that the JRE includes the virtual machine that allows Java bytecode to run anywhere, and that the JDK includes development tools...but as to figuring out which version I AM running, vs which version is used when building jar files and which version SHOULD be used...I am completely lost.
I'm using Eclipse Indigo under 64-bit Win7. My build path includes the following:
JRE System Library: C:\Program Files\java\jre7\*
External paths: C:\<MyDocuments>\java\lib\commons-io-2.4*
I also have, installed on my machine, the following paths which are NOT included in the build:
C:\Program Files (x86)\java\jre7\
C:\Program Files (x86)\java\jre1.5.0_22\
C:\Program Files (x86)\java\jdk1.7.0_21\
The users that will be running this executable file are only supported (by corporate IT) up to JRE5. I suspect that my building this pointing it jre7 is one of the things that's messing with me.
My first stupid question is whether there's a difference between "Java" and the "JRE" when it comes to version numbers. For instance, when I read about JavaSE7 or JavaEE7, are they talking about the JRE version for the standard or enterprise editions? Are the development kits and runtime environments just components to JavaSE/EE? Or are they separate and distinct products?
Then, my understanding is that I should build this jar using the lowest-common-denominator JRE expected from my users. In this particular case, because the corporate standard is JRE5, I should build this pointing to JRE5 instead of JRE7. Is that a correct assumption?
Does it matter if I build using the 64bit or 32bit version? Some older machines may still be 32bit running JRE5, so I need to make sure I'm backwards compatible.
The Program Files (x86) naming conventions confuse me. JRE7 installed as \jre7. However, JRE5 installed as \jre1.5.0_22, and I also have jdk1.7.0_21, which, based on the JRE name, I assume to be the Java7 Development Kit. Do I need to install the Java5 Development Kit to properly build this program? And am I properly interpreting the versions from the filenames? that 1.5 represents Java5 and 1.7 represents Java7?
Then, my last question I know there's an Eclipse option to copy the external libraries to the project. I assume that if I do this, this will be included with the jar so the users do NOT need to have the Apache Commons jars on their local machines in order for this to run properly. Does the manifest include any confirmations that these files were included? I've been unable to find any references...so I'm trying to verify if I'm even pulling the Commons libraries over and where to look to get that confirmation.
This is just speculation, but I think you may have to re-write the program with the java5 jdk, because some of the APIs/libraries used in java7's jdk may not be recognized by the java5 jre. (Just like it wouldn't be possible to play PS4 games on a PS2... without any serious modding)
If you write the program in Eclipse, you can just select what library you want to use as you create the Java project. At the "Create a Java Project" screen, you can select the "Use an execution environment JRE:" or "Use a project specific JRE" or "Use default JRE" option. (I have jdk6 and jdk7 installed on my computer so I'm able to select those two options; which is why you may have install the jdk5 in order to create a java 5 project.)
You are properly interpreting the filenames. jre1.5.0_22 is java 5 update 22.
There is a way to specify which JRE is used to run the jar file.
cmd prompt >
"C:\Program Files (x86)\java\jre1.5.0_22\bin\javaw.exe" -jar "filepath_filename.jar"
Drop the "w" from the javaw.exe, and you'll be able to see any console and/or stack trace output.
What's the best way to package Java software for running on Windows? Is there a standard for writing .BAT files which can discover the latest installed JRE on the machine? Are there any Maven plugins for this? What's the deal with executable Jar files?
I would without any doubt recommand you to use Java Web Start, as it allows you easy control over version used (and by far the easier to use update mechanism available nowadays).
Depends on what you need.
We've found that using the One-JAR + JSmooth gives a very good user experience as it allows us to distribute a single EXE-file which can be put anywhere on the users system, as opposed to having installation binaries, which need to be installed and uninstalled etc. etc. etc. JSMooth checks for the existance of the appropriate Java runtime, and redirects to the official download site if none is found.
The reason for One-jar is that you generally need to use library jars which is best to have separately but JSmooth only allows for a single jar file.
Also the One-Jar SDK and JSmooth is scriptable without being tied to Windows, so we can build new versions on our Hudson engine running on Linux.
In the past I've used a java installer package like launchForJ. However, a lot of these packages use Java so you may need to a batch or simple executable written in native windows code that does a quick check to see if Java is already installed then run the installer.
Since Java uses system variables during install you should be able to check if the version (or higher) that you require exists in this way.
The standard way would be to use Java Web Start.
Using Java Web Start technology, standalone Java software applications can be deployed with a single click over the network. Java Web Start ensures the most current version of the application will be deployed, as well as the correct version of the Java Runtime Environment (JRE)
Maven has a Webstart Maven Plugin to help building application bundles that can be deployed via Web Start.
An alternative solution would be to use a cross-platform installer generator to generate, well, an installer. I personally like IzPack (I think that JSmooth is very similar but I have more experience with IzPack) and, if you are specifically targeting the Windows platform, you could use IzPack to Build [a] Native Windows Installers with IzPack Native Launcher:
A problem still arise with IzPack when
the target system does not have a JRE
installed. The user needs to first
install it and then run the IzPack
installer. This is not a problem with
Linux or BSD users since they are
generally skilled and they know how to
do that by hand or with a packaging
system (RPM, DEB, ebuilds, ports,
...). Similarly, a Mac OS X user will
not have much problems since it is
available with the operating system.
However the situation is more
complicated on the Windows platform as
a JRE must be installed. Worse,
several instances can be installed in
a sometimes messy situation.
The IzPack Native Launcher tries to
solve this problem. It is a C++ native
application that is available under
the very permissive MIT License and
that uses wxWidgets for the GUI. It is
thus cross-platform (for the
historians: it was first developed on
a FreeBSD box), but most people will
need it on Windows. It uses a simple
configuration file and will first
check for a JRE. If none can be found,
it will pop-up a dialog to let the
user choose between the following
options:
manually specify a JRE location
download one from the Internet
install one that is provided by the packager (if available).
IzPack also offers a Maven Plugin. Worth the check.