@jrm Ah, cool! Was worried I had forgotten about something. But I don't want to take credit for your work, so if you want to commit it yourself, that's probably better?

In D56125#1283835, @fuz wrote:

Now fails to build like so:

ERROR: Build failed for target 'images' in configuration 'bsd-ppc64le-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_precompiled_precompiled.hpp.pch:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/share/precompiled/precompiled.hpp:32:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/share/classfile/javaClasses.inline.hpp:28:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/share/classfile/javaClasses.hpp:28:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/share/classfile/vmClasses.hpp:30:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/share/runtime/handles.hpp:29:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/share/oops/oop.hpp:36:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/share/runtime/atomicAccess.hpp:859:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/os_cpu/bsd_ppc/atomicAccess_bsd_ppc.hpp:27:
In file included from /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/cpu/ppc/atomicAccess_ppc.hpp:33:
/wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/cpu/ppc/orderAccess_ppc.hpp:70:28: error: redefinition of 'loadload'
   70 | inline void   OrderAccess::loadload()   { inlasm_lwsync(); }
      |                            ^
/wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/src/hotspot/os_cpu/bsd_ppc/orderAccess_bsd_ppc.hpp:72:28: note: previous definition is here
   72 | inline void   OrderAccess::loadload()   { inlasm_lwsync(); }
      |                            ^
   ... (rest of output omitted)

* All command lines available in /wrkdirs/usr/ports/java/openjdk26/work-jdk/openjdk-jdk-26-35-2/build/bsd-ppc64le-server-release/make-support/failure-logs.
=== End of repeated output ===

In D56125#1283797, @fuz wrote:

In D56125#1283796, @haraldei wrote:

For some reason pkg thinks version 26+35.1_1 is greater than 26+35.2. Not sure how this will affect upgrades or the pkg builders?

You sure? My pkg says:

$ pkg version -t 26+35.1_1 26+35.2 
<

For some reason pkg thinks version 26+35.1_1 is greater than 26+35.2. Not sure how this will affect upgrades or the pkg builders?

@fuz If you have an ARM box I can use, that would be great. Otherwise I can set up a VM too. I will either have to work my way up from openjdk8, or see if I can use a jdk for another arch to bootstrap it. The latter should be possible, but I haven't done that before, so will have to explore a bit.

Thanks for the reviews!

In D55938#1279966, @jrm wrote:

Considering the diff [0] between this and java/openjdk25 is quite minimal, I think we're pretty safe.

In D55589#1271778, @fuz wrote:

LGTM. Please bump PORTREVISION for this kind of change. You can add that in when you land the fix.

Remove relnote info from pkg-descr

Thanks a lot!

Hi again, it would be nice if the review could be accepted sometime before OpenJDK 20 expires in two and a half weeks.
Let me know if there's anything that should be changed.

Rebase on main again for updated openjdk21

Is there anything else needed for this review, or could I get it accepted?

@jrm Awesome! Thanks!

@jrm Hoping it's because it's been a while, so rebased on main again and hope it works better now?

Rebase on main again

In D54731#1255008, @jrm wrote:

@haraldei, look at the diffs, nothing problematic stands out to me. I can do i386/amd64 build tests in about a day or so, if that's helpful. (I recently upgraded all my systems from 15 to 16-CURRENT, so all packages are rebuilding.)

In D54731#1254985, @fuz wrote:

LGTM, sorry for the delay.

I'd love to get some feedback on this one.

Thank you for the review!

• Change order of bootstrap variables based on feedback

If I could get a review on this patch today, it would be really helpful. As java/openjdk18 is expiring today, we need this in place to be able to build any of the jdks from 19 and up.

In D54608#1247967, @michaelo wrote:

In D54608#1247947, @haraldei wrote:

In D54608#1247892, @michaelo wrote:

Where does openjdk19-19.0.2+7.1_4.${JDK_ARCH}.tar.xz come from and how is it produced?

From pkg.freebsd.org. It's the release pkg file that has been extracted, moved to the boot-jdk directory and compressed and packed with tar. The only exception is the ppc64(le) tarballs as there's no official packages of these, so they are built by pkubaj@.

It seems that the port will never be selfcontained in the ports tree, no?

