公開更新 Java

Apache jcloudsとは？2025年の退役と最終版2.7.0の使い方・依存の脆弱性対応・移行先

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）の違いで解説しています。

プロバイダと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・jclouds-apis-project）が <module> として列挙する実装モジュールは、プロバイダが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ページ）。利用は続いていた一方で、開発者が減り続けたことが終了の理由です。Apache理事会議事録のjclouds報告のうち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へ移ったプロジェクトはコードも課題管理も読み取り専用になり、脆弱性が見つかっても公式の修正版は出ません。公式サイトの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 になります。

<properties>
  <maven.compiler.release>11</maven.compiler.release>
  <jclouds.version>2.7.0</jclouds.version>
</properties>

<dependencies>
  <!-- BlobStore（オブジェクトストレージ）の共通API -->
  <dependency>
    <groupId>org.apache.jclouds</groupId>
    <artifactId>jclouds-blobstore</artifactId>
    <version>${jclouds.version}</version>
  </dependency>
  <!-- ComputeService（仮想マシン）の共通API -->
  <dependency>
    <groupId>org.apache.jclouds</groupId>
    <artifactId>jclouds-compute</artifactId>
    <version>${jclouds.version}</version>
  </dependency>
  <!-- 接続先ごとのプロバイダ（例：Amazon S3） -->
  <dependency>
    <groupId>org.apache.jclouds.provider</groupId>
    <artifactId>aws-s3</artifactId>
    <version>${jclouds.version}</version>
  </dependency>
  <!-- 後掲のBlobDemoを filesystem で動かす場合のみ（ローカルディスク） -->
  <dependency>
    <groupId>org.apache.jclouds.api</groupId>
    <artifactId>filesystem</artifactId>
    <version>${jclouds.version}</version>
  </dependency>
</dependencies>

コンパイルと実行は、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<? extends NodeMetadata> 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（オープンソースの脆弱性データベース）のAPIで照会したところ、既知の脆弱性が登録されていたのはGuava 33.4.0-jreだけで、jclouds自身の成果物には登録がありませんでした。Guavaのリポジトリのアドバイザリでは、33.4.0-jreに該当するものが2件公開されています。2件目は照会の時点でOSVに未登録だったため、OSVの結果だけで依存の安全を判断しないでください。

1件目は2026年9月29日公開の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（CVE-2026-118042、ベンダー評価はLow）です。HashBiMap はキーや値の、LinkedHashMultimap は同じキーに属する値のハッシュ衝突への対策が不十分なため、同じハッシュ値の文字列（"Aa" と "BB" の組み合わせなど）を詰めた入力で、構築の処理量が要素数の2乗に増えます。対象はGuava 13.0以上33.8.0未満で、修正版は33.8.0です。リクエストのヘッダー名やJSONのキーをこれらのコレクションに入れている場合に影響します。復元処理の危険と防ぎ方は安全でないデシリアライゼーションとは？RCEに至る仕組みと言語別の防御実装を解説で扱っています。

Guava 33.8.0-jreへの更新：dependencyManagementによる依存の上書き

jcloudsの新しい版は出ないため、利用者のPOMでGuavaの版を上書きします。dependencyManagement に書いた版は、jcloudsが推移的に引き込む版より優先されます。

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>33.8.0-jre</version>
    </dependency>
  </dependencies>
</dependencyManagement>

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との違い・導入判断を解説で説明しています。

Apache Camelのjcloudsコンポーネント：Camel 4.0で削除

CamelのルートからBlobStoreやComputeServiceを呼ぶ camel-jclouds コンポーネントは、Camel 4.0で削除されました。Camel公式の「Camel 3.x to 4.0 Migration Guide」は削除コンポーネントの一覧に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<String, String> 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の範囲で、セルフホストのS3互換ストレージの選択肢はMinIOとは？S3互換オブジェクトストレージの仕組みで扱っています。

ComputeServiceの利用：IaCか各クラウドSDK

ComputeServiceに相当するJavaライブラリは、Atticのページも示していません。移行先は、仮想マシンを作るタイミングで分かれます。デプロイ時に決まった台数を用意しているだけなら、作成をTerraformやOpenTofuなどのIaCへ移し、アプリケーション側は各クラウドのSDKで状態を参照するだけにする構成が現実的です。負荷や利用者の操作に応じて実行時に仮想マシンを作る場合も、HCP TerraformのRun APIからplan・applyを起動すればIaCで扱えます。ただし、要求ごとの作成処理をアプリケーション内で制御する用途では、各クラウドのSDKへの移行を勧めます。移行先のクラウド基盤の設計や構築を外部に任せる場合は、弊社のインフラ構築（AWS・Google Cloud・Azure）でも相談を受けています。Terraformとのライセンスの違いを含めた選び方はOpenTofuとは？Terraformとのライセンス・機能差と移行判断を参照してください。

jcloudsを使い続けてよい条件：S3Proxyのフォーク事例

jcloudsを使う代表的なOSSであるS3Proxy（S3 APIを受けてAzure・Google Cloud・ローカルディスクなどへ中継するプロキシ）は、退役後に段階を踏んでjcloudsから離れました。S3Proxyのリリースノートによると、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）とは｜ライセンス種別と採用判断・リスク管理にまとめています。

よくある質問

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を移行先として勧めます。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.11　テックブログ Microsoft 2026年11月の月例更新：Outlookの悪用済みCVE-2026-124194と修正版の確認方法
  2. 2026.11.11　テックブログ JANISの不正アクセス：最大11,652名の医療機関情報と情報窃取プログラムの検知設定
  3. 2026.11.11　テックブログ SMBC日興証券の不正アクセス：持株会会員最大5.6万人の範囲と受託システムの分離設計
  4. 2026.01.21　コラム 税務調査の録音は禁止？判例・裁決と国税局マニュアルで見る、断られたときの対応
  5. 2026.11.09　テックブログ ステップゴルフ不正アクセス：口座情報の対象確認と偽連絡・引き落としの注意点

RELATED POSTS 関連記事

一覧へ戻る

目次