RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Langer, Christoph]

Hi,

I had to update my change a little bit – I forgot to exclude jimage.map, 
java.map and jpackage.map when copying the cmd debug symbols in Images.gmk.

Furthermore, I needed to modify tests jdk/tools/launcher/TestHelper.java and 
jdk/tools/launcher/VersionCheck.java to cope with debug symbol files in 
images/jdk/bin on non Windows platforms.

http://cr.openjdk.java.net/~clanger/webrevs/8237192.2/

Cheers
Christoph

From: Langer, Christoph
Sent: Montag, 17. Februar 2020 10:17
To: Erik Joelsson ; Magnus Ihse Bursie 
; 'build-dev@openjdk.java.net' 

Cc: 'hotspot-...@openjdk.java.net' ; Baesken, 
Matthias 
Subject: RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk 
images

Hi Erik,

thanks for your review. While I’ve addressed all your points (thanks for the 
great hints regarding usage of SetupCopyFiles), I also enhanced the configure 
option a little bit.

What you can now pass is --with-external-symbols-in-bundles=. 
Default setting is none. It’ll require --with-native-debug-symbols=external 
obviously and is currently only implemented for Windows. This is checked in 
configure.
Depending on the value used, the bundles and jmods will contain either no pdbs, 
public pdbs or the full pdbs. This configure option could easily be enhanced to 
work for Linux/Unix/Mac as well – but I didn’t want to go too far with my 
change now.

What also comes with my change is debug files for executables (launchers, cmds) 
in images/ which weren’t copied so far in Images.gmk. It’s however 
needed because bundles are created from these images and with the current 
bundle logic, stripped pdb files need to exist in images/… to get bundled for 
option ‘public’.

I also removed the special handling of the pdb file for java.exe in 
Launcher-java.base.gmk, as the filtering to make sure it’s not overwriting the 
pdb for java.dll has to be done in CreateJmods.gmk and Images.gmk anyway.

Eventually, when this is all refactored, one should probably generate the pdb 
files to ship into support/modules_libs and support/modules_cmds and only in 
the case of public pdbs redirect generation of the full pdbs to something like 
support/modules_libs_full_debug_info or something like that. Then, from 
support/modules_libs and support/modules_cmds, one should generate the base 
image via jlink which can simply be packed into the shipment bundle. And the 
other image with all debug/demos can be created by copying the base image and 
then applying the stuff from support/ modules_libs_full_debug_info etc.

Here's the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237192.1/

Best regards
Christoph


From: Erik Joelsson mailto:erik.joels...@oracle.com>>
Sent: Mittwoch, 12. Februar 2020 23:17
To: Langer, Christoph 
mailto:christoph.lan...@sap.com>>; Magnus Ihse Bursie 
mailto:magnus.ihse.bur...@oracle.com>>; 
'build-dev@openjdk.java.net' 
mailto:build-dev@openjdk.java.net>>
Cc: 'hotspot-...@openjdk.java.net' 
mailto:hotspot-...@openjdk.java.net>>; Baesken, 
Matthias mailto:matthias.baes...@sap.com>>
Subject: Re: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk 
images


Hello Christoph,

This patch certainly looks better to me, though I agree it's a bit hackish to 
have to filter and rename the stripped.pdb files twice, once for jmods and 
again for bundles. I think I'm ok with it for now though. The future 
improvement I would like to make would be to create two sets of jdk images, one 
that contains debug symbols and demos, which we continue to use for testing, 
and another which only contains exactly what we bundle up, including the 
correctly named top dir. The latter would be created first and used as input 
for the former. I think lots of things would be cleaner then, especially 
Bundles.gmk.

But, that can wait for later. With your current proposal, my proposed future 
change will apply seamlessly in regard to the stripped pdb files and our 
distribution bundles.

The clash between launchers and libs is annoying, and we also have it for 
java.exe and java.dll already, though the build is explicitly handling that one 
somewhere else.

Now to review, there are some details I will nitpick about.

CreateJmods.gmk:

