By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account
  • java8 : OracleJDK 8 (versions)
  • java10 : OracleJDK 10 (versions)
  • zulu7 : ZuluJDK 7 (versions)
  • zulu8 : ZuluJDK 8 (versions)
  • zulu9 : ZuluJDK 9 (versions)
  • Related cask: java-jdk-javadoc

    Open PRs:

  • sapmachine-jdk JDK 11
  • adoptopenjdk9 JDK 9 (versions)
  • Forthcoming PRs:

  • adoptopenjdk 8/10 (versions)
  • Dumping these all in one tap would make them easier to manage (naming/avoiding duplicates, postflight consistency/avoiding install conflicts, etc.) I'm expecting more variants now that building JDKs is a thing.

    I’m neutral on this one. I don’t think an extra tap is warranted, but I’m also not the one that typically manages the java casks, so I may not be considering the difficulty.

    I really don't get how having more taps makes them easier to manage

    It makes it easier to detect what’s abandoned and what’s managed.

    I think I’ve mentioned this before, but I like the idea of directories inside the tap. If that were possible, we could get the benefit of organisation without the disadvantage of extra taps.

    As all of them are basically hacks using postflights to install files, they could all have conflicts in /Library/Java/JavaVirtualMachines that need to be checked.

    Keeping the postflights consistent, e.g. moving rather than symlinking and plist modifications.

    Consistent naming for casks provided by different upstreams and multiple versions provided by the same upstream.

    Having them all in one place would make it much easier.

    I like the idea of directories inside the tap

    This could work but it wouldn't allow for rules that are tap specific, it would mean adding more rules to this tap.

    This could work but it wouldn't allow for rules that are tap specific, it would mean adding more rules to this tap.

    Yes, I don’t mean to replace taps entirely, but as an intermediary step (e.g. qlplugins, audioplugins, the java casks).

    I've kind of changed my mind on this as:

    brew cask install homebrew/cask-java/java

    is ugly and I think moving only some of the java casks to the tap is pointless.

    Closing again, sorry of the noise.

    Agreed the way that homebrew currently handle java version, or currently do no handle is a pain for developers. Some need multiple versions of java at a time. Currently this is impossible to do properly with homebrew only at this time.

    This is both confusing and frustrating user experience. A solution that is fine too could be to just not use homebrew to handle java versions, but that should be advertised like pointing to https://github.com/sdkman .