1. ホーム
2. Play リリース
3. Play 2.9
4. マイグレーションガイド

§Play 2.9 マイグレーションガイド

• このガイドは、Play 2.8 から Play 2.9 へのマイグレーションを対象としています。Play 2.8 マイグレーションガイド を参照して、Play 2.7 からアップグレードしてください。
• このマイグレーションガイドを完了し、アプリケーションを Play 3.0 （Pekko と Pekko HTTP 上に構築）に移行する場合は、Play 3.0 マイグレーションガイド を参照して、さらなる指示を確認してください。

§マイグレーション方法

sbt を開始する前に、以下のアップグレードを実行してください。

§Play のアップグレード

project/plugins.sbt で Play のバージョン番号を更新します。

addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.9.x")

2.9.x の「x」は使用する Play のマイナーバージョンです（例：2.9.0）。
Play のマイナーバージョンのリリースノートを確認してください。リリース.

§sbt のアップグレード

Play 2.9 は sbt 1.9 以降のみサポートしています。更新するには、project/build.properties を次のように変更します。

sbt.version=1.9.6

執筆時点では、1.9.6 が sbt 1.x 系の最新バージョンですが、それ以降のバージョンも使用できる場合があります。詳細については、sbt のリリースノートを確認してください。リリース.

§必要な Java と sbt の最小バージョン

Play 2.9 は Java 8 のサポートを終了し、Java 11 以上が必要です。他のサポートされている Java バージョンは 17 と 21 です。Play 2.9 にアップグレードする際には、少なくとも Java 17 LTS へのアップグレードを強くお勧めします。今後の Play 2.x リリース（バージョン 2.10）では、Java 11 のサポートを終了する可能性があることに注意してください。

Java 17 と Java 21 で自己署名証明書を使用して HTTPS ポートをバインドすると、問題が発生する可能性があることに注意してください。この問題の詳細については、"Java 17 と Java 21 で自己署名証明書の生成が失敗する" を参照してください。

§Jetty ALPN Agent の削除

Java 11 は Play 2.9 の必要な Java の最小バージョンであり、ALPN を標準でサポートしているため、Jetty ALPN Agent は厳密には不要になりました。
-javaagent:jetty-alpn-agent-*.jar フラグを Play アプリケーションに渡していた場合（おそらく SBT_OPTS 環境変数経由）、そのフラグを削除する必要があります。

§Akka と Akka HTTP のアップグレード

Akka 2.6 と Akka HTTP 10.2 を超えてアップグレードする場合は、Play Scala または Play Java の更新ガイドを参照してください。また、以下の内容についても確認することを強くお勧めします。

• Play が Akka のライセンス変更に対処する方法

§API の変更

Play 2.9 には、複数の API の変更が含まれています。通常どおり、削除する前に既存の API を非推奨とするポリシーに従っています。このセクションでは、これらの変更について詳しく説明します。

§Scala 2.12 のサポート終了

Play 2.9 は Scala 2.13 と Scala 3.3 をサポートしていますが、Scala 2.12 はサポートしていません。Scala 3 には、Scala 3 マイグレーションガイド に記載されている、さらにいくつかのマイグレーション手順が必要です。

§プロジェクトでの scalaVersion の設定

**Scala ユーザーと Java ユーザーの両方** は、サポートされている Scala バージョンを使用するように sbt を設定する必要があります。プロジェクトに Scala コードがない場合でも、Play 自体は Scala を使用しており、正しい Scala ライブラリを使用するように設定する必要があります。

sbt で Scala バージョンを設定するには、次のように scalaVersion キーを設定します。

scalaVersion := "2.13.13"

Play 2.9 は Scala 3 もサポートしています。

scalaVersion := "3.3.3"

Play は Scala LTS（長期サポート） バージョンのみを排他的にサポートしていることを強調することが重要です。その結果、Scala 3.3 LTS と次の LTS バージョンの間の Scala リリースは、Play によって公式にサポートされません。ただし、そのような Scala バージョンで Play を使用することは依然として可能かもしれません。

単一プロジェクトのビルドの場合、この設定は build.sbt に単独行で配置できます。ただし、複数プロジェクトのビルドの場合、scala バージョン設定は各プロジェクトで設定する必要があります。通常、複数プロジェクトのビルドでは、すべてのプロジェクトで共有される共通の設定があるため、設定を配置するのに最適な場所です。例：