174, 185: Rule declarations should be indented like any other line inside 
conditionals. But, I have a problem with these rules as the target is the 
directory. This will not work well with incremental builds. I would recommend 
doing a SetupCopyFiles construct instead so you get individual rules for each 
file. It would look something like this:
rename-stripped-pdb = \
$(patsubst %.stripped.pdb,%.pdb,$1)
$(eval $(call SetupCopyFiles, COPY_STRIPPED_LIBS, \
SRC := $(LIBS_DIR), \
DEST := $(LIBS_DIR_STRIPPED), \
FILES := $(call FindFiles, $(LIBS_DIR)), \
NAME_MACRO := rename-stripped-pdb, \
))

DEPS += $(COPY_STRIPPED_LIBS)

For the corresponding CMD_DIR, the removal of jimage and friends can be done 
with $(filter ) around The FindFiles call.

GenerateLinkOptData.gmk:

Please i

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[Kim Barrett]

> On Feb 16, 2020, at 2:58 PM, John Paul Adrian Glaubitz 
>  wrote:
> 
> Hi Kim!
> 
> On 2/15/20 10:30 PM, Kim Barrett wrote:
>> I prefer the approach using a non-ODR-used dummy to the approach of
>> casting of some random number to an address.  Non-ODR-used
>> declarations are well supported by the standard (C++03 3.2) and widely
>> used; that's the basis for the "sizeof trick" metaprogramming idiom,
>> for example.
> 
> I've now understood that approach and implemented it. Please see my patch in 
> [1].
> 
> FWIW, I have tried to put the declaration of RegistersForDebugging outside
> the X_offset() functions but that doesn't work. Hope the change is now
> okay as is :).
> 
> Adrian
> 
>> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.02/

Nope.  That unnecessarily pollutes the global namespace with “dummy_regs”.

The dummy declaration should be in the RegistersForDebugging class as I 
suggested earlier.
But you say that “doesn’t work”.  I thought perhaps that meant I’d made was a 
mistake in the
code snippet I’d sent, but that seems to work for me.  So what do you mean by 
“doesn’t work”?

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[John Paul Adrian Glaubitz]

On 2/18/20 4:55 PM, Kim Barrett wrote:
> Nope.  That unnecessarily pollutes the global namespace with “dummy_regs”.
> 
> The dummy declaration should be in the RegistersForDebugging class as I 
> suggested earlier.
> But you say that “doesn’t work”.  I thought perhaps that meant I’d made was a 
> mistake in the
> code snippet I’d sent, but that seems to work for me.  So what do you mean by 
> “doesn’t work”?

Ah, I completely missed that mail and the code snippet. Sorry.

I forgot to use a reference type when I tried the definition within the class
which is why it failed for me. I will test the proper approach and post a
patch in a few minutes.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[John Paul Adrian Glaubitz]

Hi Kim!

On 2/18/20 5:07 PM, John Paul Adrian Glaubitz wrote:
> I forgot to use a reference type when I tried the definition within the class
> which is why it failed for me. I will test the proper approach and post a
> patch in a few minutes.

Here's the patch with the changes as you suggested [1].

Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.03/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8239026: Support non-maven artifacts by JibArtifactManager

[Erik Joelsson]

Looks good.

/Erik

On 2020-02-13 17:44, Leonid Mesnik wrote:

Hi

Could you please review following fix which extend JibArtifactManager to 
support download and installation of artifacts with layout different from maven 
style.
It is planned that user provide name and properties to resolve layout using 
default or jib manager. There are no tests which use this customization  
currently added in the testbase. So there is no good interface like Artifact 
annotation is added.

webrev: http://cr.openjdk.java.net/~lmesnik/8239026/webrev.00/ 

bug: https://bugs.openjdk.java.net/browse/JDK-8239026 


Leonid

Re: RFR: 8237566: FindTests.gmk should only include existing TEST.ROOT files

[Erik Joelsson]

Looks good.

/Erik

On 2020-02-14 05:51, Erik Helin wrote:

On 2/13/20 6:21 PM, Erik Joelsson wrote:

Hello Erik,

Looks good.


Thanks for reviewing!

