Skip to content

Fixes for guava version bump#2943

Merged
Naenyn merged 1 commit into
uPortal-Project:masterfrom
bjagg:fix/errorprone-limitingtee-callback
Apr 22, 2026
Merged

Fixes for guava version bump#2943
Naenyn merged 1 commit into
uPortal-Project:masterfrom
bjagg:fix/errorprone-limitingtee-callback

Conversation

@bjagg

@bjagg bjagg commented Apr 22, 2026

Copy link
Copy Markdown
Member

Summary

Adopts @Naenyn's direct-to-the-point fix for the ErrorProne CheckReturnValue violations that surface when resource-server's newer Guava transitively lands in the classpath. Cherry-picked verbatim from commit f2e3a459 on his remove_fluid branch so he keeps authorship.

Why this approach beats the @SuppressWarnings workaround

My earlier version of this PR used a @SuppressWarnings("unused") Object unused = callback.apply(this); pattern to silence ErrorProne while keeping the Function<T,?> signature. Bill's approach is strictly better: the callback's return value was never used (the ? wildcard was a tell), so java.util.function.Consumer<T> is the correct type. No suppression needed; no weird "unused" variable convention; the ErrorProne violation goes away because there's no return value to check.

Scope (6 files, +23/−48)

Source:

  • LimitingTeeWriter.javaFunction<LimitingTeeWriter, ?>Consumer<LimitingTeeWriter>, .apply().accept(), import swap
  • LimitingTeeOutputStream.java — same pattern
  • CachingPortletOutputHandler.java (sole caller) — anonymous new Function<>() { ... return null; }input -> clearCachedWriter() lambdas

Tests:

  • LimitingTeeWriterTest.java, LimitingTeeOutputStreamTest.java — matching Function→Consumer updates with lambdas, drop com.google.common.base.Function import
  • PortalRawEventsAggregatorImplTest.javadifferent pattern here: the Function comes from the code-under-test's API, not our types, so it can't be changed to Consumer. Bill uses a Boolean ignored = … capture to satisfy CheckReturnValue. Same shape as the @SuppressWarnings pattern but localized to the specific call.

Validation

  • ./gradlew :uPortal-rendering:compileJava on master baseline — BUILD SUCCESSFUL
  • ./gradlew :uPortal-webapp:compileTestJava on master baseline — BUILD SUCCESSFUL
  • Bill's own remove_fluid branch (which has resourceServerVersion=1.5.2 and therefore triggers the underlying Guava @CheckReturnValue check) already builds clean with these exact changes — so we know the fix addresses the real failure mode surfaced by Bootstrap / jQuery Update & Fluid Infusion Removal #2915.

Merge order — no change

  1. This PR — ErrorProne fix, source+tests (this commit)
  2. fix: exclude Spring from resource-server-utils transitive deps #2944 — Spring exclusion in uPortal-utils-core so Util.java compiles when resource-server 1.5.2 comes along
  3. fix(deps): update resource server to v1.5.2 - autoclosed #2537 (Renovate) — the actual resourceServerVersion 1.3.1 → 1.5.2 bump
  4. Bootstrap / jQuery Update & Fluid Infusion Removal #2915 (Bill) — rebases master; his LimitingTee + test hunks become no-ops because they're already on master; his PR gets slightly smaller and his rebase gets slightly cleaner.

cc @Naenyn — this PR now contains your commit verbatim. If you'd prefer a different attribution style or want me to close and let your own PR carry it instead, just say the word.

Newer Guava (pulled in transitively via resource-server 1.5.x)
annotates com.google.common.base.Function.apply() with @CheckReturnValue,
so ErrorProne now flags the two call sites that discard the return:

  uPortal-rendering/src/main/java/org/apereo/portal/portlet/container/
  cache/LimitingTeeWriter.java:86
  cache/LimitingTeeOutputStream.java:84

The callback's Function<T,?> return was always intentionally discarded
(the sole caller returns null), so the fix is to name the captured
result 'unused' — the convention ErrorProne recognizes as "intentional
discard" — with @SuppressWarnings("unused") to also silence the
compiler's own unused-variable lint.