def commonSettings = Seq(
  scalaVersion := "2.13.13"
)

val projectA = (project in file("projectA"))
  .enablePlugins(PlayJava)
  .settings(commonSettings)

val projectB = (project in file("projectB"))
  .enablePlugins(PlayJava)
  .settings(commonSettings)

§より一貫性のあるメソッド名への名前変更

特にデータの追加、削除、クリアを行うメソッドについて、さまざまな API 間で一貫性を高めるために、一部のクラスとメソッドの名前が変更されました。
スムーズなマイグレーションを可能にするために、古いメソッドは非推奨となり、将来のバージョンで削除されます。

トレイト play.api.i18n.MessagesApi で名前が変更されたメソッド

オブジェクト play.api.mvc.Results で名前が変更されたメソッド

play.api.libs.typedmap.TypedMap で名前が変更されたメソッド

以下のクラスの名前が変更されました

§非推奨 API の削除

以前のバージョンで非推奨とされた多くの API は、Play 2.9 で削除されました。まだそれらを使用している場合は、Play 2.9 にアップグレードする前に、新しい API に移行することをお勧めします。マイグレーションノートについては、Javadoc と Scaladoc を確認してください。Play 2.8 のマイグレーションガイド も参照してください。

§CSP レポートタイプの変更

w3.org の仕様 に従って、CSP レポートにいくつかの変更が加えられました。Play 2.9 以降、フィールド lineNumber と columnNumber は Long 型です。実装がこれらのフィールドを String 型として基づいている場合、Play は String から Long への解析にフォールバックし、解析に失敗した場合にのみエラーをスローします。ただし、CSP3 のリリース時には変更される可能性があるため、String 型ではなく数値型を使用することをお勧めします。

§Request.asJava は常に RequestBody でボディをラップするようになりました

asJava メソッドを使用して Scala リクエストを Java リクエストに変換する場合、結果の Java リクエストには常にボディが Http.RequestBody クラスでラップされるようになりました。この変更により、Play Java ではリクエストボディが常にこのクラスでラップされるため、一貫性が確保されます。

以前は、この変換がクリーンに実行されず、変換された Java リクエストに Http.RequestBody にラップされずに Scala リクエストボディが直接含まれている可能性がありました。

ただし、リクエストボディを RequestBody クラスでラップしても、Scala リクエストを Java リクエストに変換する際に、ボディ自体が自動的に Java の同等のものに変換されるわけではないことに注意することが重要です。たとえば、Scala リクエストに play.api.mvc.RawBuffer が含まれている場合、Java の同等のもの play.mvc.Http.RawBuffer に変換されません。同様に、Scala の AnyContentAsEmpty は java.util.Optional.empty() （空のボディの Play Java の同等物）に変換されません。その結果、request.asJava.body().asRaw()、.asJson() などのヘルパーメソッドは、期待どおりに動作しない可能性があります。

格納されている Play Scala ボディオブジェクトを取得するには、request.asJava.body().as(classOf[Object]) を使用できます。

§Java Persistence API から Jakarta Persistence API への移行

Hibernate ORM 6+ および EclipseLink 3+ を最終的にサポートするために、Play はJPA モジュールをJakarta Persistence APIに移行する必要がありました。コードを移行するには、まず、`build.sbt`内の`libraryDependencies`でHibernateまたはEclipseLinkをアップグレードする必要があります。次に、Javaファイルのインポートを次のように調整します。

変更前

import javax.persistence.*;

変更後

import jakarta.persistence.*;

さらに、以下のように`persistence.xml`を更新します。

変更前

<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
             version="2.1">
...

変更後

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="https://jakarta.ee/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence https://jakarta.ee/xml/ns/persistence/persistence_3_0.xsd"
             version="3.0">
...

さらに、プレフィックス`javax.persistence`を`jakarta.persistence`に置き換えることで、すべての構成パラメーターを更新します。例えば

変更前

<property name="javax.persistence.jdbc.driver" value="..."/>

変更後

<property name="jakarta.persistence.jdbc.driver" value="..."/>

さらに、報告によると、必要に応じて、HibernateがPlay 2.9で正しく動作するように、構成内のプロバイダーを以下のように変更する必要がある場合があります。