On 2/13/20 6:21 PM, Erik Joelsson wrote:
Style wise I try to put closing braces for logical blocks on a new 
line, aligned with the opening brace. I think that helps making the 
already quite convoluted makefile logic a tad more readable.


Ok, sure, no problem. I moved the closing brace onto a new line 
(aligned with the opening brace). Please see new webrevs below:


Webrevs:
- full: http://cr.openjdk.java.net/~ehelin/8237566/01/
- inc: http://cr.openjdk.java.net/~ehelin/8237566/00-01/

Thanks,
Erik


/Erik

On 2020-02-13 04:44, Erik Helin wrote:

Hi all,

this small patch changes FindTest.gmk to only include TEST.ROOT 
files that actually are present. The motivation for this change is 
that both Git and Mercurial supports so called "sparse" checkouts 
[0][1] (still somewhat experimental for both, but actively worked 
on). While experimenting with these features I noticed that 
FindTests.gmk demands that 
test/{jtreg,jdk,langtools,nashorn,jaxp}/TEST.ROOT are present even 
if you are only trying to run e.g. `make hotspot`. This small patch 
ensures that we only include TEST.ROOT files that actually exist on 
disk.


Webrev:
https://cr.openjdk.java.net/~ehelin/8237566/00/

Issue:
https://bugs.openjdk.java.net/browse/JDK-8237566

Testing:
- Tier 1,2,3 on Linux, macOS, Windows (all x64)

Thanks,
Erik

[0]: https://www.mercurial-scm.org/repo/hg/file/tip/hgext/sparse.py
[1]: 
https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/ 



PS. For the curious, I did manage to create a minimal working 
directory for hotspot using git version 2.25 (with this patch applied):


$ git clone https://github.com/openjdk/jdk --no-checkout
$ cd jdk
$ git sparse-checkout init --cone
$ git sparse-checkout set make src/java.base src/hotspot
$ curl 
https://cr.openjdk.java.net/~ehelin/8237566/00/JDK-8237566.patch | 
git apply

$ bash configure
$ make hotspot

Re: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Erik Joelsson]

Hello Christoph,

Thanks for hanging in there, this is now looking good to me. Nice to see 
a more general solution to the java.pdb problem.


/Erik

On 2020-02-18 06:47, Langer, Christoph wrote:


Hi,

I had to update my change a little bit – I forgot to exclude 
jimage.map, java.map and jpackage.map when copying the cmd debug 
symbols in Images.gmk.


Furthermore, I needed to modify tests 
jdk/tools/launcher/TestHelper.java and 
jdk/tools/launcher/VersionCheck.java to cope with debug symbol files 
in images/jdk/bin on non Windows platforms.


http://cr.openjdk.java.net/~clanger/webrevs/8237192.2/

Cheers

Christoph

*From:*Langer, Christoph
*Sent:* Montag, 17. Februar 2020 10:17
*To:* Erik Joelsson ; Magnus Ihse Bursie 
; 'build-dev@openjdk.java.net' 

*Cc:* 'hotspot-...@openjdk.java.net' ; 
Baesken, Matthias 
*Subject:* RE: RFR: 8237192: Generate stripped/public pdbs on Windows 
for jdk images


Hi Erik,

thanks for your review. While I’ve addressed all your points (thanks 
for the great hints regarding usage of SetupCopyFiles), I also 
enhanced the configure option a little bit.


What you can now pass is 
--with-external-symbols-in-bundles=. Default setting 
is none. It’ll require --with-native-debug-symbols=external obviously 
and is currently only implemented for Windows. This is checked in 
configure.


Depending on the value used, the bundles and jmods will contain either 
no pdbs, public pdbs or the full pdbs. This configure option could 
easily be enhanced to work for Linux/Unix/Mac as well – but I didn’t 
want to go too far with my change now.


What also comes with my change is debug files for executables 
(launchers, cmds) in images/ which weren’t copied so far in 
Images.gmk. It’s however needed because bundles are created from these 
images and with the current bundle logic, stripped pdb files need to 
exist in images/… to get bundled for option ‘public’.


