Replace animal-sniffer with javac parameter

[Euklios]

This closes #311

[bramp]

Sounds great, but quickly reading about this, doesn't the '--release' flag need to be set. Where is that now happening?

[Euklios]

Sounds great, but quickly reading about this, doesn't the '--release' flag need to be set. Where is that now happening?

Interestingly, when testing, I had the same behaviour when specifying the source and target.
But according to the documentation, you also need maven.compiler.release.
I'll update the PR

[Euklios]

@bramp I've added the missing flag.
This Javac feature was introduced in Java 9, so we can't use it on jdk8.
I configured it so that it will only be applied for jdk 9+.
Version 8 is still supported, but without adding the flag. Compatibility is guaranteed by simply not having the classes of higher versions in that case.

Alternatively, we could also upgrade to a newer Java version

[bramp]

I'm really out of date with Java, what's the standard min supported version? Checking my go-to project guava, they still support Java 1.8+.

[Euklios]

LTS releases are:

• 8
• 11
• 17
• 21

It honestly depends. Many tooling and very static solutions are still using Java 8, which is basically the "never-touch"-systems.
More significant projects (with financial backing) usually tend to target the current LTS or one before (spring, for example, switched to Java 17 with the release of Spring Boot 3)

The only somewhat consistent overview of that topic (that I know of) is from newrelic. Based on that: Java 11 would be the most LTS. Sadly, this was published a few months after the release of Java 17, which means adoption was still underway. I'm expecting an update next month, but I'm expecting a shift in adaptation towards 17.

The option of Multi-Release Jar Files allows newer versions to be added to an old project.
Example: (The baseline is on Java 8, so add a second implementation for Java 11, and the runtime will dispatch to the next lower version).
But that is more for performance improvements, and we don't have the time to support this setup.

My company is still running on Java 17, and we plan to upgrade it to Java 21.
We switched because the dependencies we rely upon started incorporating needed changes, but they already used Java 17.
We were running on Java 8 before.

I'm working on projects in my spare time using Java 17+.
The project I'm using this library in is currently running with Java 19 but already has a branch ready with Java 21.

Ultimately, Java 8 was so popular that it won't die.
However, the projects still using it will most likely not add significant updates in the future.

@bramp Hope that helps.
TLDR: Use 17 for now

[Euklios]

@bramp Something I'd like to add:
I would create a release before switching versions.

Additionally, I'm working on adding getters to all the data classes.
Java has made a lot of progress towards immutable data, which (based on the comments) is also a goal of this project.
However, these structures don't work with public properties.

So, my recommended roadmap would be:

• Add getters and mark public properties as deprecated
• Release
• Make properties private
• Switch Java version

[bramp]

Thanks for all the great info. I think I'll move a lot of this content into a bug #316

As for this change, let's try and keep Java 8 support, but happy to use this change for Java 9+