Any idea how the update site generator could determine this without opening each plugin hpi and checking the .java files' major.minor?

At least at build time we should add a control with an enforce bytecode version I think

http://www.mojohaus.org/extra-enforcer-rules/enforceBytecodeVersion.html

At runtime for the plugins manager if we don't want to parse all plugins we need to extract the supported java version in the update center for each plugin

I created issue because tired from users complaining about it even if it written in docs. I didn't think about tech side. But i guess you can parse pom (i.e. Aether lib) that has enforcement level as string value.

Yes, it makes sense we see it regularly.
The main issue is that some plugins are targeting Java 8 while Jenkins core and slaves are always supposed to run on Java 7.

extract the supported java version in the update center for each plugin

Well, yes, but how? It's not like I can parse the POM for this, or have META-INF for this. I need to look at all the class files individually and check their versions. Which seems pretty insane.

We could add this in maven-hpi-plugin, but until that trickles down we'd have nothing…

Every plugin has pom, that has <java.level> all you need parse pom and trust to this info. Checking META-INF was my first thought, but you limited to not extract hpi's

Isn't that only convention? https://github.com/jenkinsci/plugin-pom/blob/master/pom.xml#L546

It wasn't in https://github.com/jenkinsci/jenkins/blob/jenkins-1.532/plugins/pom.xml …

Also, remember the Gradle based plugins. Nothing in http://repo.jenkins-ci.org/simple/releases/org/jenkins-ci/plugins/job-dsl/1.52/job-dsl-1.52.pom …