I also removed the special handling of the pdb file for java.exe in 
Launcher-java.base.gmk, as the filtering to make sure it’s not 
overwriting the pdb for java.dll has to be done in CreateJmods.gmk and 
Images.gmk anyway.


Eventually, when this is all refactored, one should probably generate 
the pdb files to ship into support/modules_libs and 
support/modules_cmds and only in the case of public pdbs redirect 
generation of the full pdbs to something like 
support/modules_libs_full_debug_info or something like that. Then, 
from support/modules_libs and support/modules_cmds, one should 
generate the base image via jlink which can simply be packed into the 
shipment bundle. And the other image with all debug/demos can be 
created by copying the base image and then applying the stuff from 
support/ modules_libs_full_debug_info etc.


Here's the new webrev: 
http://cr.openjdk.java.net/~clanger/webrevs/8237192.1/ 



Best regards

Christoph

*From:*Erik Joelsson >

*Sent:* Mittwoch, 12. Februar 2020 23:17
*To:* Langer, Christoph >; Magnus Ihse Bursie 
>; 'build-dev@openjdk.java.net' 
mailto:build-dev@openjdk.java.net>>
*Cc:* 'hotspot-...@openjdk.java.net' >; Baesken, Matthias 
mailto:matthias.baes...@sap.com>>
*Subject:* Re: RFR: 8237192: Generate stripped/public pdbs on Windows 
for jdk images


Hello Christoph,

This patch certainly looks better to me, though I agree it's a bit 
hackish to have to filter and rename the stripped.pdb files twice, 
once for jmods and again for bundles. I think I'm ok with it for now 
though. The future improvement I would like to make would be to create 
two sets of jdk images, one that contains debug symbols and demos, 
which we continue to use for testing, and another which only contains 
exactly what we bundle up, including the correctly named top dir. The 
latter would be created first and used as input for the former. I 
think lots of things would be cleaner then, especially Bundles.gmk.


But, that can wait for later. With your current proposal, my proposed 
future change will apply seamlessly in regard to the stripped pdb 
files and our distribution bundles.


The clash between launchers and libs is annoying, and we also have it 
for java.exe and java.dll already, though the build is explicitly 
handling that one somewhere else.


Now to review, there are some details I will nitpick about.

CreateJmods.gmk:

174, 185: Rule declarations should be indented like any other line 
inside conditionals. But, I have a problem with these rules as the 
target is the directory. This will not work well with incremental 
builds. I would recommend doing a SetupCopyFiles construct instead so 
you get individual rules for each file. It would look something like this:


rename-stripped-pdb = \
    $(patsubst %.stripped.pdb,%.pdb,$1)