<provider>org.hibernate.ejb.HibernatePersistence</provider>

変更前

<provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>

これにより、HibernateがPlay 2.9で正しく動作するようになります。

`version="3.0"`および`persistence_3_0.xsd`が使用されていますが、このXML宣言は最新のJakarta Persistence 3.1で正しいものです。これは、Jakarta Persistence 3.1では`persistence.xml`スキーマに変更がないためです。重複を避けるため、バージョン更新には3.0スキーマが再利用されます。https://jakarta.ee/xml/ns/persistence/

§Play 2.9では現在JPA Bean Validationがサポートされていません

Bean Validationは現在Play 2.9でサポートされていないことに注意することが重要です。詳細については、こちらに記載されている詳細を参照してください。

§JNotify監視サービスは使用できなくなりました

play-file-watchからJNotifyFileWatchServiceが削除されたため、

play.dev.filewatch.FileWatchService.jnotify

はPlayKeys.fileWatchServiceの値として使用できなくなりました。

§PlayKeysからいくつかの設定が削除されました

設定`playOmnidoc`、`playDocsName`、`playDocsModule`、および`playDocsJar`はPlayKeysから削除されました。これらの設定は、Playドキュメントをローカルで実行することがかなり前から不可能になっているため、もはや使用されていません。

§名前空間の変更: org.fluentleniumからio.fluentleniumへ

FluentLeniumは名前空間をorg.fluentleniumからio.fluentleniumに移行しました。そのため、インポートを適宜更新する必要がある場合があります。

§構成の変更

このセクションでは、構成の変更と非推奨化について説明します。

§アプリケーションシークレットは最小長を強制します

アプリケーションシークレット構成`play.http.secret.key`は、すべてのモード（prod、dev、test）で最小長のチェックを強制するようになりました。最小長を満たしていない場合、エラーが発生し、構成が無効になり、アプリケーションの起動が阻止されます。

最小長は、セッションまたはフラッシュクッキーに署名するために使用されるアルゴリズムによって異なります。これは、configキー`play.http.session.jwt.signatureAlgorithm`および`play.http.flash.jwt.signatureAlgorithm`で設定できます。デフォルトでは、両方のconfigは`HS256`アルゴリズムを使用し、少なくとも256ビット（32バイト）のシークレットが必要です。`HS384`の場合は最小サイズが384ビット（48バイト）、`HS512`の場合は512ビット（64バイト）です。

このエラーが発生すると、解決策に関する詳細情報が表示されます。

Configuration error [
  The application secret is too short and does not have the recommended amount of entropy for algorithm HS256 defined at play.http.session.jwt.signatureAlgorithm.
  Current application secret bits: 248, minimal required bits for algorithm HS256: 256.
  To set the application secret, please read https://playframework.com/documentation/latest/ApplicationSecret
]

このエラーを解決するには、シークレットに必要なビット数/バイト数を含むようにします。たとえば、`head -c 32 /dev/urandom | base64`を使用して、少なくとも32バイトの完全にランダムな入力でシークレットを生成するか、`playGenerateSecret`または`playUpdateSecret`を使用してアプリケーションシークレットジェネレーターを使用できます。

§新しいLogback構成形式

バージョン1.3以降、Logbackは構成ファイルに新しい標準形式を使用します。Playは最新のLogbackバージョンにアップグレードされているため、Logback構成ファイルをこの新しい形式に更新する必要があります。Logbackチームが提供するオンライン翻訳ツールを使用すると簡単にこれを行うことができます。GitHubアカウントでログインし、既存のLogback構成をコピーして貼り付けて変換します。

従来の構成形式はまだ機能しますが、プロセスが簡単なので、今すぐアップグレードすることをお勧めします。

さらに、Play固有の`coloredLevel`コンバーターは非推奨となりました。Logbackはしばらくの間カラーリングのための組み込みパターンを提供しています。そのため、Logback構成ファイルから次の行を削除します。

<conversionRule conversionWord="coloredLevel" converterClass="play.api.libs.logback.ColoredLevel" />

代わりに、パターンで`%coloredLevel`を`%highlight(%-5level)`に置き換えます。

