OSHI: a Java library that reads OS and hardware details through JNA, the FFM API or plain procfs

Three implementations share one API, and the classpath decides which one runs

OSHI offers two native access implementations. The JNA one is oshi-core, which uses Java Native Access, supports JDK 8 and newer, and has the JPMS module name com.github.oshi. The FFM one is oshi-core-ffm, which uses the JDK Foreign Function and Memory API, requires JDK 25 or newer, and has the module name com.github.oshi.ffm. Both implement the shared interfaces in oshi-common, so you can choose at compile time or include both and select at runtime.

A third, pure-Java implementation also lives in oshi-common, under the package oshi.nativefree. It is chosen when neither oshi-core nor oshi-core-ffm is on the classpath. The consequence is that your dependency list is a configuration choice: the same source line can run a different backend depending on which artifacts you shipped, so inspect your final classpath before you debug a missing value.

SystemInfoFactory.create picks the backend, with a fixed table of outcomes

The recommended entry point is a single call, shown here exactly as the project writes it:

// Automatically selects the best available implementation based on your classpath and runtime.
SystemInfoProvider si = SystemInfoFactory.create();

The selection rules are a table. With oshi-core only on JDK 8 or newer, you get JNA. With oshi-core-ffm only on JDK 25 or newer, you get FFM. With both on the classpath, you get FFM on JDK 25 and newer and JNA otherwise. With oshi-common only, you get the native-free mode on Linux and NetBSD.

You can bypass the factory and construct a specific class:

SystemInfoProvider si = new oshi.SystemInfo();            // JNA (oshi-core)
SystemInfoProvider si = new oshi.ffm.SystemInfo();        // FFM (oshi-core-ffm, JDK 25+)
SystemInfoProvider si = new oshi.nativefree.SystemInfo(); // no native access (oshi-common)

The factory is convenient, but a direct constructor makes the backend explicit in your code, which matters when behaviour differs between implementations.

The FFM backend cannot start below JDK 25

The FFM implementation depends on the JDK Foreign Function and Memory API, and the project states it requires JDK 25 or newer. If you add oshi-core-ffm to an application that runs on JDK 21, it does not meet the stated JDK requirement. With both artifacts present, the factory falls back to JNA on older JDKs, which is the safer way to ship one build that runs on several Java versions.

The practical rule is to choose by deployment target. A fleet pinned to JDK 17 uses oshi-core. A new service on JDK 25 can use oshi-core-ffm and avoid JNA altogether. Mixed environments should include both artifacts and let the factory decide; the table above says JNA is used whenever the JDK is older than 25. The cost of including both is a larger dependency set, since transitive dependencies such as JNA are resolved automatically for oshi-core. Do not assume that adding the FFM artifact to an older runtime gives you the newer backend; it gives you the JNA fallback only if oshi-core is also there.

The native-free mode covers only Linux and NetBSD

The third implementation reads only procfs, sysfs, sysctl and other command-line tools. It needs no native access, so it runs without an --enable-native-access flag and without the warning the JDK prints when one is missing. It covers Linux and NetBSD only.

That trade is attractive for a locked-down Linux container where native libraries are awkward, and wrong for anything else. On Windows, macOS, FreeBSD or Solaris the oshi-common-only setup is not available, so you need JNA or FFM. Because the mode reads command-line tools and filesystems, the data it returns comes from what those sources expose, and it needs the tools to be present on the machine. Compare its output with the native backends on your hardware before you rely on it for fields such as sensors or GPU figures.

The feature list is wide, but sensors appear only on some hardware

Supported platforms are Windows, macOS, Linux including Android, and UNIX systems named as AIX, DragonFly BSD, FreeBSD, NetBSD, OpenBSD and Solaris (illumos). The feature list covers firmware and baseboard, OS version and virtualization detection, physical and logical CPUs with NUMA nodes and caches, load and tick counters, processes with command line arguments and thread details, services, login sessions, memory, filesystems, disks, partitions, network interfaces, routing tables and TCP/UDP statistics, battery, USB and Bluetooth devices, displays with EDID, GPU utilization, container limits under cgroup v1 and v2, and printers.

The qualifier is on sensors: temperature, fan speeds and voltage are listed as available on some hardware. A program that logs fan speed will find empty values on machines that do not expose it, so handle missing readings. Breadth across platforms also means a given field may be filled on one system and absent on another.

Windows sensors need an extra dependency whose DLLs are under MPL 2.0, and Android needs a swap

For Windows, the project suggests the optional jLibreHardwareMonitor dependency if you need sensor information, and notes that the binary DLLs in it are licensed under MPL 2.0. OSHI itself is MIT, so adding this dependency brings a second license into your product that your legal review should cover.

On Android, you add the AAR artifact for JNA and exclude OSHI's transitive JAR dependency on JNA. If you see NoClassDefFoundError or NoSuchMethodError, the project points to an entry in FAQ.md about resolving JNA issues. For people who manage JARs by hand, each GitHub release carries an oshi-dist zip containing oshi-common, oshi-core and oshi-core-ffm with their runtime dependencies, but not the oshi-demo examples. The project strongly recommends a dependency manager such as Maven or Gradle instead.

Configuration is read once at startup and is not thread-safe

Some settings live in the oshi.properties file in oshi-common, and they can also be set through the GlobalConfig class or through Java System Properties. The project says to do this at startup, because configuration is not thread-safe and OSHI does not guarantee re-reading the configuration during operation.

So changing a setting from another thread while queries are running is unsupported. Set your values before the first call to SystemInfoFactory.create. After you have a provider, the usual path is to read components through getters, such as a hardware abstraction layer from getHardware, a processor from the HAL, and an operating system object from getOperatingSystem. If you need runtime-adjustable behaviour, wrap OSHI calls in your own code rather than flipping its configuration.

Releases arrive about every ten days, and old JDKs are pinned to 3.x

The recent releases are 7.7.3 on 2026-10-31, 7.7.2 on 2026-10-20 and 7.7.1 on 2026-10-10, and the last push was on 2026-11-02. Snapshot builds of the next version are published to a Sonatype snapshots repository that your build must be configured to use. The legacy section lists oshi-core 3.13.6 for JDK 7 and oshi-core 3.14.0 for JDK 6, which means current OSHI starts at JDK 8.

The repository also contains UPGRADING.md, PERFORMANCE.md, CHANGELOG.md, a benchmark module, a metrics module and a demo module. Read UPGRADING.md before moving between major versions. If you only need to see what OSHI reports on your own machine, the project suggests cloning the repository and running the SystemInfoTest main method that both native implementations provide.

Editorial conclusion

OSHI is the right choice when a Java program needs OS, CPU, memory, disk, network or process facts across Windows, macOS, Linux and several Unix systems without installing extra native libraries. It is the wrong choice if you need guaranteed sensor readings on every machine, or if you plan to run on JDK 7 or older without pinning an ancient release. Before adopting it, pick the implementation that matches your JDK and platform, and check on your target machines that the specific fields you need come back populated.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes