BiDi Java を使用するようにインポートを更新
カテゴリ
コードベースのどの部分が影響を受けますか？
Java バインディングの Selenium WebDriver BiDi API が影響を受けます。
破壊的変更によって何が影響を受けますか？
WebDriver BiDi API は変更されないため、引き続き使用できます。ただし、インポート文を更新する必要があります。
破壊的変更とは何ですか？
BiDi API を使用する場合は、インポート文を更新する必要があります。
Selenium 4.19 より前
import org.openqa.selenium.bidi.LogInspector;
import org.openqa.selenium.bidi.BrowsingContextInspector;
import org.openqa.selenium.bidi.Input;
import org.openqa.selenium.bidi.Script;
import org.openqa.selenium.bidi.Network;Selenium 4.19 以降
import org.openqa.selenium.bidi.module.LogInspector;
import org.openqa.selenium.bidi.module.BrowsingContextInspector;
import org.openqa.selenium.bidi.module.Input;
import org.openqa.selenium.bidi.module.Script;
import org.openqa.selenium.bidi.module.Network;なぜ破壊的変更が必要なのですか？
Selenium は、W3C BiDi の実装に積極的に取り組んでいます。W3C BiDi の長期的な目標は、すべての W3C WebDriver Classic API を WebDriver BiDi API を使用するように移植することです。browsingContext.locateNodes コマンド（findElements コマンドの BiDi 対応版）が導入された際、主な目標は、'locateNodes' コマンドが WebElement を返すようにすることでした。これにより、将来の移植がスムーズになり、ユーザーは引き続き WebElement の API を呼び出すことができます。
実装中に、基盤となるビルドツールである Bazel で循環依存が発生しました。この解決策は、Bazel のベストプラクティスに従うことでした。
そこで、モジュールの W3C BiDi 関連クラスは、Bazel パッケージにグループ化されました。コマンドまたはイベント自体を呼び出すクラスはすべて、「module」という名前のパッケージにグループ化されました。このように、推奨されるプラクティスに従い、Bazel の循環依存を回避することが、双方にとって有益な解決策であることが証明されました。
まとめ
W3C BiDi プロトコルは開発中であり、並行してブラウザとクライアントが補完的な API の追加に取り組んでいます。Selenium が実装に取り組む一方で、プロトコルは常に変化しており、新しいモジュールや API が追加または既存のものが更新されています。チームは破壊的変更を避け、削除前に少なくとも 2 バージョンは API を非推奨にすることを努めていますが、このブログ記事で説明されているような一部の変更については、これを遵守することが難しい場合があります。
