On Mon, 8 Jan 2024 13:03:22 GMT, Jiří Vaněk <[email protected]> wrote:
> This PR is fixig to-old values of javac source/target for jdk22. > Note, that jdk21 suffers the same, only the target values have to be 8. I > will be happy to backport this cange to jdk17 later. > > Note, that considering the rolling release of jdk and the reached threshold > of bytecode compatibility, we will be forced to do this bump every STS, so > best would be to drop this hardcoded limitation. As it obtains a bit more > coding, I had filled the > [JDK-8323169](https://bugs.openjdk.org/browse/JDK-8323169) - [ j2dbench need > constant updating of javac source/target > ](https://bugs.openjdk.org/browse/JDK-8323169) and will be happy to fit it > for jdk asap once this direct fix bubbles to jdk21 Hello! Thanx for a reply! This could have been true when the source/target was rolling supper slowly, but now, with new jdk every half a year, this is literally forcing anybody who would like to j2dbenchmark newer jdks to substitute source/target or to compile by another jdk where non of that gave sense to me. I think j2dbench should go in spirit of in-tree jtregs and shold be ok for jdk it is cloned from. Anybody who wishes to run it on older jdk, can clone it from older jdk. One can argue that different j2dbenchmarks will produce different results, but j2dbench is completed project, and even bumping source/targe is not exactly well spent time. In addition user knows what jdk they are will be comparing, and select base j2dbench accordingly. I think it would be super rare to compare jdks 7-22 in one batch. If that would be a target, a bit of coding would be expected anyway. But you know better. Feel free to close (or tell me to close) this PR/bug . (Actually I think I was fixing it already once in past, from 1.4 to 1.7, but I had not found a commit nor pr so maybe that is what was closed "want fix") If I may dare to discuss furthermore, then I would like to persuade you that j2dbench should really be compilable with jdk it is part of. By keeping the source/target (or change it to release), or by dropping source/target completely, or to make it adjustable by better way then repalcing in build files (in which case the sane default, should be still compatible with jdk it iwas cloned from) . The proper sane defaults will nicely enforce clean code. To drop it completely may actually bring wider changes, and maybe indeed affect the accuracy (will try if that will be the case) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17303#issuecomment-1882704706
