RFR: 8233995: java.vm.vendor (and potentially other properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8

[Andrew John Hughes]

On 12/11/2019 13:01, Langer, Christoph wrote:
> Hi,
> 
> please review and approve the following change that affects Windows builds of OpenJDK 8. It is an OpenJDK8 specific fix. In later JDKs, the build system was completely changed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233995
> Webrev (for hotspot): http://cr.openjdk.java.net/~clanger/webrevs/8233995.8u.0/
> 
> The problem is that for Windows builds the System property java.vm.vendor is empty. It doesn't matter whether the configure option --with-vendor-name is used or not. The problem is that the variables from configure don't get passed correctly to the hotspot build.
> 
> I fixed this by passing the needed variables in make/windows/makefiles/defs.make via MAKE_ARGS. Furthermore, in make/windows/makefiles/vm.make, the defines VENDOR, VENDOR_URL, VENDOR_URL_BUG and VENDOR_URL_VM_BUG for the C/C++ compilations will only be set if the variables have a value. This is because otherwise those would override expected default values from inside the hotspot code. With that change, the Windows build will behave more like the Unix/Linux builds do already.
> 
> BTW, the problem can be observed in the current AdoptOpenJDK builds. Amazon Corretto seems to have a workaround for this problem (a hard coded vendor string in the makefile).
> 
> Thanks
> Christoph
> 

Indeed, the build system did change in OpenJDK 9 with "JDK-8150601:
Remove the old Hotspot build system". As JDK-8189761: COMPANY_NAME,
IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag" occurred
later than this, the HotSpot parts of the 8189761 had to be constructed
from scratch when I backported it. Not having access to Windows myself,
I'm reliant on others to test the changes there and report breakage.

Looking over this patch, and comparing with what we do for
AIX/Solaris/BSD/Linux in 8189761, I have two questions:

1. We echo the values of VENDOR, VENDOR_URL, VENDOR_URL_BUG and
VENDOR_URL_VM_BUG to local.make in build.make, in much the same way as
buildtree.make does for the other platforms. Any idea why that is not
sufficient and these need to be also added to defs.make? If the
build.make variables aren't being set, that has an impact for other
variables too. I notice ZIPEXE is in both places, with no checks in the
defs.make case:

hotspot/make/windows/build.make:        @ if "$(ZIPEXE)" NEQ "" echo
ZIPEXE=$(ZIPEXE)           >> $@
hotspot/make/windows/makefiles/defs.make:MAKE_ARGS += ZIPEXE=$(ZIPEXE)

If possible, it would be better to fix the underlying issue rather than
papering over it.

2. The checks added in vm.make are done by configure for the other
builds and assembled into VERSION_CFLAGS. To avoid duplication  in
vm.make, is it possible to just use VERSION_CFLAGS there as the other
systems do? If Windows can't handle the -D syntax that uses, maybe a
better solution is to setup VERSION_WINFLAGS in the same place with the
correct syntax?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew