adoptopenjdk: add caveat pointing to the external tap

[commitay]

cc @Homebrew/cask

Ref: #53976 (comment), #53976 (comment)

Upstream intends to have casks for a (current) minimum of 8 adoptopenjdk JDK versions + JRE versions.

This is more than we can or want to support.

[claui]

I’m 👍 on that, especially from a UX perspective. Java’s roadmap is already complicated enough by itself; users may appreciate to have a reliable single source for AdoptOpenJDK casks.

[gdams]

@commitay I'm strongly against this?! you've accepted my casks into core and then you're removing them with no notice/agreement from myself or anyone else at the AdoptOpenJDK. This is a breaking change and I would hope that homebrew had better policies than this...

[karianna]

Hi all - it would be great to have a voice / video call on this. The Java ecosystem is undergoing significant change which I appreciate is coming down like a ton of bricks on Brew in the past week. There are X million java developers who would like to see a good brew experience for this and I think it’s up to us to work with the maintainers to come up with a solution which has minimal harm for brew. Is there a channel we can arrange a call on?

[vitorgalvao]

you've accepted my casks into core and then you're removing them with no notice/agreement from myself or anyone else at the AdoptOpenJDK.

Let’s please start by deescalating the tone, so we can have a productive conversation. @karianna’s comment is a good example.

Let’s also please understand Homebrew has no obligations to anyone and we don’t need to ask for permission to third parties if we decide to stop supporting their software.

This is a breaking change and I would hope that homebrew had better policies than this

Furthermore, insulting our policies is an unproductive way to get us to change them. I’ll remind you that it’s those same policies that are keeping the cask in right now, as @commitay has opened a discussion and asked for feedback, not outright removed it.

Finally, external taps are perfectly legitimate options. The homebrew system is designed well-enough that no one is bound by the restrictions of the main repositories.

So I’ll ask again that we don’t act like something is owed when it’s not and keep the discussion civil, as that’s in everyone’s best interest.

[commitay]

When adding casks and deprecating the adoptopenjdk tap was discussed in the original PR it was not clear that AdoptOpenJDK wanted to add additional casks for versions that did not exist in that tap.

12 adoptopenjdk casks is more than the combined total of all of our other Java casks. While your offer to assist in maintaining them is appreciated, it does not change the fact that the burden of maintaining them lands on HBC maintainers.

As we are unwilling to support all of them and they are all considered equal, I think AdoptOpenJDK maintaining all of the casks in their own tap is the best path forward for the community.

[gdams]

The way I view this is that we now have users that will be pulling our casks in from core and many people will be automating this. IMO deprecating a task would have a very negative affect for both homebrew and adoptopenjdk. I for one use homebrew in ansible playbooks and it concerns me greatly that homebrew is happy to remove those casks. I would ask that the homebrew maintainers please consider @karianna’s request to have a call with us so that we can at least discuss the options.

[commitay]

IMO deprecating a task would have a very negative affect for both homebrew and adoptopenjdk.

Yes, so we should do so as soon as possible as the longer we wait it will affect more users.

We will not add all of the versions that you wish to support and splitting them between an official tap and a external tap will be confusing for users.

To be blunt: if it had been mentioned in the original PR that AdoptOpenJDK wanted to add so many versions we wouldn't be here now.

[gdams]

@commitay are you and others happy to have a call to discuss this?

[commitay]

are you and others happy to have a call to discuss this?

I personally am not and I don't see any benefit to be gained to discussing this further via a call.

[claui]

I would ask that the homebrew maintainers please consider @karianna’s request to have a call with us so that we can at least discuss the options.

@gdams I feel it would be better to discuss the options here. It’s more transparent this way for everyone involved.

[karianna]

Hi all - I'm new to homebrew, so forgive the beginner questions :-).

1. Assuming AdoptOpenJDK maintains some/all of its own casks, what is the user experience like from an end user? If they executed brew search openjdk or brew search adoptopenjdk would they find them or do they need to add some sort of brew repository?

2. I'd like to understand what an acceptable number of adoptopenjdk casks would be from a brew core maintainers perspective.

[gdams]

Assuming AdoptOpenJDK maintains some/all of its own casks, what is the user experience like from an end user? If they executed brew search openjdk or brew search adoptopenjdk would they find them or do they need to add some sort of brew repository?

@karianna if our cask is not in homebrew-casks anymore then users will no longer be able to find our casks out of the box. The would have to actually go and find the AdoptOpenJDK repo, tap the repo using brew tap <repo> and only then would our casks appear.

