Ability to install specific builds of a JDK?

[nskobelevs]

I was wondering whether it's possible to extend these casks to allow users to install a specific of JDKs?

I've had a few instances where I've ran into bugs on the latest JDK build where the only build is to downgrade to a previous build until the issue is fixed on the latest release. It would be nice to be able to install older versions through brew (e.g. [email protected]) instead of having to manually install the version through the dmg.

Example Issue which requires downgrading

[mdogan]

I think it's possible to keep all versions as separate casks. That will require a few changes to the updater app. I can try to implement this when I have some free time, but can't promise when unfortunately. As always all contributions are welcome.

[nskobelevs]

I had a look at updater and while I can't make any promises, I am interested to look into this further.

There are a few things to discuss though.

Version Definitions Firstly I couldn't find any homebrew documentation on this but it seems that versioning this way just means having a separate cask definitions for each version? For example I'm seeing [email protected], [email protected], etc in the homebrew-core repo (I'm assuming it wouldn't be any different for casks). Am I right to understand then that updater needs to output a .rb file for every version Zulu has? So we'd have [email protected], [email protected] etc?

Default Version Even with separate versions available we would still like zulu-jdk17 to work and install the latest version available. homebrew-core has an Aliases folder which seems to allow to reference another formula - I'll explore whether this works for casks (e.g. python3 referencing most latest python version)

Double Versioning Having a cask be like [email protected] feels clunky given the double versioning. Is there scope for simplifying the cask to zulu-jdk with version afterwards? Again it might be possible to use aliases to keep the old names - so zulu-jdk17 aliases to zulu-jdk@17.<latest>

Conflicts The Zulu .pkg's currently install in /Library/Java/JavaVirtualMachines/zulu-{version}.jdk meaning it's not possible to install multiple minor versions of the same major JDK version. (e.g having 17.0.7 and 17.0.6 side-by-side)

I don't know is this is something you want to support or how often someone might need to have multiple minor versions but it might be possible by switching to .tar.gz and manually unpacking in e.g. .../zulu-17.0.7.jdk. However I'm not sure about the logistics of this in the context of homebrew given the uninstall action is now different and whether that affects users who installed previous to the change.

off-topic:

Zulu API I've roughly figured out how the API works and how to get versions from the updater code but I'm having a lot of trouble find documentation on their Discovery API - it seems they've migrated to their Metadata API with the only reference to the old Discovery API being their article Migrate from Zulu OpenJDK Discovery API to Azul Metadata API. While I wasn't able any indication that the Discovery API is planned to be deprecated, I was wondering if this migration would be benificial?

[JakeWharton]

it seems that versioning this way just means having a separate cask definitions for each version?

That is my understanding. They abandoned versioning a long time ago so this is basically a trick to emulate it.

homebrew-core has an Aliases folder which seems to allow to reference another formula - I'll explore whether this works for casks

Cool! This definitely sounds desirable.

I'm curious what happens when you install a specific version and then the alias. Does it no op? Then then if you uninstall the specific version it should also be a no op as the alias is still "installed".

Or here's another one: you install a specific version and the alias, and then the alias changes. Does upgrade install the newer version and keep the old?

I assume so, but we should test it.

Having a cask be like [email protected] feels clunky given the double versioning.

I don't hate this, but if we are doing aliases perhaps we can start with [email protected] for the specific versions and worry about migrating the existing names to @17 and such later.

it might be possible by switching to .tar.gz

That would have been my suggestion.

I think we can also install into ~/Library directory rather than /Library, but maybe that discussion is for another time. It would avoid sudo.

I was wondering if this migration would be benificial?

Let's either do it before or after as a separate change. But sounds like it is the direction they are going.

[nskobelevs]

I'm curious what happens when you install a specific version and then the alias. Does it no op? Then then if you uninstall the specific version it should also be a no op as the alias is still "installed". Or here's another one: you install a specific version and the alias, and then the alias changes. Does upgrade install the newer version and keep the old? I assume so, but we should test it.

From exploring brew source code my understanding is that aliases are only used when trying to resolve a formula name passed as argument to brew to an actual formula definition after which it's indifferentiable from a non-alias. The aliases aren't separate formula either - they don't know up on brew list for example. So my understanding is that the answer to any of these questions is essentially what you would expect to happen if you the user used the fully qualified name instead of the alias.

e.g. brew install [email protected] followed by brew install python3 is a warning since python3 resolves to [email protected] which is already installed.

After installation there is no reference to the alias - [email protected] is the formula installed. When a new python version comes out and the python3 alias gets bumped to [email protected] you won't be able to uninstall your [email protected] using python3 alias since it'll resolve to [email protected].

The Aliases folder only works for formulae and not casks.

I created an Alias for one of these casks and it was unable to resolve it - however trying to install it without --cask the alias was properly resolved but it threw an error given it expected a formula definition and not a cask one. This lack of support can be partially confirmed from the docs where the Formula Cookbook states "Add aliases by creating symlinks in an Aliases directory in the tap root." while the Cask Cookbook makes no such mention.

it might be possible by switching to .tar.gz That would have been my suggestion.

I think this might be the way to go at some stage as like you said it prevent requiring sudo but also if installation is moved to ~/Library could this be converted to a formula instead of a cask? (Or are there other home-brew limitations forcing this to be a cask other than the .pkg install?) Moving a formula could open up the use of Aliases

Let's either do it before or after as a separate change. But sounds like it is the direction they are going.

I'll take a look at the migration article and perhaps do the migration before the versioning

[JakeWharton]

So my understanding is that the answer to any of these questions is essentially what you would expect to happen if you the user used the fully qualified name instead of the alias.

Okay. That makes sense. But also means it sounds like a non-starter for use here. Ultimately it's not that big of a deal since 100% of the files are generated rather than hand-written.