Skip to content

Conversation

@dwalluck
Copy link
Contributor

Update all dependencies to the latest version and use properties for all versions for easy updating.

pom.xml Outdated
<configuration>
<compilerId>javac-with-errorprone</compilerId>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
<forceLegacyJavacApi>true</forceLegacyJavacApi>
Copy link
Contributor

Choose a reason for hiding this comment

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

I assume this is the configuration of JDK 9+. Why is this option required?

Also, why is plexus-compiler-javac-errorprone required below? Error Prone works very well alone on JDK 9+.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried removing it, and it apparently still is, even with JDK 9+.

Copy link
Contributor

@ppkarwasz ppkarwasz Mar 4, 2025

Choose a reason for hiding this comment

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

Debugging this a little bit: if forceLegacyJavacApi is set to false, the javac-with-errorprone compiler is equivalent to javac. As a result Error Prone does not run and no Error Prone warnings appear.

To run Error Prone you need to set forceLegacyJavaApi to false and add additional parameters to the JVM used by the compiler:

--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED

These options can be passed:

  1. To the main Maven process by adding them to the .mvn/jvm.config file. This has the disadvantage that Maven will not start on JDK 8.
  2. They can also be prefixed with -J and passed as arguments to the compiler, but then we need to set <fork>true</fork>.

Personally I would go for 1 and require JDK 17 or 21 to build the package. Users can still run tests on JRE 8 using toolchains (see the java8-tests profile in Log4j)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@stevespringett already said that Java 8 is a requirement. Any changes could be handled by putting it in a profile. Maybe just disable errorprone in the non-jdk1.8 profile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Using the errorprone compiler is making my IDE (IDEA) continuously rebuild.

I wonder if anything is gained from errorprone that spotbugs can't already find, and spotbugs doesn't require a special compiler. However, spotbugs-maven-plugin will still need to be version locked because future versions drop building on Java 8 support it seems.

Copy link
Contributor

Choose a reason for hiding this comment

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

@stevespringett already said that Java 8 is a requirement.

Yes, but that is a runtime requirement. To build the library JDK 17 can be used with --release 8. Even if they target the same bytecode version, newer compilers generate better performing bytecode.

We make all Log4j releases using JDK 17, although the runtime requirement is Java 8.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if anything is gained from errorprone that spotbugs can't already find, and spotbugs doesn't require a special compiler.

Error Prone and Spotbugs rules are rather independent. Currently Error Prone finds these problems, while Spotbugs does not find any:

[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[95,53] [NonApiType] Prefer a java.util.Map instead. 
    (see https://errorprone.info/bugpattern/NonApiType)
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[250,48] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'final String retVal = value.toLowerCase(Locale.ROOT);' or 'final String retVal = value.toLowerCase(Locale.getDefault());' or 'final String retVal = Ascii.toLowerCase(value);'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[279,51] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'retVal = tempNamespace.toLowerCase(Locale.ROOT);' or 'retVal = tempNamespace.toLowerCase(Locale.getDefault());' or 'retVal = Ascii.toLowerCase(tempNamespace);'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[298,41] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'temp = value.toLowerCase(Locale.ROOT);' or 'temp = value.toLowerCase(Locale.getDefault());' or 'temp = Ascii.toLowerCase(value);'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[301,62] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'temp = value.replaceAll("_", "-").toLowerCase(Locale.ROOT);' or 'temp = value.replaceAll("_", "-").toLowerCase(Locale.getDefault());' or 'temp = Ascii.toLowerCase(value.replaceAll("_", "-"));'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[335,50] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'final String retValue = value.toLowerCase(Locale.ROOT);' or 'final String retValue = value.toLowerCase(Locale.getDefault());' or 'final String retValue = Ascii.toLowerCase(value);'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[419,59] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'purl.append(entry.getKey().toLowerCase(Locale.ROOT));' or 'purl.append(entry.getKey().toLowerCase(Locale.getDefault()));' or 'purl.append(Ascii.toLowerCase(entry.getKey()));'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[456,66] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'builder.append(Integer.toHexString(b).toUpperCase(Locale.ROOT));' or 'builder.append(Integer.toHexString(b).toUpperCase(Locale.getDefault()));' or 'builder.append(Ascii.toUpperCase(Integer.toHexString(b)));'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[571,83] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'this.type = validateType(remainder.substring(start, index).toLowerCase(Locale.ROOT));' or 'this.type = validateType(remainder.substring(start, index).toLowerCase(Locale.getDefault()));' or 'this.type = validateType(Ascii.toLowerCase(remainder.substring(start, index)));'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[620,69] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'if (map.put(entry[0].toLowerCase(Locale.ROOT), percentDecode(entry[1])) != null) {' or 'if (map.put(entry[0].toLowerCase(Locale.getDefault()), percentDecode(entry[1])) != null) {' or 'if (map.put(Ascii.toLowerCase(entry[0]), percentDecode(entry[1])) != null) {'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[621,175] [StringCaseLocaleUsage] Specify a `Locale` when calling `String#to{Lower,Upper}Case`. (Note: there are multiple suggested fixes; the third may be most appropriate if you're dealing with ASCII Strings.)
    (see https://errorprone.info/bugpattern/StringCaseLocaleUsage)
  Did you mean 'throw new ValidationException("Duplicate package qualifier encountere - more then one value was specified for " + entry[0].toLowerCase(Locale.ROOT));' or 'throw new ValidationException("Duplicate package qualifier encountere - more then one value was specified for " + entry[0].toLowerCase(Locale.getDefault()));' or 'throw new ValidationException("Duplicate package qualifier encountere - more then one value was specified for " + Ascii.toLowerCase(entry[0]));'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[661,20] [InlineMeSuggester] This deprecated API looks inlineable. If you'd like the body of the API to be automatically inlined to its callers, please annotate it with @InlineMe. NOTE: the suggested fix makes the method final if it was not already.
    (see https://errorprone.info/bugpattern/InlineMeSuggester)
  Did you mean '@InlineMe(replacement = "this.isCoordinatesEquals(purl)")'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURL.java:[703,16] [UnnecessaryParentheses] These grouping parentheses are unnecessary; it is unlikely the code will be misinterpreted without them
    (see https://errorprone.info/bugpattern/UnnecessaryParentheses)
  Did you mean 'return  this.canonicalize().equals(purl.canonicalize());'?
[WARNING] /home/piotr/workspace/CycloneDX/packageurl/src/main/java/com/github/packageurl/PackageURLBuilder.java:[194,19] [NonApiType] Prefer a java.util.Map instead. 
    (see https://errorprone.info/bugpattern/NonApiType)

@dwalluck
Copy link
Contributor Author

I will revisit after #178.

@dwalluck dwalluck marked this pull request as draft March 11, 2025 13:57
@dwalluck dwalluck force-pushed the update-pom-versions branch 2 times, most recently from 4f9344e to 6105448 Compare March 12, 2025 22:52
@dwalluck dwalluck marked this pull request as ready for review March 12, 2025 22:52
@dwalluck
Copy link
Contributor Author

OK, merged with #178.

@jeremylong
Copy link
Collaborator

In trying to reduce merge conflicts - is there something in this PR that won't be handled by the dependabot updates?

@dwalluck
Copy link
Contributor Author

In trying to reduce merge conflicts - is there something in this PR that won't be handled by the dependabot updates?

Yes, there are a few changes:

  • Currently, dependabot seems to have caught only half the version updates
  • Add a property for all versions where it was missing
  • Add maven-gpg-plugin pluginManagement
  • Added versions-maven-plugin config. This just allows manual version checking to see if dependabot missed something. It does not run during the build, but I am OK with removing it.

I forget if dependabot will automatically close existing pull requests if this were to be merged first. It definitely will if you rebase it and it notices that the version is already up to date.

Or, merge dependabot first, and we'll see what, if anything, remains.

@dwalluck dwalluck force-pushed the update-pom-versions branch from 6105448 to b280fd6 Compare March 13, 2025 13:26
@jeremylong
Copy link
Collaborator

The dependabot PRs have been merged. Mind fixing the merge conflicts and I'll get this merged as well?

@dwalluck dwalluck force-pushed the update-pom-versions branch 2 times, most recently from d5477a8 to 4ded039 Compare March 16, 2025 13:50
@dwalluck
Copy link
Contributor Author

Needs #205 first.

Update all dependencies to the latest version and use properties for
all versions for easy updating.
@dwalluck dwalluck force-pushed the update-pom-versions branch from 4ded039 to 99f75e1 Compare March 16, 2025 15:09
@jeremylong jeremylong merged commit b6269ec into package-url:master Mar 16, 2025
2 checks passed
@dwalluck dwalluck deleted the update-pom-versions branch April 15, 2025 21:38
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.

3 participants