I'd argue this is something non-standard you should set in your environment, not in the nixpkgs derivations. But I am open to discussions. I have never had to use variables like these (I go though different nix-shell invocations to build against multiple JDKs).

something non-standard you should set in your environment, not in the nixpkgs derivations

It's definitely a niche use case, but a google search for JAVA_8_HOME shows it's not entirely unheard of

I go though different nix-shell invocations to build against multiple JDKs

Yes, that is neater when possible. I have some builds that want to be able to find both JDK8 and JDK11 bootclasspaths during the same build (invocation/artifact), though, so that is where this would come in useful.

Also adoptopenjdk-bin should be updated.

If you introduce JAVA_?_HOME into nix derivations, then you create another de-facto standard only for nixpkgs. If this is not a standard respected by java but something which completely depends on how you handle it in a specific build, then I think, this should be set only for this build. Or is there any formal/generally accepted standard for handling multiple JDKs in one build?

If you introduce JAVA_?_HOME into nix derivations, then you create another de-facto standard only for nixpkgs

I agree that's not great, though https://www.google.com/search?client=firefox-b-d&q=JAVA_8_HOME suggests it's already not entirely unheard of.

It's exotic, though, I agree - if there were some more widely used approach that would certainly be my preference.

Or is there any formal/generally accepted standard for handling multiple JDKs in one build?

Not as far as I know.

If you introduce JAVA_?_HOME into nix derivations, then you create another de-facto standard only for nixpkgs

I agree that's not great, though https://www.google.com/search?client=firefox-b-d&q=JAVA_8_HOME suggests it's already not entirely unheard of.

It's exotic, though, I agree - if there were some more widely used approach that would certainly be my preference.

Or is there any formal/generally accepted standard for handling multiple JDKs in one build?

Not as far as I know.

Then why should the Nix community standardize it? This would also need to be documented and enforced.

From the google search, my impression is that most of the time people set JAVA_HOME to $JAVA_?_HOME to switch between java versions. With nix builds, nix-shell or lorri(+direnv) it is easy to select the right JDK.

For your use case, @raboof (multiple JDKs at once): If there are the JAVA_?_HOMEs then you still need to tell your build to use them. So you need to be explicit again. What is the benefit from having a part of this abstracted in nixpkgs when a part of this is still needed in each build?
You can always set JAVA_?_HOME in any derivation that needs it.

Is this use case very common? Or is your proposal an abstraction of multiple use cases? Are there others than this which would benefit from your proposal?

Furthermore, why do you only assign JAVA_?_HOMEs for major releases? What if a build needs, say, openjdk8 from nixos-19.03, zulu8, openjdk12 and oraclejdk12? Is there a canonical way of naming the additional JAVA_?_HOMEs? Or how does nix decide which JAVA_{8,12}_HOME to choose? This is already a mess with JAVA_HOME depending on the order of evaluation of buildInputs, which isn't specified AFAIK. The solution I see is: Always have at most one JDK in buildInputs and be explicit about everything else.

Is this use case very common? Or is your proposal an abstraction of multiple use cases? Are there others than this which would benefit from your proposal?

I'll be the first to admit it's a somewhat niche situation, but it would definitely benefit other build tools and IDE's that allow 'interactively' switching between Java versions.

I guess I also agree with the voices against this change since it contributes to promote non standard environments. If it's for niche situations why this should be rolled out in general and not be solved in user space.

it contributes to promote non standard environments

i think there is a real need for a standard way to discover the available JDK's. There is no standard way to achieve this, and such a standard isn't going to materialize spontaneously - it should emerge from smaller experiments. This could be such a smaller experiment.

If it's for niche situations why this should be rolled out in general

I think one of the wonderful things of open source is that if someone cares enough about a certain niche, they can put in the work to have 'their' niche well-supported and contribute those improvements upstream. Having a single niche well-supported is of relatively little value, but accumulating and supporting many niches is an advantage for the project as a whole. Of course this has to be balanced against increased maintenance burden - but in this case I'd say that's pretty light.

Anyway, this PR has gained a conflict, closing for now.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/auto-detecting-java-installations/4677/6