$(eval $(call SetupCopyFiles, COPY_STRIPPED_LIBS, \
    SRC := $(LIBS_DIR), \
    DEST := $(

Re: RFR: 8239026: Support non-maven artifacts by JibArtifactManager

[Leonid Mesnik]

Thank you for review.

Leonid

On 2/18/20 8:42 AM, Erik Joelsson wrote:

Looks good.

/Erik

On 2020-02-13 17:44, Leonid Mesnik wrote:

Hi

Could you please review following fix which extend JibArtifactManager 
to support download and installation of artifacts with layout 
different from maven style.
It is planned that user provide name and properties to resolve layout 
using default or jib manager. There are no tests which use this 
customization  currently added in the testbase. So there is no good 
interface like Artifact annotation is added.


webrev: http://cr.openjdk.java.net/~lmesnik/8239026/webrev.00/ 

bug: https://bugs.openjdk.java.net/browse/JDK-8239026 



Leonid

Re: RFR: JDK-8239019: testmake fails with FATAL: VCS_TYPE is empty

[Erik Joelsson]

Here is an updated webrev with the whole check removed:

http://cr.openjdk.java.net/~erikj/8239019/webrev.02

/Erik

On 2020-02-14 09:16, Roger Riggs wrote:

Hi Erik,

Agree it should run outside of any source code system.
Idea supports that with the empty string.
So even the warning can be removed.

Thanks, Roger


On 2/13/20 7:41 PM, Erik Joelsson wrote:

Hello,

The fix to make idea.sh support both git and mercurial had the 
unfortunate side effect of bailing out completely if neither was 
found. This happens to be the case when we run our build system tests 
(which includes running idea.sh) in our distributed test environment. 
I think idea.sh should still work even if run on a source tree 
outside of any source control system.


This patch just changes the lack of a detected VCS_TYPE to a warning 
instead of being fatal. The vcs.xml is still generated, but from what 
I can tell, Intellij doesn't seem to care much.


Webrev: http://cr.openjdk.java.net/~erikj/8239019/webrev.01

Bug: https://bugs.openjdk.java.net/browse/JDK-8239019

/Erik

Re: RFR: JDK-8239019: testmake fails with FATAL: VCS_TYPE is empty

[Roger Riggs]

Looks good.

Thanks, Roger

On 2/18/20 2:05 PM, Erik Joelsson wrote:

Here is an updated webrev with the whole check removed:

http://cr.openjdk.java.net/~erikj/8239019/webrev.02

/Erik

On 2020-02-14 09:16, Roger Riggs wrote:

Hi Erik,

Agree it should run outside of any source code system.
Idea supports that with the empty string.
So even the warning can be removed.

Thanks, Roger


On 2/13/20 7:41 PM, Erik Joelsson wrote:

Hello,

The fix to make idea.sh support both git and mercurial had the 
unfortunate side effect of bailing out completely if neither was 
found. This happens to be the case when we run our build system 
tests (which includes running idea.sh) in our distributed test 
environment. I think idea.sh should still work even if run on a 
source tree outside of any source control system.


This patch just changes the lack of a detected VCS_TYPE to a warning 
instead of being fatal. The vcs.xml is still generated, but from 
what I can tell, Intellij doesn't seem to care much.


Webrev: http://cr.openjdk.java.net/~erikj/8239019/webrev.01

Bug: https://bugs.openjdk.java.net/browse/JDK-8239019

/Erik

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[Kim Barrett]

> On Feb 18, 2020, at 11:24 AM, John Paul Adrian Glaubitz 
>  wrote:
> 
> Hi Kim!
> 
> On 2/18/20 5:07 PM, John Paul Adrian Glaubitz wrote:
>> I forgot to use a reference type when I tried the definition within the class
>> which is why it failed for me. I will test the proper approach and post a
>> patch in a few minutes.
> 
> Here's the patch with the changes as you suggested [1].
> 
> Adrian
> 
>> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.03/

Looks good.

> 
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

[David Holmes]

Looks good to me too.

David

On 19/02/2020 6:26 am, Kim Barrett wrote:

On Feb 18, 2020, at 11:24 AM, John Paul Adrian Glaubitz 
 wrote:

Hi Kim!

On 2/18/20 5:07 PM, John Paul Adrian Glaubitz wrote:

I forgot to use a reference type when I tried the definition within the class
which is why it failed for me. I will test the proper approach and post a
patch in a few minutes.


Here's the patch with the changes as you suggested [1].

Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.03/


Looks good.



--
.''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects

[Andrew Hughes]

On 30/12/2019 20:18, Volker Simonis wrote:
> Hi,
> I'd like to downport the support for Visual Studio Code project
> creation to 11u. I think we will have to support 11u for quite some
> years and it makes sense to have as good as possible tool support in
> 11u as well.

I just came across this proposal in the process of backporting
JDK-8232748: "Build static versions of certain JDK libraries". The only
hunk of that changeset which isn't a simple context difference is that
which applies to JdkNativeCompilation.gmk and the FindLib &
FindStaticLib rules it introduces.

I was going to just drop this hunk, as I didn't see any reason to
backport JDK-8210459, but then I saw your existing RFR referenced on the
bug. If JDK-8210459 is to be backported, I thus need this in place
before posting JDK-8232748 for review.

> 
> This mail is especially intended to get a review from the build team
> that the few changes to the patches are OK:
> 
> https://bugs.openjdk.java.net/browse/JDK-8210459
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8210459/
> 
> https://bugs.openjdk.java.net/browse/JDK-8218807
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8218807/
> 
> https://bugs.openjdk.java.net/browse/JDK-8223678
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8223678/
> 
> The downport consists of three changes which are additive (i.e. later
> changes depend on earlier ones). That's why I decided to post just one
> RFR, because looking at a single change makes no sense without the
> corresponding context. The changes mostly apply cleanly except for
> very few places where we need manual adjustments because of changed
> context.

I'm just going to stick to reviewing JDK-8210459 here. I feel an RFR
should stick to just the one single change, which a reviewer can then
apply and test on the current state of the repository. Having three
changes in one RFR is quite overwhelming and the later changes are being
applied against a repository state which doesn't yet exist. I suspect
that may be one of the reasons this review has not been undertaken thus far.

> 
> These changes only touch make files and actually only add new features
> to the make system, so the normal build results shouldn't be affected.
> I've tested that the build still works on Linux and Windows and "make
> test-make" succeeds.
> 
> Following some details on the three changes:
> 
> 8210459: Add support for generating compile_commands.json
> 
> The initial change which creates the compile_commands.json file (i.e.
> "make compile_commands"). This file can be used for many tools (e.g.
> CLion IDE, clangd, etc..)
> Applies cleanly except for the following hunk, which has a different context:
> 
> ORIGINAL
> 
> CFLAGS_solaris := -KPIC, \
>  CFLAGS_macosx := -fPIC, \
>  DISABLED_WARNINGS_clang := format-nonliteral, \
> -LDFLAGS := $(UNPACKEXE_ZIPOBJS) \
> -$(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \
> +LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \
> 
> JDK11u
> ==
> CFLAGS_linux := -fPIC, \
>  CFLAGS_solaris := -KPIC, \
>  CFLAGS_macosx := -fPIC, \
> -LDFLAGS := $(UNPACKEXE_ZIPOBJS) \
> -$(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \
> +LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \
> 

This looks fine. I compared your patch and the original changeset and
this is indeed the only difference, and only occurs because of the
additional disabled warning for Clang.

> 
> Finally, I've added an additional fix to this last change, whch fixes
> the make tests (i.e. "make test-make"). These tests are currently
> broken in jdk11u. They have been broken by JDK-8212028 (which has
> already been downported to jdk11u) and fixed in jdk 12 as part of
> "8210958: Rename "make run-test" to "make test"" (which hasn't been
> downported yet and probably won't be donwported at all). Because the
> fix is trivial (that's why it was done as part of 8210958 without an
> extra bug ID) and because I wanted to run "make test-make" in jdk11u
> as well to verify my changes, I've decided to downport this fix as
> part of 8223678:
> 
> diff -r 8599975f5b33 test/make/TestMakeBase.gmk
> --- a/test/make/TestMakeBase.gmkTue Feb 12 08:40:43 2019 +0100
> +++ b/test/make/TestMakeBase.gmkMon Dec 23 22:10:46 2019 +0100
>  KWBASE := 
> APA=banan;GURKA=tomat;COUNT=1%202%203%204%205;SUM=1+2+3+4+5;MANY_WORDS=I
> have the best words.
> 
>  $(eval $(call ParseKeywordVariable, KWBASE, \
> -KEYWORDS := APA GURKA SUM, \
> +SINGLE_KEYWORDS := APA GURKA SUM, \
>  STRING_KEYWORDS := COUNT MANY_WORDS, \
>  ))
> 
> @@ -364,7 +376,7 @@
>  KWBASE_WEIRD := ;;APA=banan;;;GURKA=apelsin;APA=skansen;;
> 
>  $(eval $(call ParseKeywordVariable, KWBASE_WEIRD, \
> -KEYWORDS := APA GURKA SUM, \
> +SINGLE_KEYWORDS := APA GURKA SUM, \
>  STRING_KEYWORDS := COUNT, \
>  ))
> 

I agree it doesn't make sense to backport JDK-8210958, as that's a major
change to the test infrastructure. However, I think this warrants its
own 11u bug rather