OSHI Documentation

OSHI is a modern alternative to Hyperic's SIGAR for cross-platform system monitoring. Key differences include:

• No Additional DLLs: Unlike SIGAR, which requires platform-specific native C DLLs, OSHI uses JNA to access native APIs, eliminating the need for manual installation of platform-specific binaries.
• Active Development: SIGAR has been abandoned (last release in 2010), whereas OSHI is actively maintained by open-source volunteers.
• Support: OSHI has an active community and developer support, unlike SIGAR which is unsupported.

OSHI provides three named JPMS modules. Add the one that matches your native access preference to your module-info.java:

• com.github.oshi.common: Public API interfaces and native-free implementation (oshi-common). Works on JDK 8+ on the classpath; JDK 9+ on the module path. Currently supports Linux only.
• com.github.oshi: JNA-based implementation (oshi-core). Works on JDK 8+ on the classpath; JDK 9+ on the module path.
• com.github.oshi.ffm: FFM-based implementation (oshi-core-ffm). Requires JDK 25+.

requires com.github.oshi.common; // API + native-free implementation (Linux only)
requires com.github.oshi;        // JNA
requires com.github.oshi.ffm;    // FFM

If running with the OpenTelemetry Java Agent, enable the Micrometer bridge using the system property -Dotel.instrumentation.micrometer.enabled=true. Then, register the metrics with Micrometer's global registry. The agent will automatically bridge the global registry to the OpenTelemetry SDK.

-Dotel.instrumentation.micrometer.enabled=true

import io.micrometer.core.instrument.Metrics;

OshiMetrics.bindTo(Metrics.globalRegistry, SystemInfoFactory.create());

To run an OSHI agent that exposes system metrics via JMX, use the CreateJmxOshiAgent factory class. You can either specify a port and host directly or provide a HashMap of properties for advanced configuration (such as custom RMISocketFactory or TLS settings).

After creating the agent, you must call .start() to begin the server.

In 7.x, oshi-core contains a full module-info.class. If using the module path, it is now a named module with explicit exports and opens directives.

FFM Module Rename

The FFM module artifact is now oshi-core-ffm (previously oshi-core-java25). The JPMS module name is now com.github.oshi.ffm. Update your module-info.java as follows:

requires com.github.oshi.ffm;

Handling Module Path behavior

If you rely on accessing non-exported internal packages via the module path, you may need to add --add-opens flags or switch to the classpath. To force classpath behavior in Maven Surefire:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <useModulePath>false</useModulePath>
    </configuration>
</plugin>

Standard Windows APIs for sensor information can be unreliable. For more reliable data, add jLibreHardwareMonitor as a dependency to your project. OSHI uses this as an optional dependency.

<!-- Maven -->
<dependency>
    <groupId>io.github.pandalxb</groupId>
    <artifactId>jLibreHardwareMonitor</artifactId>
</dependency>

// Gradle
implementation("io.github.pandalxb:jLibreHardwareMonitor")

Feature implementation is driven by community contribution. If you want a feature implemented:

• Submit Code: If you can provide the full implementation, it is highly likely to be added.
• Provide Information: If you cannot code, providing cross-platform documentation or pointers to where information can be found is also highly valued.
• Submit Issues: You can submit an issue to request a feature, though implementation depends on developer availability and documentation availability.

While GitHub Actions automatically deploys snapshots for pushes to the master branch, you can manually deploy snapshots using the Maven deploy command.

mvn clean deploy