--- title: "Apache jcloudsとは？2025年の退役と最終版2.7.0の使い方・依存の脆弱性対応・移行先" url: "https://www.issoh.co.jp/tech/details/7002/" published: 2025-05-28 updated: 2026-11-06 categories: ["Java"] publisher: "株式会社一創" --- # Apache jcloudsとは？2025年の退役と最終版2.7.0の使い方・依存の脆弱性対応・移行先 Apache jcloudsは、AWS・Azure・Google Cloud・OpenStackなどのクラウドを、Javaから共通のAPIで操作するためのオープンソースライブラリです。ただし、プロジェクトは2025年6月に活動停止を理由に終了し、同年8月にApache Attic（退役プロジェクトの保管場所）へ移りました。最終版は2025年1月29日公開の2.7.0で、今後のバグ修正やセキュリティ修正は出ません。 この記事では、jcloudsの仕組みと最終版2.7.0のコードを、手元のJava 25で実行した結果つきで示します。2026年9月から10月にかけて、2.7.0が依存するGuavaに脆弱性が2件公開されました。依存を上書きして塞げるかも実測したうえで、既存のjclouds利用コードを使い続けるか移行するかの判断材料を整理します。 ## まとめ：Apache jcloudsの現状と既存コードの扱い - **jcloudsとは**：ContextBuilderでプロバイダ名と認証情報を渡し、ComputeService（仮想マシン）・BlobStore（オブジェクトストレージ）・LoadBalancerServiceといった共通APIで複数のクラウドを操作するJavaライブラリです。 - **現状**：2025年6月18日のApache理事会決議で終了し、2025年8月にAtticへ移りました。GitHubのリポジトリは2025年8月6日にアーカイブされ、ソース・メーリングリスト・JIRAはすべて読み取り専用です。 - **最終版**：2.7.0（2025-01-29）。動作にはJava 11以上が必要です。公式POMに列挙された実装モジュールは、プロバイダが48、APIが26です。 - **依存の脆弱性**：2.7.0が固定するGuava 33.4.0-jreには、2026年9月と10月に公開された脆弱性2件が該当します。Guavaを33.8.0-jreに上書きすると、サンプルは同じ結果のまま動きました。 - **Camel連携**：camel-jcloudsはCamel 4.0で削除され、Camel公式の移行ガイドは代替コンポーネントを「none」としています。 - **移行先**：BlobStoreの利用はApache OpenDALか各クラウドの公式SDKへ移します。ComputeServiceの利用は、TerraformやOpenTofuなどのIaCか、各クラウドのSDKへ移します。 - **使い続けてよい条件**：用途がオブジェクトの読み書き程度で、ライブラリを自社で保守できる場合に限ります。新規の採用は勧めません。 ## Apache jcloudsの仕組み：Javaから複数クラウドを共通APIで操作する構造 jcloudsは、各クラウドのREST APIの違いをライブラリ側で吸収し、アプリケーションには同じメソッドを見せる設計です。接続先を変えるときに書き換えるのは、原則としてプロバイダ名と認証情報だけです。 ### ContextBuilderとView：ComputeService・BlobStore・LoadBalancerService 入口は `ContextBuilder.newBuilder("プロバイダ名")` です。認証情報を渡し、`buildView()` で用途別の「View」を組み立てます。Viewは3種類あります。 | View | 取り出すAPI | 扱う対象 | Mavenモジュール | | -------------------------- | ------------------- | --------------- | -------------------- | | ComputeServiceContext | ComputeService | 仮想マシン（ノード） | jclouds-compute | | BlobStoreContext | BlobStore | コンテナ（バケット）とBlob | jclouds-blobstore | | LoadBalancerServiceContext | LoadBalancerService | ロードバランサー | jclouds-loadbalancer | Viewで表現できないクラウド固有の機能は、各プロバイダのAPIクラスを直接取り出して呼びます。共通APIで足りる処理は共通APIで書き、足りない部分だけ固有APIに降りる、という使い分けが前提の設計です。内部ではGoogle GuiceでDI（依存性の注入）を組み、HTTP通信・再試行・署名の処理を差し替え可能にしています。DIの考え方は[依存性の注入（DI）と依存性逆転の原則（DIP）の違い](/tech/details/2761/)で解説しています。 ### プロバイダとAPIの違い：2.7.0で48プロバイダ・26API jcloudsの接続先には「API」と「プロバイダ」の2層があります。APIはクラウドの通信方式の実装（例：`s3`、`openstack-swift`、`ec2`）で、接続先のURLを指定して使います。プロバイダは特定事業者向けに既定値を詰めた実装（例：`aws-s3`、`azureblob`、`google-cloud-storage`、`aws-ec2`、`google-compute-engine`）です。2.7.0の公式POM（[jclouds-providers-project](https://repo1.maven.org/maven2/org/apache/jclouds/provider/jclouds-providers-project/2.7.0/jclouds-providers-project-2.7.0.pom)・[jclouds-apis-project](https://repo1.maven.org/maven2/org/apache/jclouds/api/jclouds-apis-project/2.7.0/jclouds-apis-project-2.7.0.pom)）が `` として列挙する実装モジュールは、プロバイダが48件、APIが26件です。集約用の親POMは実装数に含めません。 この中には、提供が終わったサービス向けのプロバイダも残っています。たとえば `packet` の接続先は、Equinix Metalの前身であるPacketのAPI（`https://api.packet.net`）ですが、Equinix Metalは2026年6月30日でサービスを終了しました。プロバイダの一覧は退役時点のまま更新されないため、使いたい接続先が2.7.0に入っているかは、最初にMaven Centralの `org.apache.jclouds.provider` 配下で確認してください。S3互換ストレージなら、汎用APIの `s3` に接続先URLを渡す方法も取れます。 ## 退役の経緯：2025年6月の終了決議とApache Atticへの移管 jcloudsは2013年10月にApacheのトップレベルプロジェクトになりました（[Apache Atticのjcloudsページ](https://attic.apache.org/projects/jclouds.html)）。利用は続いていた一方で、開発者が減り続けたことが終了の理由です。[Apache理事会議事録のjclouds報告](https://whimsy.apache.org/board/minutes/jclouds.html)のうち2022年10月の報告では、jclouds-coreの直近12か月のダウンロード数が5万から8万に増えたのに対し、コミットは2018年の26人・123件から2022年の6人・24件に減っていました。報告は、近いうちにリリースの承認に必要な人数（quorum）を欠く見込みだと述べています。 | 時期 | 出来事 | | ---------- | -------------------------- | | 2013年10月 | Apacheのトップレベルプロジェクトに昇格 | | 2022年3月26日 | 2.5.0公開（Java 17対応） | | 2022年10月 | 理事会報告でAttic移管の検討を表明 | | 2024年3月10日 | 2.6.0公開（Java 21・Guice 7対応） | | 2025年1月29日 | 2.7.0公開（最終版） | | 2025年6月18日 | 理事会がプロジェクト終了を決議 | | 2025年8月6日 | GitHubのリポジトリをアーカイブ | | 2025年8月 | Apache Atticへの移管完了 | 2022年の報告後、Apache BrooklynとApache Karafのコミュニティから存続に協力する申し出がありました。しかし、その後の理事会報告によれば、実際のコントリビュートにはつながりませんでした。Atticへ移ったプロジェクトはコードも課題管理も読み取り専用になり、脆弱性が見つかっても公式の修正版は出ません。[公式サイト](https://jclouds.apache.org/)のGetting Startedと、GitHubのサンプル集jclouds-examplesは今も読めますが、どちらも退役時点のまま更新されません。 ## 最終版2.7.0の導入とBlobStore・ComputeServiceのコード例 以下のコードは、2026年11月6日にIntel Mac・Temurin 25.0.5・Maven 3.9.16・jclouds 2.7.0で実行して出力を確認したものです。クラウドの認証情報なしで動くよう、BlobStoreはメモリ上の `transient` とローカルディスクの `filesystem`、ComputeServiceは検証用の `stub` プロバイダを使っています。 ### Maven依存関係：2.7.0はJava 11以上が必須 以下は既存のpom.xmlのproject要素内に追加する断片です。共通APIのモジュールと、接続先の実装を別々に追加します。以下はAmazon S3向けの例に、後掲のBlobDemoを `filesystem` で動かすための `org.apache.jclouds.api:filesystem` を加えたものです。メモリ上の `transient` はjclouds-blobstoreに、検証用の `stub` はjclouds-computeに含まれているため、追加の依存は要りません。複数のクラウドを使うなら、プロバイダの依存を接続先の数だけ並べます。この依存がないプロバイダ名を `ContextBuilder.newBuilder()` に渡すと `NoSuchElementException` になります。 ``` 11 2.7.0 org.apache.jclouds jclouds-blobstore ${jclouds.version} org.apache.jclouds jclouds-compute ${jclouds.version} org.apache.jclouds.provider aws-s3 ${jclouds.version} org.apache.jclouds.api filesystem ${jclouds.version} ``` コンパイルと実行は、Mavenでクラスパスを書き出してから行えます（macOS・Linuxの例）。 ``` mvn -q dependency:build-classpath -Dmdep.outputFile=cp.txt javac --release 11 -cp "$(cat cp.txt)" -d out BlobDemo.java ComputeDemo.java java -cp "out:$(cat cp.txt)" BlobDemo transient java -cp "out:$(cat cp.txt)" BlobDemo filesystem java -cp "out:$(cat cp.txt)" ComputeDemo ``` 2.7.0のjclouds-coreはJava 11向けのクラスファイル（major version 55）でビルドされています。2.6.0まではJava 8向け（major version 52）で、2.6.0の公式POMは `jdk.version` に1.8を指定し、依存するGuice 7.0.0もJava 8向けのクラスファイルです。Java 8環境で使えるのは2.6.0までですが、使うプロバイダの依存も含めて手元で動作を確かめてください。 ### BlobStoreでのアップロードと一覧取得 コンテナを作り、Blobを1件書き込んでから一覧を取る例です。プロバイダ名を引数で切り替えられるようにしています。 ``` import com.google.common.io.ByteSource; import java.nio.charset.StandardCharsets; import java.util.Properties; import org.jclouds.ContextBuilder; import org.jclouds.blobstore.BlobStore; import org.jclouds.blobstore.BlobStoreContext; import org.jclouds.blobstore.domain.Blob; import org.jclouds.blobstore.domain.StorageMetadata; import org.jclouds.blobstore.options.ListContainerOptions; public class BlobDemo { public static void main(String[] args) throws Exception { String provider = args.length > 0 ? args[0] : "transient"; // "aws-s3" などに差し替える ContextBuilder builder = ContextBuilder.newBuilder(provider) .credentials("identity", "credential"); if (provider.equals("filesystem")) { Properties p = new Properties(); p.setProperty("jclouds.filesystem.basedir", "/tmp/jc7002/data"); builder.overrides(p); } try (BlobStoreContext context = builder.buildView(BlobStoreContext.class)) { BlobStore blobStore = context.getBlobStore(); blobStore.createContainerInLocation(null, "reports"); ByteSource payload = ByteSource.wrap("hello jclouds".getBytes(StandardCharsets.UTF_8)); Blob blob = blobStore.blobBuilder("2026/10/hello.txt") .payload(payload) .contentLength(payload.size()) .contentType("text/plain") .build(); System.out.println("provider=" + provider + " etag=" + blobStore.putBlob("reports", blob)); for (StorageMetadata m : blobStore.list("reports")) { System.out.println("list: " + m.getName() + " type=" + m.getType()); } for (StorageMetadata m : blobStore.list("reports", ListContainerOptions.Builder.recursive())) { System.out.println("recursive: " + m.getName() + " type=" + m.getType()); } } } } ``` Java 25では、Guava 33.4.0が `sun.misc.Unsafe::objectFieldOffset` を呼ぶ旨の警告が出ます。今は動作に影響しませんが、jclouds側で依存が更新されることはもうありません。依存を上書きしたときの挙動は「退役後の依存ライブラリの脆弱性」の章で扱います。 ### ComputeServiceでのノード作成と削除 Templateで「Ubuntu・メモリ2GB以上・22番と80番ポートを開放」という条件を書き、条件に合うハードウェアをjcloudsに選ばせる例です。`createNodesInGroup` はグループ名をまとめて扱う単位にし、削除もグループ名で絞り込みます。 ``` import static org.jclouds.compute.options.TemplateOptions.Builder.inboundPorts; import java.util.Set; import org.jclouds.ContextBuilder; import org.jclouds.compute.ComputeService; import org.jclouds.compute.ComputeServiceContext; import org.jclouds.compute.domain.NodeMetadata; import org.jclouds.compute.domain.OsFamily; import org.jclouds.compute.domain.Template; public class ComputeDemo { public static void main(String[] args) throws Exception { // "stub" はクラウドに接続しない検証用プロバイダ。本番では "aws-ec2" 等と認証情報を渡す try (ComputeServiceContext context = ContextBuilder.newBuilder("stub") .buildView(ComputeServiceContext.class)) { ComputeService compute = context.getComputeService(); Template template = compute.templateBuilder() .osFamily(OsFamily.UBUNTU) .minRam(2048) .options(inboundPorts(22, 80)) .build(); System.out.println("hardware=" + template.getHardware().getId() + " ram=" + template.getHardware().getRam()); Set nodes = compute.createNodesInGroup("web", 2, template); for (NodeMetadata n : nodes) { System.out.println(n.getId() + " " + n.getStatus() + " " + n.getPublicAddresses()); } compute.destroyNodesMatching(node -> "web".equals(node.getGroup())); System.out.println("remaining=" + compute.listNodes().size()); } } } ``` ``` hardware=medium ram=7680 1 RUNNING [144.175.1.1] 2 RUNNING [144.175.1.2] remaining=0 ``` `minRam(2048)` を指定しても、選ばれたのはメモリ7,680MBの「medium」でした。templateBuilderは条件を満たすハードウェアの中から選ぶため、指定した値ちょうどのサイズになるとは限りません。本番のクラウドでは料金に直結するので、`hardwareId()` でインスタンスタイプを明示するほうが安全です。 ## BlobStoreの移植性の限界：プロバイダで変わる一覧結果 「プロバイダ名を変えるだけで同じコードが動く」はjcloudsの売りですが、結果まで同じになるとは限りません。上のBlobDemoを `transient` と `filesystem` で実行すると、同じ1件のBlobに対して一覧の結果が違いました。 ``` $ java -cp ... BlobDemo transient provider=transient etag=21190cdc3960c2d5171912fed7033ed1 list: 2026/ type=RELATIVE_PATH recursive: 2026/10/hello.txt type=BLOB $ java -cp ... BlobDemo filesystem provider=filesystem etag=21190cdc3960c2d5171912fed7033ed1 list: 2026/ type=FOLDER recursive: 2026/ type=FOLDER recursive: 2026/10/ type=FOLDER recursive: 2026/10/hello.txt type=BLOB ``` - 再帰なしの `list()` で返る `2026/` の型が、transientでは `RELATIVE_PATH`、filesystemでは `FOLDER` です。 - 再帰ありの `list()` では、filesystemだけがディレクトリ2件（`2026/`・`2026/10/`）を返します。transientが返すのはBlob1件だけです。 テストではtransientを、本番ではS3などを使う構成で、件数を数える処理や `getType() == BLOB` での絞り込みを省いていると、環境ごとに結果が変わります。jcloudsのコードを移行するときも、この「プロバイダごとの差」がテストに暗黙に織り込まれていないかを先に確かめてください。共通APIで書いたコードでも、検証は接続先ごとに必要です。 ## 退役後の依存ライブラリの脆弱性：Guava 33.4.0-jreの上書き jclouds本体の修正版は出ませんが、jcloudsが引き込むライブラリには今も脆弱性が見つかります。2.7.0の公式POMはGuavaを33.4.0-jre、Guiceを7.0.0に固定しています。 ### 2.7.0の実行時依存29件とGuavaの脆弱性2件 前掲のPOM（jclouds-blobstore・jclouds-compute・aws-s3・filesystem）で `mvn dependency:list` を実行すると、実行時の依存は29件でした。この29件を2026年11月6日に[OSV（オープンソースの脆弱性データベース）](https://osv.dev/)のAPIで照会したところ、既知の脆弱性が登録されていたのはGuava 33.4.0-jreだけで、jclouds自身の成果物には登録がありませんでした。Guavaのリポジトリのアドバイザリでは、33.4.0-jreに該当するものが2件公開されています。2件目は照会の時点でOSVに未登録だったため、OSVの結果だけで依存の安全を判断しないでください。 1件目は2026年9月29日公開の[GHSA-xxph-c9ww-hj94](https://github.com/google/guava/security/advisories/GHSA-xxph-c9ww-hj94)（CVE-2026-102554、ベンダー評価はModerate、CVSS 3.1は5.9）です。Guavaの `CompactHashMap`・`CompactHashSet`・`MapMakerInternalMap` は、Java標準のシリアライズから復元するとき、ストリームから読み取った要素数や初期容量について、上限や実際のデータ量との整合性を十分に検証せず、大きな配列を確保することがあります。そのため72バイトの細工したデータで数GBのメモリ確保を起こし、`OutOfMemoryError` でJVMを停止させられます。対象はGuava 4.0以上33.7.2未満で、33.7.2で修正されました。影響を受けるのは、外部から受け取ったデータを `ObjectInputStream` で復元している場合です。 2件目は2026年10月31日公開の[GHSA-v5x9-67m3-7m56](https://github.com/google/guava/security/advisories/GHSA-v5x9-67m3-7m56)（CVE-2026-118042、ベンダー評価はLow）です。`HashBiMap` はキーや値の、`LinkedHashMultimap` は同じキーに属する値のハッシュ衝突への対策が不十分なため、同じハッシュ値の文字列（`"Aa"` と `"BB"` の組み合わせなど）を詰めた入力で、構築の処理量が要素数の2乗に増えます。対象はGuava 13.0以上33.8.0未満で、修正版は33.8.0です。リクエストのヘッダー名やJSONのキーをこれらのコレクションに入れている場合に影響します。復元処理の危険と防ぎ方は[安全でないデシリアライゼーションとは？RCEに至る仕組みと言語別の防御実装を解説](/tech/details/16369/)で扱っています。 ### Guava 33.8.0-jreへの更新：dependencyManagementによる依存の上書き jcloudsの新しい版は出ないため、利用者のPOMでGuavaの版を上書きします。`dependencyManagement` に書いた版は、jcloudsが推移的に引き込む版より優先されます。 ``` com.google.guava guava 33.8.0-jre ``` 2件とも塞ぐには33.8.0以上が必要です。この上書きで `mvn dependency:list` のGuavaは33.8.0-jreになり、依存は28件、OSVの既知脆弱性は0件になりました。前掲のBlobDemo（transient・filesystem）とComputeDemoを実行し直した出力は、上書き前と1行も変わりませんでした。 ただし、`sun.misc.Unsafe` の警告は消えません。警告の呼び出し元として表示されるクラスが、Guavaの `AbstractFuture$UnsafeAtomicHelper` から、Guice 7.0.0の `HiddenClassDefiner` に変わるだけです。Guiceは2023年5月公開の7.0.0が最新版のため、こちらは上書きで逃げられません。 退役したApache jcloudsプロジェクトからは、依存を上書きした構成への公式サポートは提供されません。使い続けるなら、依存の脆弱性を継続して検出する仕組みと、上書きのたびに接続先ごとのテストを回す体制が前提です。依存の脆弱性を検出する仕組みは[SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説](/tech/details/16216/)で説明しています。 ## Apache Camelのjcloudsコンポーネント：Camel 4.0で削除 CamelのルートからBlobStoreやComputeServiceを呼ぶ `camel-jclouds` コンポーネントは、Camel 4.0で削除されました。Camel公式の「[Camel 3.x to 4.0 Migration Guide](https://camel.apache.org/manual/camel-4-migration-guide.html)」は削除コンポーネントの一覧にcamel-jcloudsを載せ、代替を「none」としています。Camel 3系の最終版3.22.4（2025年3月公開）のcamel-jcloudsは、jclouds 2.5.0を参照したままです。 Camel 4へ上げる場合は、接続先ごとの専用コンポーネントに書き換えます。2026年11月時点の最新版4.23.0には、Amazon S3向けの `camel-aws2-s3`、Azure Blob Storage向けの `camel-azure-storage-blob`、Google Cloud Storage向けの `camel-google-storage`、MinIO向けの `camel-minio` があります。複数のクラウドを1つのURI体系で切り替える書き方はできなくなるため、接続先の数だけルートの設定を分けることになります。 ## 既存のjclouds利用コードの移行先と判断基準 移行先は、jcloudsのどのViewを使っているかで変わります。最初に、コード中の `BlobStoreContext`・`ComputeServiceContext`・`LoadBalancerServiceContext` の利用箇所を洗い出してください。 ### BlobStoreの利用：Apache OpenDALか各クラウドSDK Apache AtticのjcloudsページはBlobStoreの利用者向けに、多数のストレージを1つのデータアクセス層で扱える関連プロジェクトとしてApache OpenDALを挙げています。OpenDALはRustで実装され、Java向けにはJNI経由のバインディングがあります。次のコードは、OpenDAL 0.50.8をJava 25.0.5で実行して出力を確認したものです。 ``` // pom.xml: org.apache.opendal:opendal:0.50.8 と、実行OS用の classifier 付き同名artifact // （例 osx-x86_64 / linux-x86_64 / windows-x86_64）の2つを依存に入れる import java.nio.charset.StandardCharsets; import java.util.HashMap; import java.util.Map; import org.apache.opendal.Entry; import org.apache.opendal.Operator; public class OpenDalDemo { public static void main(String[] args) { Map conf = new HashMap<>(); conf.put("root", "/tmp/od7002/data"); // "s3" なら bucket・region・endpoint 等を渡す try (Operator op = Operator.of("fs", conf)) { op.write("reports/2026/10/hello.txt", "hello opendal".getBytes(StandardCharsets.UTF_8)); System.out.println(new String(op.read("reports/2026/10/hello.txt"), StandardCharsets.UTF_8)); for (Entry e : op.list("reports/2026/10/")) { System.out.println("list: " + e.getPath()); } } } } // 実行結果（Java 25） // hello opendal // list: reports/2026/10/ // list: reports/2026/10/hello.txt ``` jcloudsとの違いは3点あります。OpenDALのJavaバインディングはネイティブライブラリを含むため、実行するOS・CPUごとのclassifier（linux-x86\_64、osx-aarch\_64など）を依存に追加する必要があります。Java 25では `System::loadLibrary` の呼び出しに対して `--enable-native-access=ALL-UNNAMED` を付けるよう求める警告が出ます。今回のOpenDAL 0.50.8のfsバックエンドでの一覧取得では、指定したディレクトリ自身（`reports/2026/10/`）も結果に含まれました。 接続先が1つのクラウドに決まっているなら、AWS SDK for Java 2.xなど各社の公式SDKへ移すほうが単純です。マルチクラウドの抽象化が本当に必要か、移行の前に見直してください。S3互換APIの範囲は[オブジェクトストレージとは？仕組み・S3互換APIの範囲](/tech/details/13369/)で、セルフホストのS3互換ストレージの選択肢は[MinIOとは？S3互換オブジェクトストレージの仕組み](/tech/details/16006/)で扱っています。 ### ComputeServiceの利用：IaCか各クラウドSDK ComputeServiceに相当するJavaライブラリは、Atticのページも示していません。移行先は、仮想マシンを作るタイミングで分かれます。デプロイ時に決まった台数を用意しているだけなら、作成をTerraformやOpenTofuなどのIaCへ移し、アプリケーション側は各クラウドのSDKで状態を参照するだけにする構成が現実的です。負荷や利用者の操作に応じて実行時に仮想マシンを作る場合も、[HCP TerraformのRun API](https://developer.hashicorp.com/terraform/cloud-docs/api-docs/run)からplan・applyを起動すればIaCで扱えます。ただし、要求ごとの作成処理をアプリケーション内で制御する用途では、各クラウドのSDKへの移行を勧めます。移行先のクラウド基盤の設計や構築を外部に任せる場合は、弊社の[インフラ構築（AWS・Google Cloud・Azure）](/service/system/aws/)でも相談を受けています。Terraformとのライセンスの違いを含めた選び方は[OpenTofuとは？Terraformとのライセンス・機能差と移行判断](/tech/details/15299/)を参照してください。 ### jcloudsを使い続けてよい条件：S3Proxyのフォーク事例 jcloudsを使う代表的なOSSであるS3Proxy（S3 APIを受けてAzure・Google Cloud・ローカルディスクなどへ中継するプロキシ）は、退役後に段階を踏んでjcloudsから離れました。[S3Proxyのリリースノート](https://github.com/gaul/s3proxy/releases)によると、3.2.0（2026年6月）で各ストレージの既定実装をjcloudsから各社SDKベースへ切り替え、3.3.0（2026年7月）を「jcloudsに依存する最後のリリース」とし、4.0.0（2026年8月）でjcloudsと、Atmos・B2の2つのストレージバックエンドを削除しました。BlobStore APIはjcloudsから派生したコードとして `org.gaul.s3proxy.blobstore` パッケージに取り込み、設定キーは `jclouds.provider` などの名前のまま残しています。2026年9月の最新版4.1.1のPOMにも、jcloudsへの依存はありません。退役後も使い続けるなら、このように必要な部分を自社で保守する体制が前提になります。 この記事の判断は次のとおりです。新規のシステムでjcloudsを採用するのはやめてください。既存のシステムで使い続けてよいのは、BlobStoreの基本操作だけを使っていて、依存ライブラリの脆弱性対応を自社で回せる場合に限ります。ComputeServiceで本番の仮想マシンを作っている、またはCamel 4への更新を控えている場合は、移行を先送りできません。OSSを採用するときの保守リスクの見方は[オープンソースソフトウェア（OSS）とは｜ライセンス種別と採用判断・リスク管理](/tech/details/13437/)にまとめています。 ## よくある質問 ### jcloudsとは何ですか？ Javaから複数のクラウドを共通APIで操作するApacheのライブラリです。ComputeServiceで仮想マシンを、BlobStoreでオブジェクトストレージを、LoadBalancerServiceでロードバランサーを扱います。2025年6月にプロジェクトが終了し、現在はApache Atticで読み取り専用になっています。 ### jcloudsの最新バージョンはいくつですか？ 2025年1月29日公開の2.7.0が最終版です。プロジェクトが終了したため、これより新しい版は出ません。Maven Centralからは引き続き取得できます。 ### jcloudsはJava 17やJava 21で動きますか？ 2.5.0でJava 17、2.6.0でJava 21に対応しました。2.7.0はJava 11以上が必要です。Java 25.0.5でも動作しましたが、`sun.misc.Unsafe` に関する警告が出ます。Guavaを新しい版に上書きしても、Guice 7.0.0が同じ種類の警告を出します。 ### Camel 4でjcloudsコンポーネントは使えますか？ 使えません。camel-jcloudsはCamel 4.0で削除され、公式の代替もありません。camel-aws2-s3やcamel-azure-storage-blobなど、接続先ごとのコンポーネントに書き換えてください。 ### jcloudsの代わりになるライブラリはありますか？ オブジェクトストレージの用途なら、Apache AtticのページがApache OpenDALを挙げています。接続先が1つなら各クラウドの公式SDKが最も単純です。仮想マシンをデプロイ時に用意する用途ではTerraformやOpenTofuなどのIaCを、アプリケーションから要求ごとに作成・操作する用途では各クラウドのSDKを移行先として勧めます。 ## 関連記事 - [MinIOとは？S3互換オブジェクトストレージの仕組みとOSS版アーカイブ後の採用判断【2026年9月時点】](/tech/details/16006/) - [オブジェクトストレージとは？仕組み・S3互換APIの範囲とブロックとの違いを実装手順つきで解説](/tech/details/13369/) - [OpenTofuとは？Terraformとのライセンス・機能差と移行判断を実装視点で解説](/tech/details/15299/) - [オープンソースソフトウェア（OSS）とは｜ライセンス種別と実装現場での採用判断・リスク管理](/tech/details/13437/) - [SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説](/tech/details/16216/) --- 出典: [Apache jcloudsとは？2025年の退役と最終版2.7.0の使い方・依存の脆弱性対応・移行先]()（株式会社一創）