Selenium 4.51 Changes Java ExpectedCondition Compatibility

If you maintain a Java Selenium test suite, upgrading to Selenium 4.51 may expose a compile error even when your browser tests have not changed. The reason is a small but important change to ExpectedCondition: Selenium has removed its dependency on Guava's Function interface.

Most Selenium users will not notice the change. Code that passes an expected condition directly to WebDriverWait.until() continues to work. The problem appears in projects that explicitly use com.google.common.base.Function as the type of an expected condition.

Selenium 4.51, released on October 9, 2026, removes Guava from the Java client bindings. The change reduces a dependency that has been part of Selenium for years and avoids potential conflicts with the Guava version used by an application.

If your test framework uses custom wait utilities, shared helper classes, or method parameters typed as Guava's Function, it is worth checking the code before upgrading.

What Is ExpectedCondition in Selenium?

ExpectedCondition is part of Selenium's Java support API. It describes a condition that Selenium checks repeatedly until the condition succeeds or the wait times out.

This is useful because web pages rarely finish every operation at the same time. A button may appear after an API request, a loading indicator may disappear after rendering, or a result message may become visible after a form submission.

A fixed delay is not a reliable way to handle these situations. An explicit wait checks for the condition you actually need.

For example:

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

import java.time.Duration;

public class LoginTest {
    public static void main(String[] args) {
        WebDriver driver = new ChromeDriver();

        try {
            driver.get("https://example.com/login");

            WebDriverWait wait = new WebDriverWait(
                driver,
                Duration.ofSeconds(10)
            );

            WebElement loginButton = wait.until(
                ExpectedConditions.elementToBeClickable(
                    By.id("login-button")
                )
            );

            loginButton.click();
        } finally {
            driver.quit();
        }
    }
}

The important line is wait.until(...). Selenium repeatedly evaluates the expected condition until the login button is clickable or the timeout expires.

This normal use of ExpectedConditions does not depend on Guava's Function interface. It continues to work with Selenium 4.51.

What Changed in Selenium 4.51?

Before Selenium 4.51, Java's ExpectedCondition extended two interfaces:

com.google.common.base.Function, from Guava.
java.util.function.Function, included in the Java standard library.

Both interfaces represent a function that accepts an input and returns a result. Having both in the public API allowed older code to treat an expected condition as a Guava function.

Selenium 4.51 removes the Guava interface from ExpectedCondition. It now uses the standard Java Function interface.

Before Selenium 4.51	Selenium 4.51
`ExpectedCondition` extends Guava's `Function`	Guava's `Function` is no longer inherited
Also extends Java's `Function`	Continues to extend Java's `Function`
Code may assign conditions to Guava-typed variables	Such assignments need to use a compatible Java type
Selenium's Java client bindings depend on Guava for this API	This API no longer requires Guava

The change does not remove ExpectedCondition or the ExpectedConditions helper methods. It changes the interface that ExpectedCondition implements.

That distinction matters when reviewing existing test frameworks. You do not need to rewrite every explicit wait. You need to update code that depends on the old Guava type relationship.

Which Java Selenium Code Will Break?

Consider this example:

import com.google.common.base.Function;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;

public class WaitHelper {
    public static Function<WebDriver, WebElement> clickableButton() {
        return ExpectedConditions.elementToBeClickable(
            By.id("submit")
        );
    }
}

The method declares its return type as Guava's Function. Before Selenium 4.51, the returned expected condition could be assigned to that type because ExpectedCondition implemented the Guava interface.

With Selenium 4.51, the assignment no longer compiles. The returned condition is not a Guava function.

This issue can appear in more places than a return statement. Check for:

Variables declared as Guava's Function.
Fields that store expected conditions.
Method parameters that accept Guava functions.
Shared utility methods that return Guava functions.
Collections or generic types that expect Guava's Function.

The key question is whether your code relies on ExpectedCondition being assignable to com.google.common.base.Function.

How to Fix the Compatibility Issue

The recommended fix is to replace the Guava type with Java's built-in Function, or use Selenium's ExpectedCondition directly when the code represents a Selenium wait condition.

Option 1: Replace Guava Function with Java Function

The smallest change is to update the import and type declaration.

Before:

import com.google.common.base.Function;

Function<WebDriver, WebElement> condition =
    ExpectedConditions.elementToBeClickable(
        By.id("submit")
    );

After:

import java.util.function.Function;

Function<WebDriver, WebElement> condition =
    ExpectedConditions.elementToBeClickable(
        By.id("submit")
    );