<!-- Deprecated: -->
<pattern>... %coloredLevel ...</pattern>

<!-- Recommended: -->
<pattern>... %highlight(%-5level) ...</pattern>

§play.akka.config設定が削除されました

アクタシステムをブートストラップすると、Akkaは提供された「ルート」構成内のハードコードされた`akka`プレフィックスから設定を検索します。この動作はAkkaに固有であり、Play固有のものではありません。

デフォルトでは、PlayはAkkaにアプリケーション構成ルートパスから直接アクタシステム設定を読み込むように指示します。したがって、通常は`application.conf`の`akka.*`名前空間の下でPlayのアクタシステムを構成します。

Play 2.9までは、`play.akka.config`構成を使用して、PlayがAkka設定を取得する代替の場所を指定することができました。これは、`akka.*`設定を別のアクタシステムに使用する予定がある場合に役立ちました。ただし、この構成は2つの主な理由で削除されました。

1. ドキュメントの不足：`play.akka.config`設定は十分に文書化されていませんでした。ドキュメントでは、`play.akka.config = "my-akka"`を設定した場合でも、構成ルートパスの`akka.*`設定がフォールバックとして読み込まれることは明確にされていませんでした。つまり、`akka.*`構成に加えられた変更は、`my-akka.akka.*`に定義されたアクタシステムにも影響します。結果として、これら2つのアクタシステムは独立して動作せず、`play.akka.config`によって暗示された約束（別のアクタシステムのために`akka.*`を排他的に使用できるようにする）は果たされませんでした。

2. 構成の期待：Playは、アクタシステム構成が`akka.*`名前空間内に存在し、シームレスな動作を確保するためにそのプレフィックス内にさまざまな構成を設定することを期待しています。Playのために完全に異なるアクタシステムを使用する場合、アプリケーションは正しく機能しなくなる可能性があります。

これらの考慮事項のため、Play 2.9以降、`akka.*`プレフィックスはPlayのAkka構成のみに指定され、変更できません。独自のActorシステムを実装できますが、ルートパスにあるPlayの`akka`プレフィックスから構成を読み込まないようにする必要があります。

§`akka.*`構成に直接定義されたディスパッチャは自動的にロードされなくなります

`play.akka.config`構成を削除した副作用として、`akka.*`構成キー内にディスパッチャを直接定義できなくなりました。デフォルトのアクタシステムによって自動的にロードされなくなります。代わりに、次のような例外が発生します。

play.api.http.HttpErrorHandlerExceptions$$anon$1: Execution exception[[ConfigurationException: Dispatcher [my-context] not configured]]
...
Caused by: akka.ConfigurationException: Dispatcher [my-context] not configured
...

今後は

• ディスパッチャを検索するときに`akka.*`プレフィックスを指定する（例：`lookup("akka.my-context")`）か、
• `my-context`ディスパッチャ構成を構成のルートに直接配置するか、
• ディスパッチャを別のサブキーに移動し、そこから検索する必要があります（例：構成`contexts.my-context { ... }`および`lookup("contexts.my-context")`）。

実際、Play 2.9以降の動作は正しいです。ディスパッチャは`akka.*`キーから自動的に読み取るべきではありません。これは、プレーンなAkkaアプリケーションでも機能しません。ディスパッチャを`akka.*`キーに配置できたのは、壊れた`play.akka.config`実装によるPlay固有の副作用に過ぎませんでした。

§デフォルト値の変更

Playで使用されるいくつかのデフォルト値が変更されたため、アプリケーションに影響を与える可能性があります。このセクションでは、これらのデフォルト値の変更について説明します。

§Java 17およびJava 21では自己署名証明書の生成が失敗します

HTTPSポートのバインド中に、Playは通常、デフォルトの手順として自己署名証明書を生成します。ただし、Java 17を使用する場合、この操作により次の例外が発生する可能性があります。

 java.lang.IllegalAccessError: class com.typesafe.sslconfig.ssl.FakeKeyStore$ (in unnamed module @0x68c8dd0e) cannot access class sun.security.x509.X509CertInfo (in module java.base) because module java.base does not export sun.security.x509 to unnamed module @0x68c8dd0e (FakeKeyStore.scala:89)
com.typesafe.sslconfig.ssl.FakeKeyStore$.createSelfSignedCertificate(FakeKeyStore.scala:89)
com.typesafe.sslconfig.ssl.FakeKeyStore$.generateKeyStore(FakeKeyStore.scala:79)
play.core.server.SelfSigned$.x$1$lzycompute(SelfSigned.scala:24)
play.core.server.SelfSigned$.x$1(SelfSigned.scala:23)
play.core.server.SelfSigned$.sslContext$lzycompute(SelfSigned.scala:23)
play.core.server.SelfSigned$.sslContext(SelfSigned.scala:23)
play.core.server.SelfSignedSSLEngineProvider.sslContext(SelfSigned.scala:36)
...

標準的なPlayアプリケーション設定でこの例外を回避するために、テストのHTTPSポートのバインドはデフォルト構成で無効化されました。テストでのHTTPSポートのアンバインドは以前の動作への復帰です。これは、以前のPlayバージョンで無効化された後に、誤って私たちによってHTTPSポートのバインドが有効化されたためです。

Playによって生成された自己署名証明書を使用してHTTPSポートに対してテストを実行したい場合は、Java 17では回避策が必要です。これには、Java 17コマンドラインに`--add-export`フラグを追加する必要があります。さらに、テスト実行中に新しいJava仮想マシン（JVM）インスタンスをフォークすることが重要です。

Test / javaOptions += "--add-exports=java.base/sun.security.x509=ALL-UNNAMED"
// Test / fork := true // This is the default behavior in Play; a reminder in case the setting was changed to false previously

または、`JAVA_TOOL_OPTIONS`環境変数を設定できます。

export JAVA_TOOL_OPTIONS="$JAVA_TOOL_OPTIONS --add-exports=java.base/sun.security.x509=ALL-UNNAMED";

残念ながら、上記の回避策はJava 21では十分ではありません。この場合、次の例外が発生する可能性があります。

 java.lang.NoSuchMethodError: 'void sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)' (FakeKeyStore.scala:92)
com.typesafe.sslconfig.ssl.FakeKeyStore$.createSelfSignedCertificate(FakeKeyStore.scala:92)
com.typesafe.sslconfig.ssl.FakeKeyStore$.generateKeyStore(FakeKeyStore.scala:79)
play.core.server.SelfSigned$.x$1$lzycompute(SelfSigned.scala:24)
play.core.server.SelfSigned$.x$1(SelfSigned.scala:23)
play.core.server.SelfSigned$.sslContext$lzycompute(SelfSigned.scala:23)
play.core.server.SelfSigned$.sslContext(SelfSigned.scala:23)
play.core.server.SelfSignedSSLEngineProvider.sslContext(SelfSigned.scala:36)
...

現時点では、Play内で自己署名証明書の生成にJava 21を使用することはできません。この目的のためにJava 17を引き続き使用することをお勧めします。この問題の解決状況は、次のGitHubリンクで監視できます。

通常、自己署名証明書はWebサイトを提供するためのものではありません。より包括的なHTTPS構成情報については、"HTTPSの構成"または"本番環境でのPlayの使用"を参照してください。

§AnyContentボディパーサーの空のボディの処理における変更

Play Scalaの`parse.anyContent`やPlay Javaの`@BodyParser.Of(BodyParser.AnyContent.class)`など、`AnyContent`ボディパーサーを使用している場合、ボディパース処理で空のボディが生成された場合の動作が更新されたことに注意することが重要です。Play Scalaでは、リクエストボディは`AnyContentAsEmpty`に割り当てられ、Play Javaでは`Optional.empty()`に設定されます。
以前は、空のボディは`Content-Type`ヘッダーに基づいて特定の「空」タイプに関連付けられていました。たとえば、Playが空のボディをrawバッファーとしてパースした場合、リクエストにはサイズがゼロの`RawBuffer`オブジェクトが含まれていました。

§正しくないパーセントエンコードされたURI文字の処理

akka-http 10.2.0以降、正しくないパーセントエンコードされたURI文字は、akka-httpによってすぐに400 bad requestとして処理されます。この動作では、Playがエラーを処理する機会がありません。両方のHTTPバックエンド間の互換性を確保するために、nettyを同じように動作させました。正しくないパーセントエンコードされた文字をパースするときにエラーハンドラを通過しません。このアプローチは、一方のバックエンドが他方のバックエンドに置き換えられた場合の互換性を最大限に高めることを目的としています。

§Caffeineには、`play.cache.caffeine.defaults.maximum-size`によって定義された新しいデフォルト値があります。

アプリケーションが時間の経過とともに多くのアイテムをキャッシュに追加する場合、Caffeineベースのキャッシュを使用すると、最終的に`OutOfMemory`エラーが発生し、JVMがクラッシュする可能性があります。Caffeine構成のプロジェクトのデフォルト値として、最大サイズを10,000に定義しています。

§CaffeineはPlayのデフォルトディスパッチャを内部的に使用するようになりました

Caffeineによって内部的に使用されるディスパッチャは、Playのデフォルトディスパッチャになりました。Play 2.9.0以前は、Javaの共通プール（ForkJoinPool.commonPool()）が使用されていました。
play.cache.dispatcherの設定を使用して、使用するディスパッチャを変更したり、ScalaキャッシュAPIとJavaキャッシュAPIで説明されているように、異なるキャッシュに対して異なるexecutorを設定することもできます。

§テストサーバーはランダムポートを使用するようになりました

Play Java、Play Scala specs2、またはScalaTest + Playを使用して機能テストを作成する場合、テストサーバーの実行ポートを明示的に指定しない場合、以前のデフォルトのポート19001ではなく、ランダムポートが使用されるようになりました。この変更は、並列テストの実行を容易にするためのものです。明示的なポートを指定する代わりに、システムプロパティtestserver.port（例：以前の動作を有効にするには19001）を設定することもできます。

ランダムポートを使用する場合は、テストで正しいポートを取得することが重要です。running(TestServer(...))(block(..))を使用する代わりに、新しく導入されたメソッドrunningWithPort(TestServer(...))(port => block(..))を使用できます。このメソッドは、実際に使用されたポートをパラメータとして提供します。

§テストサーバーはデフォルトでHTTPSポートをバインドしなくなりました

新しいランダムポートの動作について説明した前のセクションに加えて、テストサーバーはデフォルトでHTTPSポートをバインドしなくなりました。ただし、システムプロパティtestserver.httpsportを渡すことで、この動作を再度有効にできます。HTTPSポートがバインドされている場合、自己署名証明書が使用されます。

§依存関係グラフの変更

play-jdbc-apiアーティファクトは、playコアアーティファクトに依存しなくなりました。

§ライブラリの更新

Play 2.9では、以下の独自のライブラリがアップグレードされました。

独自のライブラリの新しいバージョンへの更新に加えて、多くの重要なサードパーティの依存関係も最新のバージョンに更新されました。

§groupIdの変更

Playのすべてのアーティファクトとライブラリは、com.typesafe.play名前空間で公開されるようになりました。そのため、以下のライブラリに調整を加える必要がありました。

§アーティファクト名の変更

すべてのアーティファクトで一貫性のある命名（各名がplay-で始まる）を確保するために、残りのartifactIdに調整を加えました。

§削除されたライブラリ

Playから以下の依存関係が削除されました。

• "org.scala-lang.modules" %% "scala-java8-compat"
  Play 2.9でScala 2.12のサポートが削除されたため、この依存関係をプルインする必要がなくなりました。代わりに、Scala 2.13の標準ライブラリに追加されたscala.jdkの下にあるクラスを使用してください。

• "jakarta.xml.bind" % "jakarta.xml.bind-api"
  アップグレードされたJJWT依存関係では、JAXBは使用されなくなりました。

• "org.mortbay.jetty.alpn" % "jetty-alpn-agent"
  および
  "com.lightbend.sbt" % "sbt-javaagent"
  Play 2.9の最小必須JavaバージョンはJava 11であり、ALPNを標準でサポートしているため、これらの依存関係は不要になりました。

• "jakarta.transaction" % "jakarta.transaction-api"
  役に立たず、今までは見過ごされていたようです。

次へ: Scala 3移行ガイド

このドキュメントにエラーを見つけましたか？このページのソースコードはこちらにあります。ドキュメントガイドラインを読んだ後、プルリクエストを送信して自由に貢献してください。質問やアドバイスを共有したいですか？コミュニティフォーラムにアクセスして、コミュニティとの会話を開始してください。