OptionalNotPresentToIsEmpty rewrites `!isPresent()` on a non-`java.util.Optional` type, producing uncompilable `isEmpty()`

[sergeykad]

What version of OpenRewrite are you using?

• Gradle plugin org.openrewrite:plugin v7.35.0
• rewrite-migrate-java v3.38.0
• Active recipe: org.openrewrite.java.migrate.UpgradeToJava21 (which pulls in org.openrewrite.java.migrate.util.OptionalNotPresentToIsEmpty)

How are you running OpenRewrite?

Gradle plugin, applied via an init script over a large multi-module project:

rootProject {
    plugins.apply(org.openrewrite.gradle.RewritePlugin)
    dependencies {
        rewrite("org.openrewrite.recipe:rewrite-migrate-java:3.38.0")
    }
    rewrite {
        activeRecipe("org.openrewrite.java.migrate.UpgradeToJava21")
        setExportDatatables(true)
    }
}

The affected module depends on Jolt (com.bazaarvoice.jolt:jolt-core:0.1.8), which ships its own
com.bazaarvoice.jolt.common.Optional<T>. That class exposes isPresent() and get() but has no
isEmpty() method (its full public API is empty(), of(T), get(), isPresent(), equals, toString).

The project is private, but the third-party type is public and small; the relevant snippet is below.

What is the smallest, simplest way to reproduce the problem?

The receiver is a Jolt Optional, not a JDK Optional:

import com.bazaarvoice.jolt.common.Optional; // NOT java.util.Optional

class ConvertMarkdownToHtmlRTL {
    Optional<Object> applySingle(Object input) {
        Optional<Object> baseHtmlOpt = convert(input);
        if (!baseHtmlOpt.isPresent()) {   // original, compiles fine
            return Optional.empty();
        }
        // ...
    }
}

What did you expect to see?

The code left unchanged. baseHtmlOpt is a com.bazaarvoice.jolt.common.Optional, not a
java.util.Optional, so the recipe should not apply. The recipe's MethodMatcher is in fact scoped to the
JDK type — new MethodMatcher("java.util.Optional isPresent()") with template
#{any(java.util.Optional)}.isEmpty()
(OptionalNotPresentToIsEmpty.java, lines 46 and 56 on v3.38.0) — so the intent is clearly JDK-only.

What did you see instead?

The recipe rewrote it to call isEmpty() on the Jolt type, which does not have that method, so the module
no longer compiles:

import com.bazaarvoice.jolt.common.Optional;

class ConvertMarkdownToHtmlRTL {
    Optional<Object> applySingle(Object input) {
        Optional<Object> baseHtmlOpt = convert(input);
        if (baseHtmlOpt.isEmpty()) {   // does not compile: no isEmpty() on com.bazaarvoice.jolt.common.Optional
            return Optional.empty();
        }
        // ...
    }
}

Because the JDK-scoped MethodMatcher nevertheless matched a com.bazaarvoice.jolt.common.Optional
receiver, this looks like the matcher firing when the receiver's type is unresolved/incompletely attributed
(the third-party Optional not being on the recipe's typed classpath), falling through to a name-only match
on isPresent(). A type-scoped migration recipe should not rewrite when it cannot positively confirm the
receiver is java.util.Optional — otherwise it silently emits uncompilable code with no warning or error from
the run itself.

• Note this is a distinct failure mode from ClassCastException in OptionalNotEmptyToIsPresent #417/ClassCastException in OptionalNotEmptyToIsPresent #418 (a ClassCastException thrown by the sibling
  OptionalNotEmptyToIsPresent); here there is no crash — the recipe completes "successfully" and the breakage
  only surfaces at the next compileJava.

What is the full stack trace of any errors you encountered?

No stack trace — the recipe run completes without error. The failure is a downstream Java compile error:

error: cannot find symbol
        if (baseHtmlOpt.isEmpty()) {
                       ^
  symbol:   method isEmpty()
  location: variable baseHtmlOpt of type com.bazaarvoice.jolt.common.Optional<Object>

Are you interested in contributing a fix to OpenRewrite?

Open to it if you can point me at the preferred guard (e.g. requiring resolved receiver type before applying). Happy to add a recipe test that reproduces the mis-fire on a non-JDK Optional.

[timtebeek]

hi! Explored this for a bit on our end; the underlying issue will be with type information not being set correctly when we parse your project. I noticed your plugin configuration differs from what we typically recommend, and I can't see how your jolt-core dependency is placed on the classpath; can you provide those details?

The reason I ask is that in my reproducer attempts javac is already confused by the absence of the type, meaning we take over the misattributed type information, leading to the recipe mismatches. Ideally that's fixed at the root, starting with how the plugin classpath is configured.

[sergeykad]

The init script is actually the recommended option for this recipe — it's right on the UpgradeToJava21 docs page alongside the plugin/Maven/CLI variants, and ours is near-verbatim (same plugin:7.35.0, rewrite-migrate-java:3.38.0, setExportDatatables(true)). It's a ~300-module monorepo, so a single root init script is the only practical way — per-project application isn't on the table.

jolt-core is a normally-declared dependency of the affected module: implementation 'com.bazaarvoice.jolt:jolt-core' in jolt-transformers/build.gradle, with the version (0.1.8) supplied by a constraints {} block in the root build. So it's on that module's compileClasspath via standard Gradle resolution — nothing unusual for the parser to choke on.

If root-level application means rewrite isn't picking up each subproject's compile classpath, that seems like the thing to fix, since the docs present root init-script application as a supported path. And independently: when the receiver type can't be resolved, would it make sense for the recipe to skip rather than fall through to a name-only isPresent() match? Right now an unresolved type silently yields uncompilable isEmpty(), which is a quiet failure across a large run.

[timtebeek]

Hi; let me reiterate: for some reason the Java compiler already hands us the incorrect type information here. That's indeed the thing to fix here, but it's not clear cut why or how. I'd hoped to spot some odd configuration on your end, but that seems fairly normal still.