Update to Java 11

[chrswk]

Not sure what the stance of this project is in regards to newer Java versions. I've been using this library for a couple of years now and I would love to see it with a proper module info file. Feel free to change the module name if it's not appropriate and let me know, if there are any changes I should make.

-Chris

[stevehu]

@chrswk I would love to upgrade to Java 11; however, there are still a lot of users stuck on Java 8 and needs this library. It took us a lot of discussions when we upgrade from Java 6 to Java 8 and we cannot simply upgrade to Java 11 and leave some of our users behind. I am open to ideas to upgrade to Java 11 but want to have another branch/release for Java 8 users if possible.

[chrswk]

@stevehu I completely understand. I'll try to figure something out using multi release/module info.

[SiemelNaran]

Can we use Java 16 for the tests, but keep Java 8 for main? This will allow me to use text blocks https://openjdk.java.net/jeps/355

[stevehu]

@SiemelNaran The current source level is java 8 because a lot of users are still using it and we cannot leave them out. If we use java 16 for test cases, some developers might complain about it. Let's stay on Java 8 for now and think about upgrading when most users are upgraded.

[TJC]

I hit these issues while investigating a bug that required me to rebuild the source code. I only have JDK 11 and 17 on my machine - those being the two JDK LTS releases that are current. (8 having gone EOL some time ago)

It would be great if you could upgrade maven-bundle-plugin to 5.1.2 and maven-compiler-plugin to 3.8.1

Even if you leave the default target as 1.8, having those upgraded will allow people to change the target to 11 easily.

[stevehu]

@TJC I think it is a good idea to upgrade the plugins as long as the upgraded version still working with JDK8. Could you please submit a PR? I will test it with my local VM with Java8 installed. Thanks.

[julesjacobsen]

For solving the module info problem on pre- and post-jigsaw Java versions, how about at least adding an Automatic-Module-Name to the MANIFEST.MF like in this PR: protocolbuffers/protobuf#6568

It's not perfect, but it's better than not providing any module name which means this sort of warning happens to clients on building with maven:

[WARNING] ********************************************************************************************************************
[WARNING] * Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *
* Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *
********************************************************************************************************************

[rosti-il]

If the maven.compiler.release property is used the older maven.compiler.source and maven.compiler.target properties should be omitted.

[agentgt]

If this project upgrades to Java 11 I recommend Apache Commons lang3 get removed since all of its uses appears to be to use StringUtils.isNotBlank. Java 11 has String.isBlank builtin.