On 20/04/17 09:52, Alan Bateman wrote: > On 20/04/2017 07:43, Matej Novotny wrote: >> Another nasty thing is that the code of course needs to work with >> both, JDK 9 and 8. >> While it isn't impossible, it will add a not-so-nice reflection magic >> layer to the mix. >> > Multi-release JARs (JEP 238 [3]) and the ability to compile to older > releases (JEP 247 [4]) might be useful here (you might know about these > features already).
Alan is right to point to multi-release JARs as a useful way to solve this type of problem. However, I managed to bypass this issue in Byteman simply by hiding the affected code behind a facade (interface) and dynamically loading either a pre-jdk9 or jdk9+ implementation with all code bundled into the same jar. So, only one reflective operation was required (to instantiate the facade class). n.b. I realise that decoupling the rest of the code from the two alternative implementations is not necessarily going to be straightforward and might lead you to prefer the nulti-release jar approach. In my case the factoring this implied was not too difficult but it was actually a very useful exercise to go through. It forced me to clean up a slightly scrappy internal dependency with the *right* abstraction. If you are going to have to maintain jdk8 and jdk9 function for some time then I suspect Alan's route will probably also require you either to i) introduce some such clean abstraction or ii) go mad maintaining two slowly diverging sets of classes. So, you might still want to consider the approach I followed. Your mileage (or madness) may vary. regards, Andrew Dinn -----------
