openjdk## ports should be meta ports

[zman0900 (Dan Ziemba)]

The openjdk ports were previously meta packages, but now are not and also depend on "openjdk##-bootstrap". As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".

Now if I want to use "openjdk17-temurin" and also have, for example, "dbeaver-community" installed (dependency on "openjdk17"), my system ends up with 3 separate JDKs installed - "/Library/Java/JavaVirtualMachines/" contains "openjdk17", "openjdk17-bootstrap", and "openjdk17-temurin".

[usersxx]

I can't change it back to openjdk17 meta port but I can update the dbeaver-community portfile to add support for openjdk17 port. openjdk17 port builds from non-modified source code, thus providing a totally unmodified OpenJDK unlike any vendor. Moreover, I had changed from the openjdk meta ports to these type of openjdk ports as they are mentioned on official OpenJDK BSD port project for the old openjdk6 port (​https://wiki.openjdk.java.net/display/BSDPort).

[breun (Nils Breunese)]

As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".

I don't think the user could actually choose which implementation to use, although that would be nice. Before openjdk11 and openjdk17 would just install a particular OpenJDK distribution (Eclipse Temurin on x86_64, Azul Zulu on arm64).

[usersxx]

Replying to breun:

As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".

I don't think the user could actually choose which implementation to use, although that would be nice. Before openjdk11 and openjdk17 would just install a particular OpenJDK distribution (Eclipse Temurin on x86_64, Azul Zulu on arm64).

You can just install azul zulu by using sudo port install openjdk11-zulu and sudo port install openjdk17-zulu. You can install eclipse temurin by using sudo port install openjdk11-temurin and sudo port install openjdk17-temurin.

[breun (Nils Breunese)]

Replying to usersxx:

Replying to breun:

As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".

I don't think the user could actually choose which implementation to use, although that would be nice. Before openjdk11 and openjdk17 would just install a particular OpenJDK distribution (Eclipse Temurin on x86_64, Azul Zulu on arm64).

You can just install azul zulu by using sudo port install openjdk11-zulu and sudo port install openjdk17-zulu. You can install eclipse temurin by using sudo port install openjdk11-temurin and sudo port install openjdk17-temurin.

Yes, you can do those things, but a port cannot specify that it depends on 'some JDK 11' or 'some JDK 17'. A port can only depend on a specific JDK implementation, or it can use the java.version and java.fallback properties from the java PortGroup, but those always use the openjdk{major} ports. It would be nice if ports could indicate that they depend on a port which provides the 'Java 17' capability, without a hardcoded dependency on a specific port, so that if you already have for instance Eclipse Temurin 17 or Azul Zulu 17 or SapMachine 17 installed, the dependency is satisfied and not another JDK needs to be installed.

[zman0900 (Dan Ziemba)]

Yeah, I think I have confused how this used to work with another system's package manager, such as the "provides" capability of Arch's pacman.

[usersxx]

As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".

I don't think the user could actually choose which implementation to use, although that would be nice. Before openjdk11 and openjdk17 would just install a particular OpenJDK distribution (Eclipse Temurin on x86_64, Azul Zulu on arm64).

You can just install azul zulu by using sudo port install openjdk11-zulu and sudo port install openjdk17-zulu. You can install eclipse temurin by using sudo port install openjdk11-temurin and sudo port install openjdk17-temurin.

Yes, you can do those things, but a port cannot specify that it depends on 'some JDK 11' or 'some JDK 17'. A port can only depend on a specific JDK implementation, or it can use the java.version and java.fallback properties from the java PortGroup, but those always use the openjdk{major} ports. It would be nice if ports could indicate that they depend on a port which provides the 'Java 17' capability, without a hardcoded dependency on a specific port, so that if you already have for instance Eclipse Temurin 17 or Azul Zulu 17 or SapMachine 17 installed, the dependency is satisfied and not another JDK needs to be installed.

Actually, java.version checks if a specific JDK version is installed or not. If a Installed JDK fulfils java.version, MacPorts will use it. If there is no JDK that fulfils java.version, java.fallback will be installed

[catap (Kirill A. Korinsky)]

Right now -zulu ports are required for M1 machine.

For example I have a clean macOS 12 M1 machine where I'm installing maven3 and it fails:

catap@Kirills-mini-m1 ~ % sudo port install maven3
--->  Computing dependencies for maven3
The following dependencies will be installed: 
 autoconf
 bash
 gettext
 gettext-runtime
 gettext-tools-libs
 gmake
 libiconv
 libtextstyle
 m4
 maven_select
 ncurses
 openjdk11
 openjdk11-zulu
Continue? [Y/n]: y
...
--->  Verifying checksums for openjdk11                                              
--->  Extracting openjdk11
--->  Configuring openjdk11
Error: Failed to configure openjdk11: consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk11/openjdk11/work/jdk-11.0.15+10/config.log
Error: Failed to configure openjdk11: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk11/openjdk11/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port maven3 failed
--->  Some of the ports you installed have notes:
  openjdk11-zulu has the following notes:
    If you have more than one JDK installed you can make openjdk11-zulu the default
    by adding the following line to your shell profile:
        export JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk11-zulu/Contents/Home
catap@Kirills-mini-m1 ~ % 

the same happened with sbt:

catap@Kirills-mini-m1 ~ % sudo port install sbt                                                                                                           
--->  Computing dependencies for sbt 
The following dependencies will be installed: 
 autoconf
 bash
 brotli
 bzip2
 cctools
 freetype
 gettext
 gettext-runtime
 gettext-tools-libs
 gmake
 libiconv
 libpng
 libtextstyle
 m4
 ncurses
 openjdk8
 openjdk8-bootstrap
 pkgconfig
 xz
 zlib
Continue? [Y/n]: y
...
--->  Extracting openjdk8
--->  Applying patches to openjdk8
--->  Configuring openjdk8
--->  Building openjdk8                                  
Error: Failed to build openjdk8: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk8/openjdk8/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port sbt failed
catap@Kirills-mini-m1 ~ % 

To be honest I think that this is a major issue for new users who attempts to install sbt or maven3 and move away from MacPorts.

[lilvadim (Vadim)]

I have the same output while trying to install gradle package. It was installed in my system before but then update started failing because of this issue and I decided to completely reinstall openjdk8 and dependents, but issue still appears.

[breun (Nils Breunese)]

I think it would be good to create a separate issue against openjdk8 for the disappeared ARM64 support. openjdk8 indeed used to support ARM64 when it was still a ports delegating to other ports, but I think this support was lost with the switch to build OpenJDK from source for openjdk8.

Not a real solution, but maybe a workaround for now: can you remove openjdk and install openjdk8-zulu explicitly first and then install gradle?