Skip to content

GROOVY-11680: Java stubs use deprecated constant constructors in some… #2235

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 28, 2025

Conversation

paulk-asert
Copy link
Contributor

… cases

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR addresses GROOVY-11680 by removing usage of deprecated constant constructors in Java stub generation. Key changes include:

  • Updating tests in Groovy11019.groovy to expect string constants as null.
  • Adjusting test expectations and adding a new dynamic string constant in Groovy10902.groovy.
  • Revising JavaStubGenerator.java to generate stub values via valueOf() for primitives while defaulting strings to null.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
src/test/groovy/org/codehaus/groovy/tools/stubgenerator/Groovy11019.groovy Updated expected stub for a static string constant
src/test/groovy/org/codehaus/groovy/tools/stubgenerator/Groovy10902.groovy Updated expected stub for an Integer constant, added dynamic string constant test
src/test/groovy/org/codehaus/groovy/tools/stubgenerator/ClassWithPrimitiveFieldsStubTest.groovy Added tests for default initializations of various primitive fields
src/main/java/org/codehaus/groovy/tools/javac/JavaStubGenerator.java Modified generation of constant values for primitives and strings

@paulk-asert
Copy link
Contributor Author

@eric-milles I removed the special handling for String constants and it didn't seem to have any negative consequences. I'd be interested in your thoughts since you have done a few recent changes in this area.

@codecov-commenter
Copy link

codecov-commenter commented May 26, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.0406%. Comparing base (d7afb87) to head (76e452e).
Report is 8 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

@@                Coverage Diff                 @@
##               master      #2235        +/-   ##
==================================================
- Coverage     69.0430%   69.0406%   -0.0024%     
- Complexity      29704      29705         +1     
==================================================
  Files            1423       1423                
  Lines          114404     114421        +17     
  Branches        19852      19855         +3     
==================================================
+ Hits            78988      78997         +9     
- Misses          28781      28786         +5     
- Partials         6635       6638         +3     
Files with missing lines Coverage Δ
...codehaus/groovy/tools/javac/JavaStubGenerator.java 86.2481% <100.0000%> (ø)

... and 8 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@eric-milles
Copy link
Member

The constructors are indeed deprecated, but are they scheduled for removal? Was this a concern for someone? As long as you generate something that javac accepts but does not inline, then I guess it's fine. I'd prefer it stays simple. No need to be overly complicated just for the sake of stubs.

@paulk-asert
Copy link
Contributor Author

The Grails build messages are cluttered with many of these:

/Users/paulk/working/grails-core/grails-gradle/model/build/tmp/compileGroovy/groovy-java-stubs/grails/util/BuildSettings.java:53: warning: [removal] Boolean(boolean) in Boolean has been deprecated and marked for removal
public static final boolean GRAILS_APP_DIR_PRESENT = new java.lang.Boolean(false);
^

So, at least the Boolean constructor is marked for removal.

@daniellansun
Copy link
Contributor

No good deed is too small to do; no evil deed is too small to avoid.

@eric-milles
Copy link
Member

If there is a valueOf method for each of the wrapper types and String, then that should be the only change. So your example would appear as public static final boolean GRAILS_APP_DIR_PRESENT = java.lang.Boolean.valueOf(false); afterwards. Qualifier is there in case of strange imports. The string case may need a cast to object, since there is no valueOf(String) method.

@eric-milles
Copy link
Member

Can you include the grails build log notes in the JIRA ticket?

printValue(out, type, defaultValueX(type));
out.print(')');
} else if (isStringType(type)) {
out.print("new String()");
Copy link
Member

Choose a reason for hiding this comment

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

I'd keep the qualifier. Although, a valueOf expression would not be that difficult to produce.

@eric-milles
Copy link
Member

change looks fine now

@paulk-asert paulk-asert merged commit f229a1b into apache:master May 28, 2025
21 checks passed
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.

4 participants