On 7/7/20 10:13 AM, David Holmes wrote:
Hi Peter,
cc Claes
On 7/07/2020 5:59 pm, Peter Levart wrote:
Hi,
Recently I proposed and pushed a change for [1] which adds
--enable-preview option to javac compilation of JMH microbenchmarks
in general to enable running a benchmark that uses preview feature
(Records). This makes the class files produced marked with version
60.65535. The benchmark that uses preview feature executes without
problems because it explicitly specifies the following in its code:
@Fork(value = 1, warmups = 0, jvmArgsAppend = "--enable-preview")
Recently I wanted to run JMH benchmarks for Stream ops with:
make test TEST="micro:java.util.stream.ops"
...but all of them fail to run with the following exception:
java.lang.UnsupportedClassVersionError: Preview features are not
enabled for
org/openjdk/bench/java/util/stream/ops/value/generated/NoneMatchShort_seq_start_jmhTest
(class file version 60.65535). Try running with '--enable-preview'
What shall we do? Add similar annotation to all of them? Is there a
way to specify that all micro benchmarks should be run with
--enable-preview option passed to java?
So this breaks running all non-preview using benchmarks? If so I say
we need to backout the change for 8248135 while a proper solution is
found.
I guess it does break (at least the way I tried to run them). The
problem is that this little change:
--- a/make/test/BuildMicrobenchmark.gmk Wed Jun 24 01:02:19 2020 +0200
+++ b/make/test/BuildMicrobenchmark.gmk Wed Jun 24 11:05:09 2020 +0200
@@ -90,10 +90,11 @@
TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
SMALL_JAVA := false, \
CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
- DISABLED_WARNINGS := processing rawtypes cast serial, \
+ DISABLED_WARNINGS := processing rawtypes cast serial preview, \
SRC := $(MICROBENCHMARK_SRC), \
BIN := $(MICROBENCHMARK_CLASSES), \
JAVA_FLAGS := --add-modules jdk.unsupported --limit-modules
java.management, \
+ JAVAC_FLAGS := --enable-preview, \
))
...was pushed as part of larger fix for 8247532 which has already been
forward and backported. So I think backing out the whole patch (which is
perfectly OK by itself) would cause more problems then fixing this
particular problem in a followup, given that we can find a fix quickly.
Its has been 14 days since the above was pushed and nobody noticed until
now, so I guess this is not a big problem?
Regards, Peter
David
-----
[1] https://bugs.openjdk.java.net/browse/JDK-8248135
Regards, Peter
