OSHIを読む：JavaからOSとハードウェアを横断取得する設計

OSHIが一つのAPIに集めるシステム情報

OSHIは、Javaからオペレーティングシステムとハードウェア情報を読むための無料ライブラリです。READMEでは、追加のネイティブライブラリを別途インストールせずに、複数のOSで共通した取得方法を提供することを目標にしています。対象はOSの版とビルド、仮想化やハイパーバイザーの検出、物理CPUと論理CPU、CPU負荷、割り込み、稼働時間、プロセス、サービス、ログインセッション、メモリ、ファイルシステム、ディスク、ネットワーク、電池、USB、Bluetooth、画面、GPU、音声、センサー、コンテナ資源、プリンターまで広がります。

この範囲は、監視エージェント、診断画面、端末情報の収集、Java製の管理ツールを作るときに役立ちます。CPUについてはコア、ハイパースレッド、プロセッサグループ、NUMAノード、キャッシュ、機能フラグを扱えます。記憶装置については機種、シリアル番号、容量、読み書き、パーティション、論理ボリュームグループを取得できます。ネットワークではIP、帯域、経路表、TCPとUDP統計まで対象です。

ただし、対応項目が列挙されていることと、全OSで同じ精度の値が返ることは別です。READMEはベンチマーク結果や性能測定値を提示していません。センサーも一部ハードウェアに限られます。アプリケーション側では、項目ごとに未対応、権限不足、取得失敗を受け止め、空値や既定値を実測値として表示しない設計が必要です。

JNAとFFMを共通APIの下で選ぶ

OSHIには二つのネイティブアクセス実装があります。oshi-coreはJava Native Access、つまりJNAを使い、JDK 8以上に対応します。JPMSモジュール名はcom.github.oshiです。oshi-core-ffmはJDKのForeign Function and Memory APIを使い、JDK 25以上が必要です。こちらのJPMSモジュール名はcom.github.oshi.ffmです。両者はoshi-commonにある共通APIインターフェースを共有します。

この分割により、アプリケーション側の取得コードを大幅に変えずに、対象JDKや配布条件に合わせて実装を選べます。oshi-coreだけをクラスパスに置けばJNA、oshi-core-ffmだけならFFMが選ばれます。両方を置いた場合は、JDK 25以上ではFFM、それより古いJDKではJNAというREADMEの選択規則です。SystemInfoFactory.create()を使う場合、クラスパスとJDK版に基づいて経路が選ばれます。

FFMを採用する判断は、単に新しいAPIだからという理由だけでは足りません。実行環境がJDK 25以上で固定されているか、配布先のJPMS構成が合うか、既存のJNA依存を整理できるかを確認します。JNA経路とFFM経路が同じ結果を返すとは素材から証明できないため、CPU、メモリ、ディスク、ネットワークなど必要な項目を実機で比較するべきです。

oshi.nativefreeが担うLinuxとNetBSDの経路

oshi-commonには、三つ目の実装としてoshi.nativefreeがあります。これは純粋Javaで、procfs、sysfs、sysctl、その他のコマンドラインツールを読み取ります。ネイティブアクセスを使わないため、--enable-native-accessの指定を必要とせず、その指定がない場合にJDKが出す警告も発生しないとREADMEに説明されています。

この実装が対象にするのはLinuxとNetBSDです。クラスパスにoshi-coreもoshi-core-ffmもない場合、oshi.nativefree.SystemInfoが選択されます。ネイティブライブラリの配布を避けたいサーバーや、起動オプションを増やせない実行環境では検討しやすい経路です。一方、対象OSがWindows、macOS、AIX、FreeBSDなどであれば、この純粋Java経路だけを前提にすることはできません。

procfsやsysfs、sysctl、外部コマンドを読む方式では、OSのファイル構成、権限、コマンド出力、コンテナ境界の影響を受けます。READMEの説明だけでは、各項目の対応範囲や異常時の返却値までは分かりません。ネイティブアクセスを避けられる利点と、Linux・NetBSDに限定される範囲を比較し、監視項目ごとに欠損許容を決める必要があります。

7.6.0の依存関係と配布経路

素材のリポジトリ情報では、安定版としてJNA用oshi-core-7.6.0、FFM用oshi-core-ffm-7.6.0、共通部品oshi-common-7.6.0が示されています。スナップショット版はMaven Centralのスナップショットリポジトリから公開され、利用側のビルド設定でそのリポジトリを使う必要があります。JDK 7向けのoshi-core-3.13.6、JDK 6向けのoshi-core-3.14.0もレガシー版として記載されています。

READMEは、MavenやGradleなどの依存関係管理へoshi-core、oshi-core-ffmのいずれかを追加する方法を推奨しています。oshi-commonやJNAを含む推移的依存関係は自動解決されます。JARを手動管理する場合は、GitHub Releaseに添付されるoshi-distのZIPを使います。この配布物にはoshi-common、oshi-core、oshi-core-ffmと実行時依存が含まれますが、oshi-demoの例と依存関係は含まれません。