[commitay]

If they executed brew search openjdk or brew search adoptopenjdk would they find them or do they need to add some sort of brew repository?

brew search won't work unless they have already tapped https://github.com/AdoptOpenJDK/homebrew-openjdk

I'd like to understand what an acceptable number of adoptopenjdk casks would be from a brew core maintainers perspective.

I was willing to accept the four casks that were proposed in the original PR, one for each major version of JDK and the equivalent of what we have for other Java upstreams.

[gdams]

I was willing to accept the four casks that were proposed in the original, one for each major version of JDK and the equivalent of what we have for other Java upstreams.

@commitay let's keep the 4 proposed casks in homebrew then?

[karianna]

OK, thanks for the answers - one follow up question. Is there the ability to produce output to the end user from a cask saying something like:

"Looking for another variant or version? Then brew tap adoptopenjdk to find the less common alternatives."

[commitay]

let's keep the 4 proposed casks in homebrew then?

This means that if you offer casks for the other versions they will be split across two repos.

As AdoptOpenJDK wants to support all versions I would strongly suggest keeping in the one tap for better UX and to allow you to ensure that they are deconflicted.

[gdams]

@commitay is there a way to auto tap additonal repos upon homebrew install? If the adoptopenjdk tap was auto "tapped" on homebrew install then I would not consider this a breaking change and the maintenance burdon would be taken away from the homebrew maintainers.

[commitay]

Keeping them like this will be confusing no matter how we try to work around it.

cask

• adoptopenjdk

versions

• adoptopenjdk8
• adoptopenjdk9
• adoptopenjdk10

adoptopenjdk tap

• adoptopenjdk-openj9
• adoptopenjdk-openj9-8
• adoptopenjdk-openj9-9
• adoptopenjdk-openj9-10
• adoptopenjdk-jre
• adoptopenjdk-jre-8
• adoptopenjdk-jre-openj9
• adoptopenjdk-jre-openj9-8

[commitay]

is there a way to auto tap additonal repos upon homebrew install?

We aren't going to auto tap something that is external to the Homebrew org.

[gdams]

We aren't going to auto tap something that is external to the Homebrew org.

Well then to me I see the value in keeping our existing casks in core.

[commitay]

Well then to me I see the value in keeping our existing casks in core.

Again, I strongly disagree. Having only one source for these casks will benefit your users.

[claui]

Leaving aside the confused-users risk for a minute, here’s a summary of all the options mentioned so far from a Homebrew maintainer’s perspective:

2018

#	Option	Hotspot JDKs	OpenJ9 JDKs	Hotspot JREs	Total AdoptOpenJDK Casks 2018
A	Remove AdoptOpenJDK	—	—	—	0
B	Status quo	11 LTS → cask 8 LTS, 9 → versions	—	—	3
C	PR #53976	11 LTS → cask 8 LTS, 9 → versions	11 LTS → cask	—	4
D	OpenJ9 parity	11 LTS → cask 8 LTS → versions	11 LTS → cask 8 LTS → versions	—	4
E	OpenJ9 parity + outdated	11 LTS → cask 8 LTS, 9, 10 → versions	11 LTS → cask 8 LTS, 9, 10 → versions	—	8
F	OpenJ9 parity + outdated + JREs	11 LTS → cask 8 LTS, 9, 10 → versions	11 LTS → cask 8 LTS, 9, 10 → versions	11 LTS → cask 8 LTS, 9, 10 → versions	12

2020

Two years from now (October 2020), I would expect this to become:

#	Option	Hotspot JDKs	OpenJ9 JDKs	Hotspot JREs	Total AdoptOpenJDK Casks by 2020
A	two years later	—	—	—	0
B	two years later	15 → cask 8 LTS, 11 LTS → versions	—	—	3
C	two years later	15 → cask 8 LTS, 11 LTS → versions	15 → cask 11 LTS → versions	—	5
D	two years later	15 → cask 8 LTS, 11 LTS → versions	15 → cask 8 LTS, 11 LTS → versions	—	6
E	two years later	15 → cask 8 LTS, 11 LTS, 12, 13, 14 → versions	15 → cask 8 LTS, 11 LTS, 12, 13, 14 → versions	—	12
F	two years later	15 → cask 8 LTS, 11 LTS, 12, 13, 14 → versions	15 → cask 8 LTS, 11 LTS, 12, 13, 14 → versions	15 → cask 8 LTS, 11 LTS, 12, 13, 14 → versions	18

