OSHI: cross-platform OS and hardware information for Java without extra native libraries

What OSHI reports and who ends up depending on it

OSHI answers a narrow question: what is this machine, and what is it doing right now? The README lists the surface: computer system and firmware, OS version and build, hypervisor detection, physical and logical CPUs with processor groups, NUMA nodes and caches, per-processor load and tick counters, process uptime and memory, services and login sessions, mounted filesystems, disk drives and partitions, network interfaces and routing, battery state, USB and Bluetooth devices, displays with EDID, GPU utilization and VRAM, temperature and fan sensors on some hardware, cgroup v1 and v2 limits, and printers.

The audience is Java developers building monitoring agents, desktop applications that display system state, licensing or inventory tools, and test harnesses that need to assert something about the host. The pitch that matters is the second sentence of the README: no additional native libraries to install. A JVM application that has to run on a customer's Windows laptop and on a Linux server can call the same getters instead of shelling out to `wmic`, parsing `/proc`, and maintaining a separate code path per platform.

That breadth is also the source of the friction. OSHI does not promise that every getter returns a value everywhere. Sensor data is qualified as available "on some hardware", and the Windows sensor path depends on an optional dependency. Treat the feature list as a map of what the library attempts, not a contract about your particular machine.

JNA, FFM, or native-free: how the implementation is chosen

OSHI splits into modules. `oshi-common` holds the shared API interfaces, `oshi-core` is the JNA implementation, and `oshi-core-ffm` is the implementation built on the JDK Foreign Function and Memory API. The README states that both share the same API interfaces from `oshi-common`, so the choice is made at compile time, or both can be on the classpath and the selection deferred to runtime.

The selection rule is documented as a table. With `oshi-core` only and JDK 8 or later, you get the JNA class `oshi.SystemInfo`. With `oshi-core-ffm` only and JDK 25 or later, you get `oshi.ffm.SystemInfo`. With both present, FFM is chosen on JDK 25 or later and JNA otherwise. With `oshi-common` alone, the pure-Java implementation `oshi.nativefree.SystemInfo` is selected, which the README says reads only procfs, sysfs, `sysctl` and other command-line tools, requires no native access at all, and therefore runs without an `--enable-native-access` flag and without the warning the JDK prints when one is missing. That last point is the concrete reason the native-free path exists: it covers Linux and NetBSD only.

The JPMS module names differ per artifact (`com.github.oshi` for JNA, `com.github.oshi.ffm` for FFM), which matters if you are building a modular application. The API is the same, but the module declaration is not.

Adding OSHI with Maven or Gradle and printing a first report

The README recommends adding `oshi-core` or `oshi-core-ffm` through your dependency manager, because transitive dependencies including `oshi-common` and JNA are resolved automatically. The artifacts are published under the group `com.github.oshi` on Central; the current release is 7.6.0. If you manage JAR files by hand instead, the README points at the `oshi-dist` zip attached to each GitHub release, which contains `oshi-common`, `oshi-core` and `oshi-core-ffm` plus their runtime dependencies, but not the `oshi-demo` examples.

Once the dependency is on the classpath, the README's first step is to create an instance through the factory, which picks the implementation for you:

SystemInfoProvider si = SystemInfoFactory.create();

From there you walk down to a component. The README's example gets the hardware abstraction layer, the processor and the operating system:

HardwareAbstractionLayer hal = si.getHardware();
CentralProcessor cpu = hal.getProcessor();
OperatingSystem os = si.getOperatingSystem();

The README also gives the direct constructors, for when you want to pin the implementation rather than let the factory choose:

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)

To see what OSHI reports about your own machine rather than a single field, the README suggests cloning the repository and running the `SystemInfoTest` main method, noting that both native implementations provide one. That is the fastest way to find out which of the listed features actually return data on your hardware before you write code against them. Configuration lives in `oshi.properties` and can also be set through the `GlobalConfig` class or Java system properties, with the README warning that this should happen at startup because configuration is not thread-safe and OSHI does not guarantee re-reading it during operation.

Where OSHI returns nothing, and when it is the wrong dependency

The honest limitation is coverage asymmetry. The README's own phrasing gives it away: sensors are reported "on some hardware", and Windows sensor information is tied to the optional `jLibreHardwareMonitor` dependency, whose binary DLLs are licensed under MPL 2.0. That is a different licence from OSHI's MIT, and it is a separate artifact you have to add deliberately. If your product needs CPU temperature on arbitrary Windows machines, OSHI is not a complete answer by itself.

The second limitation is the JDK 25 boundary. If you build on JDK 25 or later and put both implementations on the classpath, FFM is selected. The README frames the native-free backend as the way to avoid the `--enable-native-access` flag and the warning the JDK prints when one is missing, but that backend covers Linux and NetBSD only. So the escape hatch from native access is also a narrowing of platform support. On Windows or macOS you take one of the native paths.

The third is configuration timing. Because OSHI does not guarantee re-reading configuration during operation and the configuration is not thread-safe, anything you want to change has to be set before the library is used. A long-running agent that wants to flip a setting at runtime is outside what the README describes.

There is also a structural point worth stating plainly: this is a library, not an agent. It has no daemon, no metrics endpoint and no storage. `oshi-metrics` exists in the repository as a separate module, but the README does not document it, so treat it as something to investigate in the source rather than a documented feature.

OSHI against SIGAR and against writing your own probes

The closest functional comparison is Hyperic SIGAR, which also aimed to expose system information to Java across platforms and also relied on native code. The practical difference is packaging. SIGAR shipped its own native binaries per platform, which had to be located and loaded at runtime, and that is exactly the burden OSHI's README says it removes: no additional native libraries to install. OSHI reaches the operating system through JNA or through the JDK's own FFM API, so the native access is either a Java library dependency or a JDK feature rather than a set of `.so` and `.dll` files you distribute. That difference decides a lot in environments where you cannot drop binaries onto the host.

The other alternative is not a library at all: reading `/proc` and `/sys` yourself on Linux, calling `sysctl` on macOS and BSD, and using WMI or PowerShell on Windows. That gives you exactly the fields you need and nothing else, at the cost of maintaining a parser per platform and per kernel version. OSHI's native-free backend is essentially that approach productised: the README describes it as reading only procfs, sysfs, `sysctl` and other command-line tools, and it is limited to Linux and NetBSD. So if your target is Linux only and you want no native access, the native-free mode is the middle option between OSHI's own native backends and writing the parsers yourself.

What none of these give you is a stability guarantee about individual fields. OSHI's advantage is one API and one set of types across platforms; its cost is that the values behind those types vary in availability.

Version cadence, the MIT licence, and what upgrading actually costs

The repository is not archived and the last push was on 2026-08-23, the same day as the 7.6.0 release. The releases immediately before it, 7.5.0 and 7.4.4, landed on 2026-08-17 and 2026-08-06, so the project is moving quickly and patch releases are frequent. Frequent releases are good for platform fixes and less good for teams that pin versions and upgrade on a slow schedule; expect to revisit the dependency more often than you would for a library that ships twice a year.

There is a dedicated `UPGRADING.md` in the repository root, and the README links to it for project dependency details, specifically for the manual JAR case. That file is the place to look before a major bump, because a library that touches native interfaces can change behaviour between versions in ways a compile check will not catch.

The licence is MIT, which is permissive and imposes no copyleft obligation on your own code. Two caveats sit next to it. The optional `jLibreHardwareMonitor` dependency for Windows sensors carries MPL 2.0 for its binary DLLs, so if you enable Windows sensor support you are pulling in a differently licensed component. And on Android the README says you need the AAR artifact for JNA and must exclude OSHI's transitive JAR dependency, which is a build change rather than a legal one but is easy to miss. Neither point is legal advice; check the licences against your own distribution model.

The upgrade cost that is easy to underestimate is the classpath. Which backend is selected depends on which artifacts are present and which JDK is running, so an upgrade that adds or removes a dependency can silently change the implementation your application uses. The README's selection table is the thing to re-read after any dependency change, not just after a version bump.

Editorial conclusion

Adopt OSHI when you need a single Java API for CPU, memory, disk, network, sensor or container data across Windows, macOS, Linux and UNIX, and you accept that some values are unavailable on some platforms. Do not adopt it if you need a documented uptime or accuracy guarantee, if you cannot tolerate a native-access warning on JDK 25 or later, or if you only target Linux and want no native code at all. Before committing, verify three things against your own environment: which implementation SystemInfoFactory.create() selects on your classpath and JDK, whether the specific getters you plan to call are populated on your target OS (the per-platform support matrix is not in the README), and whether jLibreHardwareMonitor is needed for Windows sensors and acceptable under MPL 2.0.

Frequently asked questions

Official sources

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