Windowsでセンサー情報が必要なら、任意のjLibreHardwareMonitor依存関係が候補になります。ただし、そこに含まれるバイナリDLLのライセンスはMPL 2.0です。AndroidではJNAのAARを追加し、OSHIから推移的に入るJAR依存を除外する必要があります。つまり、OSHI本体のMITライセンスだけを見ればよいわけではなく、採用する実装、補助部品、対象OSごとの依存ライセンスを個別に確認する必要があります。

SystemInfoFactoryと直接生成の使い分け

基本的な利用では、SystemInfoProvider si = SystemInfoFactory.create()としてインスタンスを得ます。ファクトリはクラスパスとJDK版を見て実装を選びます。実装を明示したい場合は、JNAのoshi.SystemInfo、FFMのoshi.ffm.SystemInfo、ネイティブアクセスを使わないoshi.nativefree.SystemInfoを直接生成できます。共通の取得コードを維持したい場合はファクトリが扱いやすく、起動環境を固定して差異を監査したい場合は直接生成が分かりやすい構成です。

取得対象へは、まずsi.getHardware()からHardwareAbstractionLayerを得て、hal.getProcessor()でCentralProcessorを取得します。si.getOperatingSystem()はOperatingSystemを返します。ここからメモリ、ディスク、ネットワーク、プロセスなど必要なコンポーネントへ進みます。インスタンス生成だけで情報が永続取得されるわけではなく、利用側が必要な間隔、収集項目、保存先、権限を設計する必要があります。

設定はoshi.properties、GlobalConfig、Javaシステムプロパティで変更できます。READMEは設定を起動時に行うよう求めています。設定はスレッドセーフではなく、動作中に再読込される保証もありません。アプリケーション起動後に複数スレッドから設定値を書き換える設計は避け、起動処理で設定を確定し、その後は読み取り専用として扱うのが安全です。

デモ、メトリクス、ベンチマークの役割

oshi-demoは概念実証用の例を含む追加モジュールです。Swing GUI、JSON出力、JMX統合があり、jbang json@oshi/oshiやjbang gui@oshi/oshiのようなコマンド例がREADMEにあります。取得できる情報の形を確かめる用途には向きますが、デモ画面の動作をそのまま本番監視の設計根拠にしてはいけません。必要な権限、収集周期、保存期間、個人情報の扱いは利用側の責任です。

oshi-metricsはMicrometer統合を提供します。システム、プロセス、コンテナのメトリクスをOpenTelemetryの意味規約に従って扱い、Prometheus、Grafana、Datadog、その他のMicrometer互換バックエンドで動かせるとREADMEに記載されています。既存のメトリクス基盤へ送る入口として整理されていますが、監視対象の許可範囲や送信失敗時の再試行は素材では説明されていません。

ושי-benchmarkではなくoshi-benchmarkには、JNAとFFMを比較するJMHベンチマークが含まれ、JDK 25以上が必要です。実行スクリプトはoshi-benchmark/scripts/run-benchmarks.shです。ベンチマークは二つの実装を自分の環境で比較する材料になりますが、README自体は性能数値を提示していません。CPU構成、OS、JDK、取得項目、権限によって結果は変わるため、一般的な優劣をREADMEから断定できません。

MITライセンスと採用前の確認範囲

OSHIはREADMEとライセンステキストの双方でMITライセンスとされています。著作権表示と許可表示を含める条件で、使用、複製、変更、統合、公開、配布、サブライセンス、販売が認められます。ライセンス本文はソフトウェアを現状のまま提供し、商品性、特定目的への適合性、非侵害性を含む保証を置いていません。セキュリティ、サポート、保守の提供をMITライセンスから読み取ることはできません。

READMEはSUPPORT.mdとSECURITY.mdを参照し、OSHIや他のオープンソースパッケージの商用サポートとしてTideliftサブスクリプションにも触れています。ただし、素材にあるREADMEはその契約内容や対応時間を要約していません。商用運用で支援が必要なら、個別の契約条件と対象範囲を確認してください。

採用前には、第一に対象OSとJDKを確定します。第二に、JNA、FFM、oshi.nativefreeのどの経路を使うかを決めます。第三に、CPU負荷、メモリ、ディスク、ネットワーク、センサー、コンテナ制限など必要項目を実機で読み、権限不足や未対応時の値を確認します。第四に、依存ライセンス、取得頻度、情報保存、障害時の表示を整理します。素材は最新の取得値や性能保証を示していないため、この確認を済ませずにOSHIの対応一覧だけで運用可否を決めるのは適切ではありません。

導入判定の記録には、採用したOSHI版、選択した実装、JDK版、対象OS、必要な取得項目を明記します。各項目について、取得成功、未対応、権限不足、値の遅延を分けて記録し、取得不能を正常値へ置き換えないようにします。監視の利用では、収集処理が本体業務を妨げない周期か、例外発生時に業務処理を停止しないか、情報を保存する権限が適切かも確認します。ライセンス表示と依存部品の一覧は配布物へ添付し、MPL 2.0のDLLを使う場合はその条件を別に管理します。対象端末の変更時には同じ確認を繰り返し、結果を版管理します。実機差の記録を残せば、更新後の数値変動を構成変更と照合できます。

実機導入で切り分けるOSHIの取得差

OSHIを監視や診断へ導入するときは、対応OS一覧を読んだだけで取得結果を同一視しないことが必要です。Windows、macOS、Linux、Android、AIX、各種BSD、Solarisでは、同じAPI名でも参照するカーネル機構、権限、ドライバー、仮想化層が異なります。CPU使用率、メモリ、ディスク容量、ネットワーク統計、電池状態、温度、ファン回転数は、装置の種類とOS設定によって空値、未対応、遅延値になる可能性があります。READMEは多数の機能を列挙していますが、全項目のOS別保証表や精度基準は示していません。

最初の確認では、対象端末のOS名、版、ビルド、JDK版、CPU構成、実行権限、コンテナ内外の位置を記録します。同じ端末でJNA、FFM、純粋Javaの各経路を使える場合は、CPU負荷、物理メモリ、ファイルシステム容量、プロセス一覧など代表項目を比較します。FFMはJDK 25以上、JNAはJDK 8以上、oshi.nativefreeはLinuxとNetBSDのみという条件を、配布設定と起動時検査へ反映してください。バージョン条件を満たさない実行環境へFFMを混ぜると、ファクトリ選択以前に依存解決や起動で失敗します。

次に、値の意味と更新間隔を決めます。稼働時間、CPU負荷、読み書き統計、帯域、電力使用量は時系列で読む項目ですが、機種情報、ファームウェア、シリアル番号、画面EDIDは毎回取得する必要がない項目です。取得処理を一つの周期へ詰め込むと、遅いセンサーや外部コマンドが全体を遅延させます。項目ごとに取得周期、保存期間、失敗時の再試行、表示状態を分け、空値をゼロへ変換しないでください。

コンテナではcgroup v1とv2の資源制限がホストの物理資源と異なることがあります。アプリケーションの利用可能メモリやCPUを判断するなら、ホスト情報、コンテナ制限、プロセス使用量を別の欄に保存します。OSHIが対象値を読めた場合でも、その値が業務プロセスの制限を表すかは実行場所によって変わります。監視画面の項目名にホスト、コンテナ、プロセスの対象を明記し、担当者が値の意味を誤らないようにする設計が望まれます。

依存関係の確認では、OSHIの本体、JNA、FFM、Android用AAR、Windowsセンサー用jLibreHardwareMonitorを分けて管理します。jLibreHardwareMonitorのバイナリDLLはMPL 2.0とREADMEに記載されています。OSHI本体がMITであることだけを根拠に、全配布物のライセンス条件を同一と扱うことはできません。手動でJARを配布する場合はoshi-distに含まれる部品と含まれないデモ部品を確認し、実行環境に必要な依存を固定します。

性能評価は、oshi-benchmarkのJMH比較を出発点にしつつ、自社の取得項目と端末で行います。READMEには性能数値がないため、JNAとFFMの一般的な優劣、センサー取得の遅さ、プロセス一覧の負荷を文書から断定できません。ベンチマーク結果にはJDK、OS、CPU、メモリ、実行権限、取得回数、並行数を添え、診断用の一回取得と長期監視用の反復取得を分けて解釈してください。

実機確認の結果は、OSHIの版、使用実装、対象項目、成功数、欠損数、取得時間とともに保存します。異なる端末で値が違っても、直ちにライブラリの不具合とは判断せず、OS設定、権限、ドライバー、仮想化、センサー装置の差を切り分けます。再現条件を記録してからIssueや社内障害票を作れば、取得値の問題と利用側の表示問題を分離できます。READMEに性能保証や項目別精度保証がない以上、実測記録を採用判断の根拠として明示することが必要です。

編集部の結論

OSHIは、JavaアプリケーションからOSとハードウェアの情報を統一的なAPIで取得したい開発者に適しています。JDK 8系を含む環境ではJNA、JDK 25以上を前提にできる環境ではFFM、LinuxまたはNetBSDでネイティブアクセスを避けたい場合はoshi-commonの純粋Java経路を選べます。ただし、センサー対応、権限、OSごとの取得差、性能、依存ライセンスは実行環境に左右されます。採用前に対象OS、JDK、必要項目、取得失敗時の扱いを実機で確認してください。

公式情報源

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