When I run my Java application on a Solaris machine, I'm having issues with a shared library since it is in 32-bit format. How do I make my application run as in 32-bit format so it would be consistent with the shared library? I compile my application in Windows by the way, and I believe it has nothing to do with the bytecodes.
Perhaps the "-d32" flag can help?
http://download.oracle.com/javase/1.5.0/docs/tooldocs/solaris/java.html
Related
I am not able to understand that after module system is introduced in our java language. Is java9 and above still platform independent or not ? I am asking this question because I have read that now every application will have its own jre inside it. So, how will this single jre run on all OS, like windows, Linux, or Mac OS.
You are conflating two different changes recently made to the Java platform:
Retiring of Java Web Start & Applet technologies
Modularization
Retiring desktop-technologies
Recently Oracle announced the phasing out of the Java Web Start technologies, in addition to the already-deprecated Applet technology. See item JDK-8184998 in Java 9 Release Notes:
Java Deployment Technologies are deprecated and will be removed in a future release
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.
End-users will no longer be encouraged to install a JDK or JRE on their computer.
For more details, see the eight-page 2018-03 white paper from Oracle, Java Client Roadmap Update.
So then, how are developers of Swing or JavaFX apps to deliver their software to the end-user?
Oracle suggests packaging up your app along with a JVM & JRE for delivery as a single launch-ready applications on that appears on the client to be just another app alongside the native apps. Such “double-clickable” app-packaging has been commonly done on the Mac since the beginning of Java. But what was once an obscure art on other host environments (Linux, BSD, Windows, etc.) will now be the norm, as it is on macOS.
In yesteryear, bundling a Java runtime with your app required jumping over some licensing hurdles. The legalities have eased with arrival of the open-source OpenJDK project, and possibly with other implementations†.
You will need to prepare different releases of your app for each hosting environment. While your Java code runs independently of the host OS, the JVM is built of native code to interact with one specific kind of host. So you will need to build a Linux release with a Linux JVM, a macOS release with a macOS JVM, and so on. While that may seem like a downer, the upside is that you no longer need to worry about users having the wrong JVM version installed, or no JVM at all. Now the JVM’s presence and version are under your control. Your end-users and customers will no longer need to be aware that your app is Java-based.
Modularization
That need for app-packaging has nothing to do with the modularization of Java. As I said, it has been done for decades on the Mac.
What modularization brings to the party is that the JVM/JRE you bundle into your delivered app can be customized to contain only the Java Modules actually utilized by your particular app. This results in a smaller size, so your finished app is smaller, downloads are faster, less storage is used, and your app may load faster.
The open-source jlink “Java Linker” tool helps with the packaging work, so you can assemble and optimize a set of modules and their dependencies (only the ones actually called by your app) into a custom run-time image. This modular run-time image format is defined in JEP 220.
† On a related note, you may want to read the white paper Java Is Still Free to understand how and where to obtain a Java implementation for your app, and what support may or may not be offered in either free-of-cost or paid releases.
By the way, you may find helpful this Answer on a related Question, with a flowchart of choosing various sources of a Java implementation.
Is java9 and above still platform independent or not ?
Yes. It's as platform independent as it ever was. The module system has nothing to do with platform independence.
now every application will have its own jre inside it.
It doesn't have to, but it's more and more recommended as time goes on since fewer people have Java installed separately on their systems. This used to be a given, but that number has been declining for the last decade or so, and now (outside of Java developers) pretty much no-one has a standalone JRE installed.
how will this single jre run on all OS
It won't. You will bundle a separate JRE for each platform you want to distribute for. But JRE's for all platforms are still freely available, and the same Java code will still run on a JRE for any platform.
The module system doesn't influence the OS independency of java in general. Java applications that make use of the module system need to be run in a JRE. This can be either an OS specific pre-installed JRE as usual or a tailored runtime image (application embedded JRE) created with JLink.
The module systems main purpose is to provide you a managed way to split your application into different logical modules. E.g. into different .jar files that can be loaded at runtime - no matter on which operating system.
In summary, you have the following options:
Make sure that your client has the right JRE pre-installed. This could be dangerous, because (normally) you are not in control of his updating behavior.
Ship your application together with an official JRE.
Tailor your own, application and OS specific runtime image using JLink. Ship it bundled with your application.
But, suppose I do not know what OS my client would be running so how
the server will decide what image he should give to him. i.e., a Mac
Image, a Linux Image or a Windows exe.
You have to know the target OS and deliver the right runtime image.
While Java 9 makes it easier to ship a JRE which is more compact and specific to the needs of an individual application, you are not required to do so. If you were already planning to ship a JRE with your application it can be smaller with Java 9 than earlier versions.
It doesn't mean you have to ship a JRE, an application which wasn't shipped with a JRE is unlikely to start shipping with one now, and in fact Java 11 only ships as a JDK.
From this link on Java 9 features;
JLink allows you to create custom runtime images that only consist of your application modules and those JRE modules that your application requires. The result is likely a smaller runtime image, which uses fewer resources than a default JRE.
When I am trying to run one of my Java application (which is deployed in IBM Websphere App server), I am getting the below error,
java.lang.UnsatisfiedLinkError: PATH/file.so (EDC5253S An AMODE64
application is attempting to load an AMODE31 DLL load module.
(errno2=some_address)) at
java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1344)
Did anyone face the same issue of AMODE64 ?
Or could someone provide info on how to compile code to AMODE64.
Any reference in this would also be of great help.
Thanks in advance.
On z/OS, you can't have a mixed single-address application that has some parts compiled 31-bit and some parts compiled 64-bit, if you are using Language Environment. All modern high level languages -do- use Language Environment (e.g. C, C++, Java, COBOL, PL/I), and so this is what is causing your problem.
Depending on the version of Java you are using, you can either switch to a 31-bit JVM or (preferably) recompile and relink your C DLLs as 64-bit.
You asked for info on how to compile code in 64-bt mode, but typically, as the end-user, you would not be the one to do that, the provider of the native library/dll would do that because you need the source code. You replaced the file name of the library in the error message above with PATH/file.so, so I can't provide you any guidance on who the provider of that library might be. Using the name of the library, search for for the provider and then ask them for a version of the library compiled in 64-bit mode.
On the outside chance you own the code for the library, see this IBM KnowledgeCenter topic for information on how to compile and bind code in 64-bit mode.
When installing Minecraft, it installs a local installation of Java. When running Minecraft, it uses that installation. I see the advantages about updating and multiple Java versions, but it does this regardless of any actual Java installations on my PC. My Java version is always up to date.
I usually have a bunch of Java programs open and always running in background. How does starting a VM from a separate installation affect performance? What are pros and cons of such an installation method? (Although I know most of the pros from Mojang). What if many other programs did this? (Let's say Eclipse for each installation)
How does starting a VM from a separate installation affect performance?
In general, it does not. Java applications (Minecraft, Open Office, LibreOffice, Eclipse, etc.) launched from the desktop run in distinct processes by virtue that each Java Virtual Machine (JVM) executing such applications are separate processes. However, it is also possible to run multiple applications in the same JVM; although it is unlikely in a normal desktop environment.
Without additional configurations, a Java application will run on a JVM from your default JRE or JDK installation. In the case of Minecraft, it will run in the JVM from the JRE installed with the new launcher, unless specifically changed in Launch Options using Advanced Settings. Eclipse will run in the default JVM unless configured differently in eclipse.ini.
What are the pros and cons of such an installation method?
In regards to Minecraft, the upside of a separate JRE installation are: 1) it ensures that a suitable JRE is available to run Minecraft; 2) eliminates potential problems dues to older or newer JRE versions; it is a game after all; and, 3) a different version can be installed without requiring changes to the user’s default JRE/JDK. There is no downside for Minecraft.
In regards to other use cases, the pros and cons can be as varied as the number of JREs installed. Case in point, we use current versions of Java 1.6, 1.7, 1.8, and even 1.9 for continuous integration and testing of various libraries and applications. The upside is that we can easily test a variety of environments. The downside is that it can become a configuration nightmare if one is not careful. For example, packaging a Java app under 1.8 and running its integration tests under 1.7. Fortunately, we keep an ample supply of aspirin around.
http://www.oracle.com/technetwork/java/javase/downloads/jdk-7u3-download-1501626.html
We know that java is a Platform Independent Language then why does this site provide JDKs for all OSes like Linux, Windows, Solaris?
Then why do we tell java is Platform Independent?
it is like this:
your application
---------------------
JAVA on OS1
---------------------
OS1
---------------------
hardware
---------------------
if you write your application on top of Java, then you can just move your java
application, as is, without changing it, or even compile it, to new OS, because
your program is written on one platform, which is Java, not the native OS.
So, you need to download specific Java for your OS. But from application point of view, it is the same API. Java makes your application platform independent since it hides the OS from your application. But Java itself, it has to be compiled and build for each specific OS. But the application do not care about that. The application sees the same API. That is the whole point.
Because there you download the Installer for the Java Virtual Machine. This is the environment where your Java Application is running in.
The reason why Java is OS independent, is because its running in this JVM.
The JVM's job is to hide the differences between platforms and to provide the same execution environment to application code regardless of platform.
The JVM is written in C++, and is compiled to a native binary, just like any other C++ application. (You wouldn't expect a .exe file to run on Linux, after all).
So the JVM is platform-specific, but the environment it provides is not.
To explain you in simple terms, you no need to compile your java source code when you move your code from one OS to another, but to run your compiled java code you need to have OS specific Java run time machine. Thats why you have different JDK for different OS.
To add to others answers, Java is qualified Platform independent because the code you write is supposed to works on every platform. That's not totally true in fact. The Java code is always compiled in bytecode in the same way, but the JVM interprets this common bytecode in different way in function of the OS, there is one JVM per OS. OS that don't have a JVM implementation to use bytecode can't support Java.
Can 32-bit and 64-bit Java be simultaneously installed on Vista x64?
Yes, and in fact, this is the only way to get Java Webstart, as there is no 64-bit version.
Edit: Supposedly a 64-bit Java WebStart will be available in Java 6u12.
Considering that when you update Java, it never removes the old version of Java, you should be able to run 32 and 64 bit java at the same time without a problem.