Use multi-version jar instead of reflection to detect Loom support

[renatoathaydes]

We're having errors loading the jar into our system because we do some verification that classes are loaded successfully on startup.

The jgroups jar seems to intentionally handle ClassNotFoundExceptions to "probe" for Project loom virtual Threads... which makes it break in our system.

I was just thinking that maybe you should consider using multi-version jars instead of reflection? So, if someone is running on JDK19 they would get to use the JDK19-specific classes instead of relying on reflection which can be quite fragile.

Example of a place where I believe jgroups is probing for Loom:

https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.java#L210

If you don't like the suggestion, please just ignore it, thanks!

[belaban]

I use CNFEs in more than just one place, e.g. to determine the correct logging subsystem. I don't understand why catching CNFEs breaks your system...
I prefer not to introduce multi-release JARs unless I have to, e.g. if you give me a good reason...

[renatoathaydes]

Guessing features users might want to use simply because they happen to have such feature in their environment (perhaps without their knowledge) has proven to be a potentially serious issue, with security consequences.
We can suppress the warnings about classes not being found, but we would prefer for libraries to not probe our environment searching for things like this... it's similar behaviour to a serialization vulnerability scanner for example.
Besides multi-jars (which seems appropriate because there is no way this would succeed on Java 8 or 11, for example), perhaps you could use something like system properties, environment variables or basic configuration to allow users to explicitly opt-in to these features.

[tristantarrant]

MR Jars are much better than using reflection, because issues can be discovered at compile-time. I can help you with setting that up @belaban

[rhusar]

+1

[belaban]

Yes, that'd be welcome. PRs for POM and ant/ivy...

[tristantarrant]

#650

[belaban]

OK, thanks @tristantarrant, applied&merged, will be in 5.2.5

[rhusar]

We should probably add some form of REALEASING.md file describing that 5.2.5 and later require JDK 19 for releasing in order to build the MR jar.