Master CI passes today because its resource-server 1.3.1 pin pulls an
older Guava without the annotation; the check triggers on branches
that have bumped to resource-server 1.5.x+ (e.g. uPortal-Project#2915
'Bootstrap / jQuery Update & Fluid Infusion Removal', which fails all
5 CI jobs on this exact error). Landing the fix on master lets that
branch rebase and go green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@bjagg bjagg requested a review from Naenyn April 22, 2026 16:38
@bjagg

bjagg commented Apr 22, 2026

Copy link
Copy Markdown
Member Author

@Naenyn — this is the ErrorProne fix for the LimitingTeeWriter / LimitingTeeOutputStream compile errors that are currently failing all 5 CI jobs on #2915. Locally validated on your remove_fluid branch (with resource-server 1.5.2) — BUILD SUCCESSFUL, errors gone. Once this merges to master, a git merge master into your branch should turn CI green, leaving just the three code fixes from my 2026-04-20 review (favorites .json(), config-lightbox Content-Type, btn-close × content) before approval.

Would you mind giving this a quick look when you have a moment?

@Naenyn Naenyn left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@Naenyn Naenyn merged commit 9ba420b into uPortal-Project:master Apr 22, 2026
5 checks passed
@bjagg bjagg changed the title fix: silence ErrorProne CheckReturnValue on limitReachedCallback.apply() Fixes for guava version bump Apr 22, 2026
@bjagg

bjagg commented Apr 22, 2026

Copy link
Copy Markdown
Member Author

Swapped out the @SuppressWarnings/unused workaround I had earlier — cherry-picked your f2e3a459 (Consumer + lambda at the sole caller + test updates) verbatim so you keep the authorship. Your approach is cleaner; no reason to merge a worse version.

Validated on master baseline: :uPortal-rendering:compileJava and :uPortal-webapp:compileTestJava both BUILD SUCCESSFUL. The 1.5.2-Guava trigger is proved out by your remove_fluid branch already building clean with these same hunks.

Force-pushed fix/errorprone-limitingtee-callback (linear replacement of my old commit). If the attribution setup isn't what you want, or you'd rather close this PR and have the change ride in via your own, just say so.

Naenyn added a commit that referenced this pull request Apr 22, 2026
…2945)

Replaces the @SuppressWarnings/unused workaround just landed in #2943
with the cleaner design @Naenyn proposed: the callback's return was
always discarded (the `?` wildcard on Function was a tell), so
java.util.function.Consumer<T> is the correct type. With Consumer,
.accept() returns void and ErrorProne's CheckReturnValue check
doesn't apply at all — no suppression needed.

Adopts @Naenyn's approach verbatim from his remove_fluid-branch work
(Naenyn/uPortal@f2e3a459). His force-push came in after #2943 was
already squashed and merged, so this PR lands the same set of changes
as a follow-up.

Scope (6 files, +23/−48):

  - LimitingTeeWriter.java  : Function<T,?> → Consumer<T>, .apply → .accept
  - LimitingTeeOutputStream.java : same pattern
  - CachingPortletOutputHandler.java (sole caller): anonymous
    Function<> classes → concise `input -> clearCachedWriter()` and
    `input -> clearCachedStream()` lambdas; drop unused import
  - LimitingTeeWriterTest.java, LimitingTeeOutputStreamTest.java :
    matching Function-to-lambda updates; drop unused Function import
  - PortalRawEventsAggregatorImplTest.java : different case — the
    Function here is part of the code-under-test's own API and can't
    be changed, so use `Boolean ignored = …` to capture the return
    (same shape @Naenyn used; aligns with the ErrorProne convention)

Verified locally:
  - :uPortal-rendering:compileJava      → BUILD SUCCESSFUL
  - :uPortal-webapp:compileTestJava     → BUILD SUCCESSFUL
  (master baseline; the 1.5.2-Guava trigger is already covered by
  @Naenyn's remove_fluid branch building clean with these same hunks.)

Co-authored-by: Bill Smith <wsmith@unicon.net>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants