Develop Reference

Use Oshi Java library to get hardware and operating system information for Windows PE

I am unable to run my Java app on Windows PE. Basically, my application gets data of Hhardware plus operating system information. I am using Oshi Java library for this purpose, but Oshi uses the JNA library, which is continuously crashing.
Note: My application runs fine on any other OS, but is unable to run on Windows PE. Code that I am using is as follows:
HardwareAbstractionLayer hal = si.getHardware();
OperatingSystem os = si.getOperatingSystem();
hal.getComputerSystem();
Any help will be appreciated.

I'm the author/primary maintainer of OSHI and a committer at JNA. JNA's Platform class does not distinguish between Windows and Windows PE. OSHI's code relies on the standard Windows Version Helper API to determine OS support for DLL functions. However, Windows PE is not indicated as a separate version.
In fact, Windows PE is not designed to be a standalone operating system. Its purpose (and authorized use) is very limited. From the Windows PE docs (emphasis mine):
Windows PE is not a general-purpose operating system. It may not be used for any purpose other than deployment and recovery.
Further,
To prevent its use as a production operating system, Windows PE automatically stops running the shell and restarts after 72 hours of continuous use.
Essentially, some features available in the Windows 10 API are not present in PE. From these Microsoft docs:
API Compatibility reference
Windows PE is a lightweight, bootstrap operating system based on a subset of components from the Windows operating system. It is designed to host deployment and recovery apps. As such, it contains many Windows binaries that are needed to host the APIs that are most important to these classes of app. Due to size and other design constraints, not all Windows binaries are present in Windows PE, and therefore not all Windows APIs are present or usable.
This is a feature of WinPE, not a bug.
OSHI is designed as a cross-platform library to provide information. It is not a "deployment and recovery" app. OSHI links (via JNA) to standard Windows DLLs such as Kernel32, while WinPE has its own set of MinCore DLLs.
Windows PE is intended to be very lightweight, and very specific to the Windows operating system family, and very specific to deployment and recovery tasks.
You should probably be using command-line or Powershell tools for operating system and hardware information necessary for "deployment and recovery", the only authorized uses of WinPE. OSHI's ExecutingCommand class is a nice utility class for processing command-line responses as Java Strings, that you are welcome to copy and use in your own Java project, without the overhead of the entire OSHI/JNA dependencies.
If you can specify specific points where "JNA is crashing" I can help you identify ways to work around any exceptions that may be thrown. Alternately, you can submit an issue/feature request at the OSHI project identifying these failures, to make it more robust to the PE environment, although "more robust" will likely be in the form of "avoiding crashes" rather than in providing information that is not available from the Windows API in WinPE. Finally, you may choose to bring up your issues for an extended discussion on the JNA mailing list.

From what I can tell, Oshi does not support Windows PE:
The Oshi FAQ does not mention Windows PE as support. For Windows, it lists:
Windows 7 and higher. (Nearly all features work on Vista and most work on Windows XP.)
I found no issues in the Oshi issue tracker that mention Windows PE
When I Googled for "oshi windows pe", nothing relevant showed up.
There is a property file in the codebase that maps Windows OS ids to names. It does not mention any Windows PE version numbers.
The JNA library documentation makes no mention of Windows PE.
None of these facts is conclusive, but taken together they paint a clear picture.
This is not to say that Oshi could not support Windows PE. But to make some progress you would need to provide more details; e.g. tell us how it is crashing.

How is a Java program bound to the JDK?

I made a java program that I want to upload on a website. I want it to be available to download for everybody. I read many things about Oracle OpenJDK and OcacleJDK but I do not really know how this is connected to my program. And if I made my program with the Oracle JDK, how can I change it to work with the Oracle Open JDK?
Edit:
Sorry, I do not really know that much about JDK's and so on... That I understand this correct, the JDK is not bound to the program. The end user needs to have the JDK installed on the computer. Because I am not sure, if I need to buy a java license.

And if I made my program with the Oracle JDK, how can I change it to work with the Oracle Open JDK?
No need to change it.
Understand that the Java platform is defined by a set of specifications. Any implementation that complies with those specs can run any Java-based app. To ensure compatibility, an implementation may be subjected to test suites published by Oracle (TCK) or by Adoptium (AQA).
If you write a Java app using an implementation of Java 11, for example, then that app can run on any other implementation of Java 11. And most likely, that app will run an any implementation of future versions of Java.
Oracle JDK is a product from Oracle that implements the Java specifications. This product is commercial, requiring a fee for use in production, with support available. Oracle also releases an unsupported free-of-cost product that is an implementation of Java that oddly does not exactly have a name, found here.
Both of those products are built from the open-source project OpenJDK. Several other vendors also release implementations of Java based on this source code. You can build your app using any of these, and run your app using any of these.
Your use of the phrase “Oracle OpenJDK” is not accurate. While Oracle founded the project, and provided the bulk of the source code, the project is also backed by IBM, Apple, and others contributing important parts of the code base.
Here is a flowchart to help you in selecting a vendor. The products found inside the blue barrel are built entirely or nearly entirely from the source code provided by the OpenJDK project. The two products outside the barrel use parts of OpenJDK, but have significant portions built from other source code to provide their special features.
I want it to be available to download for everybody.
Your app needs an implementation of Java to run.
Your user can have an implementation of Java installed locally on their computer. Then you probably should build a JAR file containing your app for distribution.
You can include an implementation of Java bundled inside of your app. See the jlink tool. You can then make a complete self-contained "double-clickable" app that runs like any other app. Search Stack Overflow to learn more.
Because I am not sure, if I need to buy a java license.
Some of the Java implementations require a fee in some circumstances, and that also buys you support in all the cases I know of.
Some of the Java implementations are free-of-cost. Of course you do not get the benefits of paid support, unless you engage a support service company separately.
The key concept to remember is that the OpenJDK project provides only source-code but not binaries/installers. For binaries/installers, choose a vendor following the flowchart I posted above. For newbies wanting a free-of-cost implementation of Java, I suggest Adoptium (formerly known as AdoptOpenJDK), as this is a cooperative effort involving nearly all of the other vendors.
That I understand this correct, the JDK is not bound to the program.
True, your Java-based app is never bound to a JDK (Java implementation). After deployment, the Java implementation could be replaced by another while leaving your Java app untouched, no need to recompile. A JVM launches first, and then uses a Java class loader to load your app’s classes from your JAR file. A JVM is actually the app running on top of the host OS. On top of the JVM is your app running. So: host OS > JVM > your app classes.
This means your Java classes are not bound to the Java implementation, not in the sense of a linker in conventional software.
Caveat: What I discussed above is generally the case. GraalVM is very special in that it enables ahead-of-time compilation, for a different runtime situation. But that is cutting-edge technology, and not commonly used. Project Leyden is a possible similar effort.
I suggest reading the white paper Java Is Still Free.

IBM Java on Linux

What would be the use case of installing IBM Java on a Linux machine? We tested our application on Linux using Oracle Java but one of ours customers installed it on a machine which only has IBM Java and the application gives errors for some missing classes and jars.
I'm assuming that the IBM java would probably have been installed because some IBM products mandate use of IBM java but this should not be a deterrent to install Oracle Java in addition to IBM java. Is my understanding correct?
Please share your thoughts.

I believe IBM doesn't ship its Java as an independent package -- so, yes, if IBM Java is present it's because an IBM product was installed that came with the IBM Java environment. (IBM supports Java on some platforms Sun doesn't; I believe the reverse is also true -- I don't think IBM bothers producing its own Java for Solaris, for obvious reasons.)
There's no problem having multiple Java's installed, each in its own directory. In some Linuxes, the alternatives mechanism can be used to select which Java is the default when you type java at the command line; in others, you would have to manually change the path or adjust symbolic links appropriately (the later is what alternatives does semi-automagically).
If you're working in Eclipse, its configuration menus will let you pick which installed copy of Java it will use to execute/debug applications, either on a workspace-default level or per launch.
(I have something like eight JREs/JDKs installed on my Red Hat machine -- a mix between Sun and IBM. Some are for my own use, for testing code for compatibility or trying to reproduce customer bug reports. Some were installed because a particular tool shipped with its own JRE rather than risk possible incompatabilities with another version; that's the only reason I still have a Java 1.5 JRE installed, for example. It's an annoyance, and it slightly belies Java's original promise of "write once, run everywhere", but it does work.)

There is nothing stopping you from having multiple installs of Java on a single linux system. However when running your application, you need to make sure that you are using the oracle version of java and not the IBM version.
which java
and
java --version
can help you find which version of java you are using.
Java is usually installed under /usr/lib/jvm or something similar to that. Checking there can help you find which java installs you have available.

You are correct that IBM java comes with IBM product installation - IBM does not ship their Java as standalone product. However, they provide provision to download their JRE for Linux from developerworks.
Ideally product running on Oracle JRE should run on IBM JRE and vice versa. However, to ensure that each product on the system runs on the JRE they are tested on, set java home properly for respective products. In case both the products use the same system-wide environment variable (which should not be the case anyway) - you may need to tweak your product settings so it does not break any IBM product running on the system.
As long as you properly isolate multiple JREs as used by different products through product/system property settings, there should not be any issue.

Using Multiple JDKs on OSX Mavericks

On platforms like Windows and Linux installation of additional JDKs for development purposes is fairly trivial: download a compressed file, uncompress it in some out-of-the-way directory, point JAVA_HOME at that location, and invoke the files in its bin directory.
I'm trying to do the logical equivalent for OS X and am seeking the advice of Java gurus who might have a preferred way to do this on that doesn't tamper with the actual OS X environment. My end objective is to merely have several JDKs, historic and experimental, to choose from when using IntelliJ.
To be clear, I'm not trying to update the Java used by OS X, nor change the JRE that gets invoked by the browser. Each JDK that I've grabbed from the vendor seems to want to replace the OS's version, which is the exact opposite of what I'd like.
From past experience, OS X (while Unix under the hood) is actually a collection of cooperating applications that have been carefully selected for dependencies and version feature compatibility; upgrading a language or service can often have disastrous or unexpected consequences, thus sandboxing alternate versions seems the better approach, plus it makes projects immune from OS upgrades.
Any recommendations?

If you become a registered Apple Developer you will have access download different versions of the Java for OS X Developer Package which, I believe, can be installed concurrently.
Please note, you DO NOT have to join the Mac Developer Program (which costs $99). You only need to register as a developer, which is free.

Is Java cross platform?

I want to develop a cross platform application.
Is Java cross platform? I mean, can I develop a Java application in Windows and use it in Mac OS X and Linux?
If yes, how?
I find application written in Java, has two setup file one for Windows and other for Mac. This confuses me.
Any illustration or suggestion will be highly appreciated.

Is Java a cross platform?
Java is cross platform in the sense that a compiled Java program runs on all platforms for which there exists a JVM. (This holds for all major operating systems, including Windows, Mac OS and Linux.)
I mean I can develop Java application in windows and use it in mac and Linux?
Yes, this is possible.
This (and the security aspect) is one of the main advantages of running the programs in a virtual machine.
If yes how?
Write your application in Java (In .java files)
Compile your application using Eclipse or javac (into .class files)
(Optionally) Bundle your .class files in an executable (.jar file)
The very same .jar file can be distributed and executed on Windows systems, Mac systems, etc.
I find application written in Java, has two setup file one for windows and other for mac. This confuses me.
This is because some applications rely on platform-specific features. They are then bundled with different platform-specific libraries.
Unless you're developing an application that itself relies on platform-specific features, (such as for instance low-level system calls), you should be able to do just fine with ordinary Java.
Important comment by #Peter Lawrey:
It can be while the application is platform independent, the setup program is not. e.g. IntelliJ has three platform specific installers which are not written in Java, but have a zip which you can just unzip on any platform and it will work.

You can run Java applications on every device that has a JVM. If it does not, you're out of luck.
The comment from Oded is important. C and C++ have compilers on lots of devices.
Java byte code won't need to be recompiled when you switch platforms.
C and C++ will require that the developer recompile the application before distributing it to the target system, but once that's done clients will be able to run without an issue.
The problem of platform-specific customizations and settings has to be dealt with no matter which language you choose. The more your application depends on platform-specific features, the less portable it will be.
UPDATE:
Let's revisit the original words in the question:
I want to develop a cross platform application.
Here's the objective - a direct quote. No details about web, mobile, or desktop app.
Is Java cross platform? I mean, can I
develop a Java application in Windows
and use it in Mac OS X and Linux?
Define "cross platform". Sounds like the bias here is "byte code portability". C/C++ can't do that, but "source code portability" is certainly possible as long as you stick to ANSI C/C++ and refrain from using vendor extensions.
Java's claim to fame from the beginning has always been byte code portability. That's what the JVM gets you. That does not mean your whole application will be portable, because you might not have managed other dependencies well.
If I substitute "C/C++" for "Java in that bloc, then cross platform means something different. I cannot pick up a .exe or .so compiled for one platform and expect to run it on another, but if I create an .exe or .so for each platform and make them available it's certainly possible to make the same source code runnable on multiple platforms.
If yes, how?
If you have packaged your Java app as a JAR, you can put that on any platform you like.
If you have multiple C/C++ .exes for the platforms you're interested in, you can certainly run it when you need to.

There is an important caveat with regard to Java portability. "Business logic" (non-UI stuff) is quite portable, but there are at least a half-dozen different (and incompatible) user interface paradigms for Java, so, eg, Java code written to run on an Android (even ignoring Android's incompatible JVM) won't run on a Nokia phone, and code for either one will not run on a desktop PC.
But there's no other language that does better, to my knowledge.

Yes, Java written and compiled on one OS can run on another OS. There are JVMs available for many modern operating systems.

Java apps are packaged as .jar files. These can run on any operating system that implements the correct Java Runtime Environment for the application, provided the user has installed that JRE (JREs are provided to users for free).
The precise procedure for running the app is different for each operating system.
The Java Development Kit provides libraries that allow system functions (e.g. file operations, user interfaces) to be invoked that ought to work on any OS. However the precise behavior may vary (in a similar way to how a website can look different in different browsers). Also, Java apps may have a 'look and feel' that does not precisely match the look and feel of applications designed specifically for that OS.

It depends what you mean by "cross-platform". Java code can be compiled to byte-code binary class or jar files on any OS supporting the JDK and run on any platform supported the JRE. However, most compiled languages can be compiled on any platform provided the designers has catered for it. Java is more easily portable than, say, C++, but that doesn't mean C++ code won't be able to compile on any platform.
In other words - don't choose your language on this single feature alone. Choosing the best language for your application would be a better way of going about it. Perhaps a scripting language would be best for you. Maybe post another question asking what language to use to solve your specific problem.

I wrote a little game in Java with sound.
I've used standard library (AudioInputStream and Clip classes).
The program works very good with Windows XP, BUT I haven't got the sounds with Windows Seven or Linux Ubuntu.
Java 6 was installed for all those OS, and I've compiled the program with the standard compiler JAVAC.
So Java is not so "cross platform".

JAVA is not really cross-platform because is just a design, some JAVA implementations can be cross-platform but it really depends on the JAVA implementer.
SUN/Oracle makes the JAVA standard implementation for Windows, MAC and Linux and if you build programs with their JDK you should run the programs with their JRE, if you try to run it with other JRE there might be compatibility issues.
This can be seen more in the mobile, some phone makers won't make a full implementation of JAVA because hardware limitations or because they want to control the device's software, they carry the JAVA logo but you must use their own JDK and those programs could not run outside of their JVM implementation.
Another issue with JAVA is that some functionality could be deprecated and what ran in some specific version of the JRE could not run in newer versions or run in a different way.

The big problem is when we are talking about mobile apps. For desktops OS, java can run perfectly, but for mobile devices, developers can, practically, only create for Android. There are tools like Totalcross that helps java developers to create apps to iOS and Android. The focus is maintain the WORA assumption to every platform, even mobile.