The standard Java interface has the same apply method signature for this use. In ordinary cases, replacing the Guava type with java.util.function.Function is a direct migration.

This is a good option when the helper is meant to accept any function that takes a WebDriver and returns a WebElement, rather than a Selenium-specific condition.

Option 2: Use ExpectedCondition Directly

If the variable represents a Selenium wait condition, declaring it as ExpectedCondition is often clearer.

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedCondition;
import org.openqa.selenium.support.ui.ExpectedConditions;

ExpectedCondition<WebElement> condition =
    ExpectedConditions.elementToBeClickable(
        By.id("submit")
    );

This type expresses the intent more clearly. It tells the next developer that the value is a condition intended for Selenium's waiting API.

You can then pass it directly to WebDriverWait.until():

WebDriverWait wait = new WebDriverWait(
    driver,
    Duration.ofSeconds(10)
);

WebElement button = wait.until(condition);

For most Selenium-specific helper classes, this is the option I would choose.

Option 3: Let Java Infer the Type

You may not need an explicit variable type at all.

WebElement button = wait.until(
    ExpectedConditions.elementToBeClickable(
        By.id("submit")
    )
);

This is the simplest form when the condition is used only once. It avoids coupling your code to either function interface.

How to Find Affected Code Before Upgrading

Start by searching the Java source files for Guava's function interface.

On Linux or macOS, run:

grep -rn "com.google.common.base.Function" \
  --include="*.java" .

This command finds explicit references to the Guava type. It is a useful first pass, but it does not prove that every match is affected. Your project may use Guava functions for unrelated code.

Review each match and check whether it is used with Selenium's ExpectedCondition or ExpectedConditions.

For a large Maven project, also search helper modules and test-framework libraries. The problematic declaration might live in a shared library rather than in the individual test classes.

After making the changes, compile the project against Selenium 4.51 before running the full browser test suite.

Does Selenium 4.51 Remove Guava Completely?

Selenium's Java client bindings no longer depend on Guava as part of this change. That does not mean Guava must disappear from every application that uses Selenium.

Your own application or another library may still require Guava. If so, you can continue using it for those purposes.

The important difference is that Selenium's ExpectedCondition no longer promises to be a Guava Function. Do not keep an old Guava dependency just to preserve that particular assignment.

Review your dependency tree if you want to understand why Guava is still present in your application after upgrading. It may be coming from another dependency.

Advantages and Disadvantages

Advantages

Fewer dependency conflicts: Removing Guava from the Selenium client bindings reduces the chance of version conflicts caused by Selenium's own dependency.
Uses standard Java APIs: Developers can rely on java.util.function.Function instead of a third-party interface for this purpose.
Clearer types: Using ExpectedCondition directly makes Selenium wait logic easier to recognize.
No broad rewrite required: Standard explicit waits and expected-condition lambdas continue to work.

Disadvantages

Some code will not compile: Helpers that explicitly use Guava's Function need to be updated.
Shared libraries may be affected: A common test framework can cause compile failures across several test modules.
Dependency cleanup needs review: Guava may still be required by other libraries, so removing it blindly can break unrelated code.

Common Migration Mistakes

Changing every Guava import without checking its use. Guava remains a valid library for applications that need it. Change the types that depend on the old Selenium interface relationship, not unrelated code.

Assuming all ExpectedCondition usage is broken. Calls to ExpectedConditions passed directly to wait.until() are not affected by this change.

Removing Guava from the entire project immediately. First check whether your application or another dependency still uses it.

Skipping compilation after changing the dependency version. A clean compile is the quickest way to catch incompatible type declarations before browser tests run.

Best Practices for Selenium Java Projects

Keep Selenium wait helpers typed as ExpectedCondition<T> when they represent browser conditions. Use Java's Function<T, R> when the helper is intended to be a general-purpose function.

Keep Selenium versions consistent across test modules. If you have a shared automation library, compile it against the target Selenium version before upgrading every test project.

Finally, run the tests that exercise shared wait utilities, not just a single login test. A type mismatch can hide in a helper that only a few test suites use.

Conclusion

Selenium 4.51 changes the Java ExpectedCondition interface by removing its relationship with Guava's Function. Most Selenium test code remains unchanged, but explicit Guava-typed variables, fields, parameters, and return types may fail to compile.

Search your code for com.google.common.base.Function, review the matches that involve Selenium expected conditions, and replace those types with java.util.function.Function or ExpectedCondition<T> as appropriate.

That small migration will let your test suite use Selenium 4.51 without relying on the old Guava interface compatibility.