Thanks Harald!

Thanks. I'm working through these too, so let me know what else you have planned (I've committed the JDK8 update and have the JDK17 one building)

LGTM

In D49354#1125699, @haraldei_anduin.net wrote:

In D49354#1125564, @emaste wrote:

Is there a reason not to apply (some of) the patches in the repo directly?

The PPC one could probably be applied to the base repo. I'll look into it. The others seem to be to be about making the build modifiable by the port system, so I don't see that these changes belong in the repo as they are now. We could try to move these changes properly into params to the configure scripts instead.

In D48194#1100442, @jrm wrote:

@arrowd, thanks for catching those things. I believe Harald will investigate the original reasons for setting LOCALE to C and test with the default locale.

It might help to get a look at the hs_err_pidXXXX.log file from the build to see more details about the error, but that won't affect this change. FWIW I believe that upstream have flagged that they are removing support for x86 in Java 25, so given that Java 23 isn't an LTS release (and 25 is the next LTS release) it probably isn't worth the effort to fix it.

Good to see this change. I'm not all that familiar with the Make infrastructure, so my review perhaps isn't all that helpful, but this looks good to me. FWIW, the USES_JAVA=<version> stuff has been deprecated in favour of JAVA_VERSION=<version> for a long time, so hopefully there isn't much of that left.

I think the main thing from my point of view is to fix the regex in bsd,java,mk

How widely was this tested? The JDK can be finicky about memory management

Looks good to me

Not sure why this was abandoned, but the change looks good to me

This version looks good to me. Thanks!

In D42720#974511, @otis wrote:

In D42720#974504, @michaelo wrote:

In D42720#974495, @otis wrote:

I don't object either. Nevertheless it seems to me that this should be performed in post-install-LOCALBASE_CACERTS-on within the STAGEDIR. What's your thought?

While I agree with you, I have chosen the approach from TZUPDATE for consistency reasons.

Maybe @glewis can make it clear why this approach was chosen.

In D42130#965494, @otis wrote:

A very friendly ping? :-)

In D42130#963017, @glewis wrote:

I think this could be a lot simpler

I think this could be a lot simpler