Replace javax.validation with jakarta.validation

[rfscholte]

Due to such breaking change, also change the version to 2.0.0

[rfscholte]

This is most likely the cause why it can only be build with Java 8, which is an undesired requirement nowadays:

[INFO] --- maven-compiler-plugin:3.11.0:compile (default-compile) @ packageurl-java ---
[INFO] Changes detected - recompiling the module! :source
[INFO] Compiling 7 source files to D:\Data\java-workspace\github\packageurl-java\target\classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] D:\Data\java-workspace\github\packageurl-java\src\main\java\com\github\packageurl\validator\PackageURLConstraintValidator.java:[32,8] cannot access java.lang.Object
  bad class file: /modules/java.base/java/lang/Object.class
    class file has wrong version 55.0, should be 53.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.
[INFO] 1 error

[dwalluck]

Actually, that error is due to error.prone.core.version (and plexus.compiler.javac.errorprone.version) being too old. Increase at least these verions to the latest and it should work

mvn "-Derror.prone.core.version=2.36.0" "-Dplexus.compiler.javac.errorprone.version=2.15.0" clean verify

[rfscholte]

What's the reason these versions haven't been updated yet? For any contributer on any project mvn verify should be enough to build the project.

[dwalluck]

The project seems to be inactive. I have a bunch of open pull requests that are going to conflict with one another so it's making it hard to submit more changes such as for this one.

Let's try pinging @stevespringett and @jeremylong and ask if they're still active.

[jeremylong]

@stevespringett I'd need more rights on the project to be able to help.

[jeremylong]

I was just given rights to the repo. I am in the middle of a higher priority issue with another project of mine. As soon as that is fixed I'll review these PRs.

[dwalluck]

Thanks @jeremylong!

Originally, I just wanted to add some APIs to avoid some boilerplate in my code.

Then, I saw some issues that had been sitting open for a long time and I decided to try to fix all of the open issues and in the process may have found some more!

A lot of the pull requests are going conflict with each other as they touch the same code. But, it's enough to start with the smallest/independent ones.

Then see if the other ones are acceptable to you before we do anything more.

Thanks again!

[dwalluck]

For example, I'd like to also upgrade from JUnit 4 to JUnit 5, since JUnit 4 I think is deprecated, but I won't waste time on it if it isn't acceptable.

[stevespringett]

Regarding Java 8 compatibility. This is still a requirement. According to the 2024 State of the Java Ecosystem report, 28.8% of applications still rely on Java 8 which will not be end-of-life until November 2026. I personally wish this date would have past long ago and we could move on, but that unfortunately doesn't appear to be the case. At that time, I would be more than happy to bump the minimum JDK version to 11 or higher.

[dwalluck]

Upgrading the versions fixes the build with JDK 9+ which is just useful for people building it themselves, I guess. JDK 8 is still enforced for releasing and appears to work fine, even after I upgraded all dependences (in part because it really doesn't have any direct dependencies).

You may consider a version 1.x for Java 8 and 2.x for Java 11.

[dwalluck]

I think if you want to get even more strict about enforcing a particular Java version, you can add animal-sniffer-maven-plugin to the build.

[rfscholte]

Note that with every more recent JDK, the compiled classes become better. So it is worth to build the application with such JDK and compile using --release 8 (instead of source/target) to ensure java 8 compatible code. https://www.mojohaus.org/extra-enforcer-rules/enforceBytecodeVersion.html can help to ensure that also the dependencies are Java 8 compatible.