openjdk-N (non-default) should not trigger autopkg tests.  All these don't make
any sense, as the tests are always run using the default JRE/JDK.

E.g. for 13, these were triggered today:

autopkgtest for airport-utils: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for android-platform-tools-apksig: amd64: Test in progress, arm64:
Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test
in progress
autopkgtest for apgdiff: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for beagle: amd64: Test in progress, arm64: Test in progress, armhf:
Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for beast2-mcmc: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress (will not be considered a
regression), ppc64el: Test in progress
autopkgtest for chromhmm: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for chromimpute: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress (will not be considered a regression), i386: Test in
progress (will not be considered a regression), ppc64el: Test in progress
autopkgtest for clojure: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for davmail: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for drop-seq: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for imagej: amd64: Test in progress, arm64: Test in progress, armhf:
Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for libreoffice: amd64: Test in progress, arm64: Test in progress
(will not be considered a regression), armhf: Test in progress, i386: Test in
progress, ppc64el: Test in progress (will not be considered a regression)
autopkgtest for libsis-jhdf5-java: amd64: Test in progress, arm64: Test in
progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for munin: amd64: Test in progress, arm64: Test in progress, armhf:
Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for openjdk-13: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for picard-tools: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for pilon: amd64: Test in progress, arm64: Test in progress, armhf:
Test in progress, i386: Test in progress (will not be considered a regression),
ppc64el: Test in progress
autopkgtest for runescape: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
autopkgtest for swi-prolog: amd64: Test in progress, arm64: Test in progress,
armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress

Hi,

Maybe, but default-jre, openjdk-11-jre, openjdk-13-jre, openjdk-14-jre,
openjdk-15-jre, openjdk-16-jre, openjdk-8-jre all provide e.g.
java5-runtime, so if a package depends on it, there's a relation to
could be tested. However, there's nothing in place to force the test to
run with an non-default alternative, so scheduling a test currently
doesn't make much sense.

I agree that the current situation doesn't really enforce to test the
right thing yet, but if we think it's worth while, we could work on
fixing that.

[...]

apksigner depends: default-jre | java8-runtime | java9-runtime |
java10-runtime | java11-runtime

Paul