I know this is often a common issue but the Java 8 aspect confuses me. I'm aware that since Oracle removed JavaFX from the Java distribution, this issue is usually resolved with VM arguments (--module-path,--add-modules, etc).
However, I'm exporting a .jar file using jre 1.8.0_202 in eclipse. And this works great without any arguments on my windows machine. Sadly when I move this jar to my linux machine, I see the classic "Cloud not find or load main class". For reference, the linux machine is running 1.8.0_342. I would think that this shouldn't be an issue because I'm using older Java versions?
Any insight on why this works on one platform and not the other?
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 have been programming in Java for several months, one of the tools I use is Eclipse, which seems to be able to run standalone from any local Java installation by having the JDK/JRE in a directory next to the main binary.
I have run it from my USB-drive in computers without any Java Runtime/Framework/other... And it has been able to open itself, understand the Java code, compile it, and run it without any problem.
So, the question is How do they do it?. At least in the Windows version (Did not try in the Linux version but I think it might work as well).
See following threads.
https://www.eclipse.org/forums/index.php/t/264351/
How does Eclipse compile classes with only a JRE?
Do I need to install Java SDK if I have eclipse
The eclipse.ini file will point to the local vm location
https://wiki.eclipse.org/Eclipse.ini
Target Environment
Windows 7 (6.1)
Java 1.8.0_121 64bit
I recently created a minimal java environment consisting of just the single file java.exe in a newly created, empty directory and successfully ran a simple HelloWorld.class file simply by copying it to the same directory and typing:
.\java HelloWorld
I found this kind of surprising, and wondered if maybe because the version of java I was using (jre 1.8.0_72) had been installed from an .exe file whether there was something in the Windows registry telling java.exe where to find rt.jar and such.
Running the java control panel, you can certainly see java 1.8.0_72 is in there:
I if I used a java version which was NOT installed (i.e. a standalone java version) would I get a different result?
Well, before trying a stand-alone version I think I'll try a computer having NO java on it at all. Same exact set up as before.
Found part of the answer on my wife's Windows 10 computer (which has no java on it):
Clearly, I should copy java.dll somewhere. Think I'll put it in the same directory as everything else (i.e. the same one as the java.exe), and try that.
Nope. Same as before.
So clearly java is looking in the registry to find its .dll.
I've downloaded jre-8u121-windows-x64.tar.gz. I'm going to try the same experiment with that.
Tried the same experiment with java from the tarball above. Exact same symptom. Cannot find java.dll.
Having done a little reading, I see that Embedded Java SE has a way to create custom deployments of java. There appears to be no official analogous mechanism for Java SE for Windows.
Doing a little more reading, I see that there is a mechanism called the Invocation API which can be used to run java, bypassing java.exe. This might be something to try. Might also be time to start surfing the HOTSPOT code.
More on the Invocation API here: http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/invocation.html
An intriguing note I also ran into during my reading said this:
Private vs. public JRE - Installing the JDK installs a private Java SE Runtime Environment (JRE) and optionally a public copy. The private JRE is required to run the tools included with the JDK. It has no registry settings and is contained entirely in a jre directory (typically at C:\Program Files\jdk1.6.0\jre) whose location is known only to the JDK.
I read this here: http://www.oracle.com/technetwork/java/javase/install-windows-142126.html
You might try this experiment with THAT jre.
Today I also face same problem .and I found the solution for this go-to your JDK bin copy path from there and peast this path to environment variable path and the priority should be first that mean it should be peast in starting of all path.
I implemented a SDK in C++ (API exported in C). This SDK compiles into a DLL for Windows and a .so for Linux. I also implemented a Java wrapper using JNA. This wrapper ships with .so and DLL inside it and I check at runtime which operation system is running and extract it on a folder specified by developer. It works well.
The problem is that one of customers that use Linux (I have just a couple of them on Linux) said that the library was not loading with a undefined symbol error. Here is the error:
java.lang.UnsatisfiedLinkError: /usr/lib/libBXSDK.so: /usr/lib/libBXSDK.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE
Initially I thought this could be related to some standard .so not being present. I then sent him a a very basic C++ executable and asked him to run. It worked. I then sent him a very basic Java application that DOES NOT use the SDK, but only calls System.loadLibrary("BXSDK"). After copying libBXSDK.so to /usr/lib, he ran the basic Java application and the error was the same.
I then decided to check his Java version, and realized he was using Oracle JDK latest version, and I saw that on my test environment that runs CentOS 7 (customer runs RHEL 7) I use OpenJDK. Immediately I installed Oracle JDK on my test environment and I saw the same problem.
So, my question is. What is the difference between Oracle JRE and OpenJDK (JRE), that causes this issue? Am I doing something wrong on my .so that OpenJDK is able to handle but Oracle JRE is not?
Thanks
Did you verify if the folder is the case as mentioned in this post: http://ubuntuforums.org/showthread.php?t=1323888
Fellow (dontexist) member's comment is quite valid in general, the fact that OpenJDK being able to make the calls makes me think if library load itself was unsuccessful.
I figured, this may not entail an answer to the question - "What is the difference between Oracle and Open JDK in loading semantics". Not sure if I can retract this post being an answer, but let others take the opportunity to explain about it.
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.