[commitay]

Thanks @claui. Good points, as users installing from only this tap would expect the previous versions to be in our versions tap.

[karianna]

let's keep the 4 proposed casks in homebrew then?

This means that if you offer casks for the other versions they will be split across two repos.

As AdoptOpenJDK wants to support all versions I would strongly suggest keeping in the one tap for better UX and to allow you to ensure that they are deconflicted.

I agree but there is the crucial issue that the cask won't be discovered as a default. I'll give some quick background on what's going on with Java / OpenJDK so you understand our motivation here.

OpenJDK now has a new major version release every 6 months, with each 6th release (11, 17, 23 etc) being designated as an LTS release. Oracle produces both a commercial Oracle JDK build (you need to pay for this from day 1) and an Oracle OpenJDK build (which they only maintain for 6 months even if it's an LTS). So getting 'Java' for any platform (including brew) is no longer automatically $free or free (as in use).

AdoptOpenJDK was formed to ensure that there is a $free and free (as in use) 'Java' for all platforms, especially for LTS releases.

Large parts of the OpenJDK / Java ecosystem (a fair few million developers) are moving to AdoptOpenJDK binaries, many of course who develop on Mac OS X and use brew to manage their Java installs :-).

So our concern for the ecosystem is that "Joe/Jane Java" can no longer easily find a $free and free to use Java for their development needs which has some pretty serious knock-on effects.

---

I definitely don't want us to dump the burden of maintenance on the core brew committers. But I would like to see if there is a way where Java developers who use brew can automatically find the adoptopenjdk cask or at least be guided to install us via tap if they can't find us by default.

---

Thinking out loud here - is there a precedent for having a cask here which simply prints out the "go and brew tap adoptopenjdk"? Apologies if I'm using the wrong syntax here!

[karianna]

@claui - PS: I'm in awe of your table formatting skills in GitHub comments :-)

[commitay]

Thinking out loud here - is there a precedent for having a cask here which simply prints out the "go and brew tap adoptopenjdk"

Not really, we could make a fake cask (that would actually still be installable, just empty) that prints a message but it wouldn't be a good user experience and it would also be bad precedent for us to start adding such casks.

[karianna]

Thinking out loud here - is there a precedent for having a cask here which simply prints out the "go and brew tap adoptopenjdk"

Not really, we could make a fake cask (that would actually still be installable, just empty) that prints a message but it wouldn't be a good user experience and it would also be a bad precedent for us to start adding such casks.

OK, so auto tap and a message only cask are ruled out. I think the options we have left for users to find us by default are:

1. Only ever provide LTS JDK versions for brew, that are hosted at brew 'core'. e.g. Only ever have 8, 11, 17, 23 for Hotspot and OpenJ9. I think most of our users who are developers would find that too restrictive as they want to explore the non-LTS builds.

2. Splitting the casks across two taps, one hosted at brew core (just LTS JDK's for HotSpot and OpenJ9) and one hosted at adoptopenjdk (everything else).

Are there any other options that I'm missing? Any workarounds that you've seen other communities follow in situations like this?

[commitay]

I'd be fine with keeping one cask in this repo that tracks the current JDK version and has a caveat pointing to the external tap. The majority of our users are not Java developers so even offering two versions of the same JDK (Hotspot and OpenJ9) is confusing and doesn't align with what we offer for the other Java casks.

[karianna]

I'd be fine with keeping one cask in this repo that tracks the current JDK version and has a caveat pointing to the external tap. The majority of our users are not Java developers so even offering two versions of the same JDK (Hotspot and OpenJ9) is confusing and doesn't align with what we offer for the other Java casks.

That could work - let me have a chat with the rest of the Adopt team and I'll get back to you, might be 24 hours. Thanks for hearing us out!

[commitay]

$ brew cask info adoptopenjdk
adoptopenjdk: 11,28
https://adoptopenjdk.net/
Not installed
==> Name
AdoptOpenJDK
==> Artifacts
==> Caveats
More versions are available in the AdoptOpenJDK tap:
  https://github.com/AdoptOpenJDK/homebrew-openjdk

  brew tap adoptopenjdk/openjdk

The caveat will also be displayed when a user runs brew cask install adoptopenjdk or when brew cask upgrade is run and there is a upgrade for adoptopenjdk.

[commitay]

PR moving the casks in versions to the adoptopenjdk tap. AdoptOpenJDK/homebrew-openjdk#39

[karianna]

Hi all - this looks good to us, thanks for adding the caveat.