The OpenJDK ports were never self contained. They either depended on the port of the previous version, or in some cases a bootstrap-jdk that was installed to the system. The main difference in this approach is that we don't rely on the previous jdk, and we don't install the bootstrap-jdk to the system.

I see, it applies the Münchhausen trilemma which is logically flawed, but we cannot change it.

In D54608#1247892, @michaelo wrote:

Where does openjdk19-19.0.2+7.1_4.${JDK_ARCH}.tar.xz come from and how is it produced?

• java/openjdk19: Update bootstraps + add ppc64

In D54176#1244617, @michaelo wrote:

I think this should have happened *after* new bootstrap ports have emerged...

In D54176#1238034, @vvd wrote:

But there is no bootstrap in the ports for either 21 or 25.

I feel this is no longer relevant, as the target version is deprecated. Will close and reopen for relevant OpenJDK versions when time permits.

Thanks a lot for the reviews!

• java/openjdk*: expiration date + portrevision

@bofh Thanks! That's exactly the kind of feedback I was looking for.

In D53975#1235259, @fuz wrote:

Patch looks fine. Approved for commit once you feel like you have tested it sufficiently.

In D53975#1234044, @fuz wrote:

In D53975#1233980, @haraldei wrote:

In D53975#1233152, @fuz wrote:

For testing, the gold standard is to build the port and execute the test suite on as many platforms we support as possible, on all currently supported OS versions (that is, 13.5, 14.3, and 15.0).

Do I have access to, and can I use the ref*-machines for that?

As far as I know, there are no resources for that.

For posterity, the current test results for AMD64:

In D53975#1233152, @fuz wrote:

For testing, the gold standard is to build the port and execute the test suite on as many platforms we support as possible, on all currently supported OS versions (that is, 13.5, 14.3, and 15.0).

I don't really have a strong opinion on this change, but if it fixes the issue for now, I'm good with it. Technically I don't think the bootstrap JDK needs X11 to build the target JDK, but since they packaged the full JDK including libawt_xawt.so at the time it is now flagged with the new change to pkg.

I've been thinking a bit more about this, and wrote up some of my thoughts here: https://kodeknekkeriet.net/en/blog/introducing-flavors-in-openjdk-freebsd/

Thanks for the reviews and help!

Rebased to main and:

@fuz There's really no problem with installing all flavors at the same time, except for bloat of course. It was @jrm who wanted me to look into the CONFLICTS_INSTALL stuff. For now I think I'll just revert that, and look back into it if needed later.

The commit message was not included, so here's a description instead:

• java/openjdk25: Fix more review comments
• java/openjdk25: Fix lib dependencies and flavor matchers
• java/openjdk25: Add CONFLIGS_INSTALL

In D53807#1229879, @fernape wrote:

In D53807#1229368, @haraldei wrote:

Not sure if it belongs in the java category, though... Perhaps security instead?

Yeah, you're right. Dropping java as category.

Not sure if it belongs in the java category, though... Perhaps security instead?

In D53782#1228128, @lwhsu wrote:

And in ports we probably cannot only checks for ${JAVA_HOME}/bin/java and think it's the full version, need to check for something only available in full version but not in headless version.

This is a good point!

Think I fixed all issues now.

• java/openjdk25: Fix minor typo causing wrong pkg name

• java/openjdk25: Fix review comments

In D53707#1226353, @fuz wrote:

Looks reasonable. I trust you to have tested this change well.

In D53450#1222561, @fuz wrote:

Looks good to me. Please proceed with a commit.

The reason I was able to run tuxguitar (a gui app) under the -headless variant was that it bundles swt.jar which dynamically loads gtk. The -headless variant only affects awt based apps.

• java/openjdk25: Update with comments for review

Obsoleted by https://cgit.FreeBSD.org/ports/commit/?id=1019f032bb79414f19b7f7c120905782ed2392db

I discovered during testing that it seems the headless build happyly also runs gui programs. That's not as intended, so I'll have to explore that before pushing this in any case.

In D53450#1221235, @jrm wrote:

If you really wanted to try to make portlint happy, you could replace the .if ${FLAVORS:U} instances with flavor helpers (e.g., jre_USES=...), but that seems like busy work for little benefit.

Hopefully the commit message is better now. Used the template so field should be in order and values align, though it's not visible in the differential summary.

java/openjdk25: New port

java/openjdk25: New port