AdoptOpenJdk is deprecated on homebrew

[RussTedrake]

https://github.com/AdoptOpenJDK/homebrew-openjdk

Likely we'll need to update to temurin soon.

[RussTedrake]

Currently, homebrew gives this scary message:

russt@TRI-FVFG13URQ6LT drake % brew info adoptopenjdk
adoptopenjdk: 16.0.1,9
https://adoptopenjdk.net/
/opt/homebrew/Caskroom/adoptopenjdk/16.0.1,9 (196.9MB)
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/adoptopenjdk.rb
==> Name
AdoptOpenJDK Java Development Kit
==> Description
JDK from the Java User Group (JUG)
==> Artifacts
OpenJDK16U-jdk_x64_mac_hotspot_16.0.1_9.pkg (Pkg)
==> Caveats
Temurin is the official successor to this software:

  brew install --cask temurin

adoptopenjdk has been officially discontinued upstream.
It may stop working correctly (or at all) in recent versions of macOS.

==> Analytics
install: 2,064 (30 days), 5,928 (90 days), 40,387 (365 days)

[jwnimmer-tri]

Duplicate of #16404? Although possibly this ticket has more content.

[RussTedrake]

i did actually search... how I did not find that I do not know...

[jwnimmer-tri]

Possibly also worth noting -- the drake-lcm-spy program is the only thing we need Java for. If we re-implemented that as a Python GUI, we could drop Java from our build system (and the JDK dependency) entirely.

[svenevs]

we could drop Java from our build system (and the JDK dependency) entirely.

For drake, yes. drake-ci will always need it (Jenkins requires Java, currently it needs java8).

[jwnimmer-tri]

... drake-ci will always need it ...

If I recall correctly, Jenkins only needs a JRE not a full JDK?

[svenevs]

FYI noting for myself, there is a new problem with this package. The drake setup scripts on macOS will result in somebody asking adoptopenjdk@16, which is different than the one that drake-ci needs. CC @BetsyMcPhail right now when I provision images I

• Run drake-ci setup
• Run drake setup
• Uninstall adoptopenjdk and rerun drake-ci setup

xref #18597 we need the older version because of jenkins

[jwnimmer-tri]

If it helps, I think we can tell bazel to download a JDK from mirrors.bazel.build instead of using the host-provided one. That would allow removing the JDK from the "drake setup" entirely.

The only think we use the JDK for anyway is compiling the lcmtypes jar files and lcm-spy, so I don't think it's super-important to use the host one for that use case?

[svenevs]

If it helps, I think we can tell bazel to download a JDK from mirrors.bazel.build instead of using the host-provided one. That would allow removing the JDK from the "drake setup" entirely.

It's not clear to me if this would resolve the problem. I can re-double check on a fresh mac later this week. What sticks out to me is that drake-ci does adoptopenjdk8

https://github.com/RobotLocomotion/drake-ci/blob/1755ccd031d69488ac7fe086efd9e94263e29fd4/setup/mac/Brewfile#L41

but drake just does adoptopenjdk

https://github.com/RobotLocomotion/drake/blob/e4862e67622f855bb54f64bafb893595f3e81cf6/setup/mac/binary_distribution/Brewfile#L6

So it could be that the unless system part has stopped working? Can drake just use adoptopenjdk8?

Relevant context: as far as I can tell it either (a) only affects vSphere, or (b) we've yet to provision orka since whenever this became a problem. With vSphere part of the gurobi update I ran into this, and there's this insane bug with vSphere. For jenkins the adoptopenjdk is what is used to login, and when I re-provisioned the image it had a too new version. The result was that it would spin-start-up multiple VMs, none are able to connect, but none are removed. To make the matter worse, the vSphere UI only lets you delete one at a time. So it took almost 30 minutes to delete them and get the node to stop alarming, each time I tried, until I realized why it was happening.

We have the orka update scheduled for 9/19, so that seems like the right time to figure it out. And ideally, just continue not touching vSphere unless absolutely necessary.

[jwnimmer-tri]

Can drake just use adoptopenjdk8?

I probably didn't explain myself clearly. I think I could set some flags in our workspace rules, and then we will neither require nor use any JDK and/or JRE from the host system. The host could have JDK 1.2 from 1999 for all we care.

[svenevs]

xref https://github.com/RobotLocomotion/drake-ci/pull/249 we updated the drake-ci java version in conjunction with jenkins updates. drake still uses

https://github.com/RobotLocomotion/drake/blob/875b7859b74afebfd64fbeb088119bc8c8ead671/setup/mac/binary_distribution/Brewfile#L6

depending on the order of operations, this can cause conflicts, both adoptopenjdk and temurin install to the same /usr/bin/java. I observed some "interesting" behavior while provisioning / testing install and uninstall order. In CI our /usr/bin/java point to temurin's java, which will have nothing to do with adoptopenjdk.

We should, as a non-urgent follow-up, do something differently with drake's setup/.

I probably didn't explain myself clearly. I think I could set some flags in our workspace rules, and then we will neither require nor use any JDK and/or JRE from the host system. The host could have JDK 1.2 from 1999 for all we care.

If we simply remove adoptopenjdk, technically it is there in CI, but will not cause issues (as far as I know) if we do not re-provision images. That said, I'm happy to do so, just seems worth stacking with other orka updates if we can (e.g., sonoma).

[jwnimmer-tri]

Note to self. Here's the remote JDKs that we could tell Bazel to use:

https://github.com/bazelbuild/rules_java/blob/6.5.1/java/repositories.bzl

I should probably do that, so we can stop installing a system-wide JDK.