Add openjdk to global pinning?

[h-vetinari]

To my surprise, I couldn't find openjdk in the global pinning.

Shouldn't we have openjdk 8/11 in the global pinning, and maybe add a migrator for 17?

Is this state of affairs intentional intentional or just a historical artefact?

CC @conda-forge/openjdk @conda-forge/core

[xhochy]

Can you name a package that would be rebuild with the pinning?

[h-vetinari]

Can you name a package that would be rebuild with the pinning?

Let me answer slightly more broadly with packages that I think would benefit from having a pinning - i.e. several feedstocks already need to work around this by either hard pinning 8/11/17, and having it available globally allow those workarounds to be removed.

It would also make it clearer that certain packages should be rebuilt against 11 / 17 (at least as soon as upstream support becomes available), because pinning to 8 (esp. as run) is quite hostile (or self-defeating) if there are other packages that need a newer java in the same environment. As such it would provide some incentive to migrate away from 8 and towards newer LTSes.

Clear-cut examples (already building for multiple java versions through cbc):

• apache-ant
• pyjnius

Others from a non-exhaustive search for "- openjdk" in conda-forge (and taking only those with a host & run dep):

• orekit
• r-rjava
• rstudio
• pypmml
• python-javabridge

There's more that have only a host-dependence, but I'm not sure those would necessarily be affected (openjdk doesn't seem to have a run-export).

And then there's cases like pyspark, where we're currently repackaging binaries.

[xhochy]

The first two make sense, but for most of the other packages, it either comes down to:

1. Upstream only supports 8 (yes, this is very typical case, half of the world is stuck there)
2. The build and run is independent of the Java version and we shouldn't build for multiple versions but only one (e.g. the oldest).