Add Maven profiles to support building with JDK 8-16

[arnej27959]

• Add 'ancient-jdk' profile (JDK 8-10) that skips test compilation and execution
• Add 'old-jdk' profile (JDK 11-16) with appropriate JVM args for module system
• Update default surefire configuration for JDK 17+ with --add-opens flags and security manager settings
• Upgrade ASM library from 5.2 to 9.9 and split into asm + asm-tree dependencies
• Update test code to use ASM 9.x API (remove Opcodes.ASM4 flag)

This allows the project to be built with older JDK versions while maintaining compatibility with modern JDK releases (17+).

[arnej27959]

Some background: I'm looking at some of the code that depends on internals of JDK versions (mainly SecureAction.java), and to ensure I can make PRs with changes that don't break for older JDKs, I've installed various versions and tried running unit tests. So far I've used 8, 11, 17, and 21 and ran into some problems that I resolved with these profiles; I will also test with Java 25. The biggest issue so far is that the unit tests wouldn't compile at all using JDK 8, so I'm not sure what people do to ensure they don't break that version - any hints would be appreciated.

[stbischof]

@cziegeler any opinion on that? Or in generally update the build jdk to some higher version in general?

[cziegeler]

I dont mind requiring a newer Java version - but I think @tjwatson needs Java 8

[laeubi]

I don't think the goal would be to compile with a true JDK8 ... it would be enough to compile with --target 8 ...

[arnej27959]

To clarify: while using --target 8 is usually enough, to ensure the code actually works with JDK8 you have to run it with an actual, true JDK8. And then it's helpful (but not really necessary) if you can also compile with it.

[laeubi]

To clarify: while using --target 8 is usually enough, to ensure the code actually works with JDK8 you have to run it with an actual, true JDK8. And then it's helpful (but not really necessary) if you can also compile with it.

I would expect people requiring this code to "really work" on JDK 8 are testing it. It does not sounds feasible to put extreme effort in an OSS project to compile / test on many JDKs without real benefit. e.g. if you are going that path, what is with JDK8 on windows? On mac? on AXI or whatever... What about 32 bit? So one can easily see that any "hard guarantees" can easily explode the necessary efforts.

For what its worth here, I think if we compile + run with the latest LTS of java seems a valid choice, java was made with platform (and java version!) independence in mind so If we doubt that some code tested with a particular version suddenly fail on an other version I would say this is a bug that must be fixed at the JVM vendor.

Anyways I don't want to hold anyone back to help making it easier to compile/test/run on a "true" JVM, I just wanted to point out that neither it is a requirement nor a prerequisite. We can make java 8 users happy with -target 8 (as long as supported) and still not need to go down that rabbit hole and simply use a modern JDK.

[arnej27959]

Agreed on all counts; the changes I want to make are for making things work more smoothly on Java 25. But if I'm not super careful I know that those changes will break for people using JDK 1.8, and as long as the project is using --target 8 that is probably not good. I'm not expecting many other people will do that type of changes.