I have a program that I want to run as an exe on a clients computer. After I made my program in Java I used Jsmooth to create the exe. The program runs perfectly fine from my own local computer, but when I try running the same program on another computer the program prompts me to install Java. After installing Java, the program STILL wants me to install Java. I thought it might be different versions of Java, but I compiled the Jar with the most LTS of Java, and my JRE was on the most recent version. What should I do?
JVMs are quite large. Out of the box, JSmooth therefore doesn't include one. I think you can ask it (I'm recalling exe4j perhaps, a different tool that does the same thing as jsmooth), by stating which path contains one relative to the executable. You cannot fold it straight into the exe, though. It'll then be an installation process where you end up with:
C:\Program Files\AnthonysAwesomeApp\Anthony.exe
C:\Program Files\AnthonysAwesomeApp\jre\lib\rt.jar
C:\Program Files\AnthonysAwesomeApp\jre\bin\java.exe
... and the other 5000 files of a JRE installation
Where 'Anthony.exe' is made by JSmooth, and you told JSmooth that it should use the JRE found in location ".\jre".
That should probably still work.
The more general problem is that the entire deployment model is more or less obsolete; JREs do not exist anymore, at least, oracle/team openjdk has ceased producing them and has ceased mentioning the very concept, but some third party deployers such as Azul still produce them. Java1.8 is the last version that can truly be said to have had the concept of a JRE.
A JDK is a superset of a JRE (It has everything a JRE has, and more), and JDKs still exist, so you should just be able to ship an entire JDK.
The new model is jlink, modules, and treeshaking, and it doesn't feel like any of the exe maker projects such as JSmooth have been updated for it. In general, java is used a ton on servers, but java on the desktop is not observed that much. If you want to delve into those - you have a lot of reading to do, and the experience is not as smooth (heh) as JSmooth.
Related
A while back I made a switch from C# to Kotlin. Initially I was using Windows 10, but moving to Kotlin highlighted some of the limitations in Windows; notably long Java class paths, and the Windows 280 character limit.
I know there are workarounds to get shorter class paths, like rolling them up into a JAR file, but for the project I was working on (building CorDapps with Corda), none of the workarounds...worked. This was due to some internal code in Corda, which loaded JAR files from the class path using reflection, however the code didn't recursively check those JAR files for class paths.
I eventually switched to Ubuntu and then MacOS and these problems were no more, since neither OS suffers from such limits. However, Windows now has WSL/WSL2 so I can install Ubuntu as a subsystem in Windows 10. That got me thinking...
Is it possible to run Windows applications in the context of a linux system on WSL?
To elaborate on my question, I'd like to be able to run IntelliJ IDEA on Windows as my IDE for Kotlin, but have it consume the JDK installed under a WSL Ubuntu instance, and also execute Kotlin applications under the same instance. Is this at all possible?
I want to write my first JavaFX 8 application (doing my first experiments with e(fx)clipse, etc.) and have a few concerns about platform independence.
JavaFX 8 is a part of the Oracle JRE, which is the most used JRE on Windows. Therefore, I do not really bother here, since JavaFX will be installed on nearly every Windows machine running Java 8.
But on Ubuntu and other *nix, OpenJDK is often used as Java distribution. Since openjfx is separated from open-jdk-8-*, many will not have JavaFX installed by default.
I thought of:
Writing an install script that calls sudo apt-get install openjfx (which I would like to avoid, since I would like the executable .jar to be runable on its own, without script)
Shipping a JavaFX distribution (i.e., its .jars) with my applications (but I read that this should not be done)
Both ideas do not seem very promising...
Since I hope that there are some JavaFX pros out there, i hope that someone can help me with "What are the best possibilities to ensure that my JavaFX application will run fine, both on Windows and Ubuntu?" What are state-of-the-art techniques on how to tackle this problem?
This page (http://www.sj-vs.net/creating-a-simple-debian-deb-package-based-on-a-directory-structure/) describes very well how to build a simple .deb package based on any directory structure (e.g., with precompiled stuff).
You can than add your dependencies, e.g., to javafx packages, to the Depends section of the control file. (https://www.debian.org/doc/debian-policy/ch-relationships.html). This forces any installer like apt or dpkg to install javafx together with your package and makes them fail if this package is not available. You can also add a postinst script that will be executed after the installation in which you can set classpaths etc if necessary.
I have a finished program that I created a JAR executable from (I created this in eclipse), and I need to download this executable onto computers different from the one that I wrote the program on.
However, I am getting the problem that when I try and download the executable onto the computers, I get the window that pops up that says that "Windows can't open this file" and it then gives me a list of programs that I can open the file with, none of which I can use. I do not need to do this on the computer on which I wrote the program. When I double-click the executable on that computer, the program starts without any trouble.
In order to run Java programs, you have to install the Java Runtime Environment (JRE). The Java Development Kit (JDK) is not needed. You can download the latest version (JRE) here.
If you want to learn more about JVM, JRE and JDK, you can read the answer to this question.
This is cause you need install Java in the remote machines including the JDK, then also you need to make java available through console installing Ant wherever it applies.
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.
I have a Java desktop app that runs on both the MacOS and Windows.
I understand that I cannot have one distribution for each, which is not a requirement.
I need to know what tool or tools is best to use when delivering a Java app for each.
The tool should install prerequisites (in this case, Java and some JARs) and look native to the respective operating system.
As for OS X's java situation:
Currently, JDK 6 is bundled in the OS.
Presumably, the next version of the OS will still include JDK 6.
It's publicly stated that the OS will have a well-defined place to install multiple copies of Java runtimes, a public interface choosing which of the Java version, etc. See here.
Apple started contributing back its own code to the open JDK community, so JDK 7 should be available as a separate download, see here.
So, you're not expected to include Java runtime itself into your Java app even then. You're not supposed to install Java in a ramdom place on a filesystem, for example.
As for how you should deploy java apps on OS X:
Double-clicking jar just works.
However, that won't be pretty, because you would only have a generic Java icon in the Dock. You don't want that.
You should use Jar Bundler to make it an honest OS X app. On Mac, it comes with XCode. See the documentation here. You can do that on a non-Mac machine too, using this open-source project.
On Windows, I would recommend either JSmooth or WinRun4J.
On a Mac, the situation is a bit more complex (as the comments point out), but just distributing an executable JAR is probably good enough for now.