From martinrb at google.com Fri Dec 1 03:36:54 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 30 Nov 2017 19:36:54 -0800 Subject: RFR: JDK-8192816 Let run-test save exit code In-Reply-To: <5A207C12.3050301@oracle.com> References: <4dcc4736-a3f9-7b8d-9bc9-d6cb3d933ba4@oracle.com> <7e77422e-b488-41fe-1bd7-aacb6a3bd9e0@oracle.com> <5A207C12.3050301@oracle.com> Message-ID: Yeah, tr is a stupid little utility that it would be nice to get away from. It's possible that env LC_ALL=C tr will fix your ASCII character set problem. On Thu, Nov 30, 2017 at 1:45 PM, Tim Bell wrote: > Magnus: > > Looks good. > > On well-behaving unix systems, tr -c '[a-z]' '_' would >> >>> take the complement of a-z and replace it by underscore. But on >>>> solaris, -c [a-z] would evaluate to a (not clearly defined) massive >>>> string of all characters except a-z in the current locale. >>>> >>> > I wish we could get away from using tr due to sometimes surprising > behavior depending on locale, but that is a separate project. > > Tim > > > > On 11/30/17 09:20, Erik Joelsson wrote: > >> Looks good. >> >> / >> >> >> On 2017-11-30 06:09, Magnus Ihse Bursie wrote: >> >>> To support all the use cases of the old test/Makefile way of running >>> tests, we need to save the exit code from running tests. >>> >>> This patch also includes three other bug fixes: >>> * Saving the test ID:s of the latest run in test-last-ids.txt, so we >>> can programmatically discover which new tests were run. >>> * Test roots were not normalized for jtreg tests given only by group >>> (e.g. ":tier1") >>> * Fix for solaris version of tr. >>> >>> The last one was actually quite interesting, and took a while to >>> figure out. On well-behaving unix systems, tr -c '[a-z]' '_' would >>> take the complement of a-z and replace it by underscore. But on >>> solaris, -c [a-z] would evaluate to a (not clearly defined) massive >>> string of all characters except a-z in the current locale. And then, >>> if the second string ('_') is *shorter* than the first, the behavior >>> of tr is *undefinied* (which, in practice, means that it doesn't do >>> anything). Like, "wtf?!? how could this possibly work for anyone?". >>> The workaround, after much hair-pulling, turned out to be a notation >>> to repeat a single character ('[_*1000]'), hoping that the character >>> set never exceeds 1000. *sigh* >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8192816 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8192816-let-run-test-sa >>> ve-exit-code/webrev.01 >>> >>> >>> /Magnus >>> >>> >> > From erik.joelsson at oracle.com Fri Dec 1 17:25:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Dec 2017 09:25:13 -0800 Subject: RFR: JDK-8192876: MacOS build fails intermittently after JDK-8139653 Message-ID: <471dc595-b451-8222-1031-1ebcb749e420@oracle.com> After my fix for linking with freetype, the build has started failing intermittently. This is caused by a closed library using the BUILD_LIBFONTMANAGER variable as prerequisite, but because of my change in JDK-8139653, this variable is no longer valid for that. In this fix, I restore BUILD_LIBFONTMANAGER to a valid prerequisite for libraries that need to link to it. Bug: https://bugs.openjdk.java.net/browse/JDK-8192876 Webrev: http://cr.openjdk.java.net/~erikj/8192876/webrev.01/ /Erik From tim.bell at oracle.com Fri Dec 1 17:36:13 2017 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 01 Dec 2017 09:36:13 -0800 Subject: RFR: JDK-8192876: MacOS build fails intermittently after JDK-8139653 In-Reply-To: <471dc595-b451-8222-1031-1ebcb749e420@oracle.com> References: <471dc595-b451-8222-1031-1ebcb749e420@oracle.com> Message-ID: <5A21930D.5070904@oracle.com> Erik: > After my fix for linking with freetype, the build has started failing > intermittently. This is caused by a closed library using the > BUILD_LIBFONTMANAGER variable as prerequisite, but because of my change > in JDK-8139653, this variable is no longer valid for that. In this fix, > I restore BUILD_LIBFONTMANAGER to a valid prerequisite for libraries > that need to link to it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192876 > > Webrev: http://cr.openjdk.java.net/~erikj/8192876/webrev.01/ Looks good. Tim From magnus.ihse.bursie at oracle.com Fri Dec 1 20:33:18 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Dec 2017 21:33:18 +0100 Subject: How to disable JVM features? In-Reply-To: <5e134e87-aa8f-325a-4b79-900b1dae2afb@oracle.com> References: <5e134e87-aa8f-325a-4b79-900b1dae2afb@oracle.com> Message-ID: You cannot disable features. However, you can create your own complete set of features. Use --with-jvm-variants=custom. The custom variant starts out with a comletely empty set of features. Then use --with-jvm-features=compiler1,minimal,... whatever you want. Please be adviced that not all combinations is possible to build, or makes sense. Or even if it's possible to build, it might not work. The closer you stay to a predefined combination, the more likely it is to work. /Magnus On 2017-11-30 19:35, Vladimir Ivanov wrote: > Hi, > > I'm curious is there a way to disable JVM features from the default list. > > Configure mentions --with-jvm-features [1], but it doesn't allow to > remove features which are enabled by default (tried to override the > list, but it didn't work). > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] > --with-jvm-features? additional JVM features to enable (separated by > ???????????????????? comma), use '--help' to show possible values [none] > ... > The following JVM features are available as arguments to > --with-jvm-features. > Which are valid to use depends on the target platform. > ? compiler1 compiler2 zero minimal dtrace jvmti jvmci graal vm-structs > jni-check services management all-gcs nmt cds static-build > link-time-opt ?aot closed-src commercial-features trace From magnus.ihse.bursie at oracle.com Fri Dec 1 20:50:07 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Dec 2017 21:50:07 +0100 Subject: RFR: JDK-8192876: MacOS build fails intermittently after JDK-8139653 In-Reply-To: <471dc595-b451-8222-1031-1ebcb749e420@oracle.com> References: <471dc595-b451-8222-1031-1ebcb749e420@oracle.com> Message-ID: <2badefbd-3458-e076-5dcc-65ff39c76bd3@oracle.com> On 2017-12-01 18:25, Erik Joelsson wrote: > After my fix for linking with freetype, the build has started failing > intermittently. This is caused by a closed library using the > BUILD_LIBFONTMANAGER variable as prerequisite, but because of my > change in JDK-8139653, this variable is no longer valid for that. In > this fix, I restore BUILD_LIBFONTMANAGER to a valid prerequisite for > libraries that need to link to it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192876 > > Webrev: http://cr.openjdk.java.net/~erikj/8192876/webrev.01/ Looks good to me. /Magnus > > /Erik > From magnus.ihse.bursie at oracle.com Mon Dec 4 10:18:30 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 11:18:30 +0100 Subject: RFR: JDK-8192854 FONTCONFIG_CFLAGS missing from spec.gmk.in Message-ID: By oversight, when the external fontconfig was introduced in JDK-8170681, spec.gmk.in was not updated to actually include FONTCONFIG_CFLAGS (but it was properly exported from lib-fontconfig.m4 and included in the AWT makefile). Bug: https://bugs.openjdk.java.net/browse/JDK-8192854 Patch inline: diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in --- a/make/autoconf/spec.gmk.in +++ b/make/autoconf/spec.gmk.in @@ -293,6 +293,7 @@ ?FREETYPE_CFLAGS:=@FREETYPE_CFLAGS@ ?FREETYPE_BUNDLE_LIB_PATH=@FREETYPE_BUNDLE_LIB_PATH@ ?FREETYPE_LICENSE=@FREETYPE_LICENSE@ +FONTCONFIG_CFLAGS:=@FONTCONFIG_CFLAGS@ ?CUPS_CFLAGS:=@CUPS_CFLAGS@ ?ALSA_LIBS:=@ALSA_LIBS@ ?ALSA_CFLAGS:=@ALSA_CFLAGS@ /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 4 10:57:14 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 11:57:14 +0100 Subject: RFR: JDK-8175795 configure should verify that system zlib contains needed functionality Message-ID: <2aa7dc18-a154-05bb-dc71-1aaf48a1580d@oracle.com> If we're using the system zlib instead of the bundled zlib, we should verify that it includes all relevant functions. We now rely on the inflateValidate() function, which was introduced in zlib 1.2.9 which is very recent. This patch adds a test to the system zlib to verify this and to fail fast in case it's too old. Bug: https://bugs.openjdk.java.net/browse/JDK-8175795 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8175795-check-for-system-zlib-functionality/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 4 11:06:08 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 12:06:08 +0100 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include Message-ID: JDK-8190484 was created as a follow-up bug to the unification of the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location of these files. This has now been decided to be hotspot/share/include and hotspot/os/$OS/include, respectively. This patch moves the relevant files there, but since this also frees up the src/$MODULE/native/include directories for the original purpose, it also unifies and simplifies the build logic for these directories, so that common code is executed for all modules to just copy any exported header files from these directories, should they exist. I'm intending to push this to jdk-hs. Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 4 11:14:43 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 12:14:43 +0100 Subject: RFR: JDK-8175795 configure should verify that system zlib contains needed functionality In-Reply-To: <2aa7dc18-a154-05bb-dc71-1aaf48a1580d@oracle.com> References: <2aa7dc18-a154-05bb-dc71-1aaf48a1580d@oracle.com> Message-ID: <7c9d39e4-102d-4eba-f5a5-d5a3d13f3b70@oracle.com> I retract this review for now. The issue turned out to be not so simple as this. We *are* able to build with older versions of zlib. The dependency for inflateValidate arises from the bundled libpng; a system libpng does not necessary have that issue. /Magnus On 2017-12-04 11:57, Magnus Ihse Bursie wrote: > If we're using the system zlib instead of the bundled zlib, we should > verify that it includes all relevant functions. We now rely on the > inflateValidate() function, which was introduced in zlib 1.2.9 which > is very recent. This patch adds a test to the system zlib to verify > this and to fail fast in case it's too old. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175795 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8175795-check-for-system-zlib-functionality/webrev.01 > > /Magnus > From david.holmes at oracle.com Mon Dec 4 11:17:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Dec 2017 21:17:37 +1000 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: References: Message-ID: Hi Magnus, On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote: > JDK-8190484 was created as a follow-up bug to the unification of the > duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location > of these files. This has now been decided to be hotspot/share/include > and hotspot/os/$OS/include, respectively. > > This patch moves the relevant files there, but since this also frees up > the src/$MODULE/native/include directories for the original purpose, it > also unifies and simplifies the build logic for these directories, so > that common code is executed for all modules to just copy any exported > header files from these directories, should they exist. > > I'm intending to push this to jdk-hs. Do you want this in 10 or 11? If you want 10 then you need to push to jdk/jdk as there may not be another snapshot from jdk/hs. > Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow on cleanups. Thanks, David > > /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 4 11:30:15 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 12:30:15 +0100 Subject: RFR: JDK-8175795 configure should verify that system zlib contains needed functionality In-Reply-To: <7c9d39e4-102d-4eba-f5a5-d5a3d13f3b70@oracle.com> References: <2aa7dc18-a154-05bb-dc71-1aaf48a1580d@oracle.com> <7c9d39e4-102d-4eba-f5a5-d5a3d13f3b70@oracle.com> Message-ID: On 2017-12-04 12:14, Magnus Ihse Bursie wrote: > I retract this review for now. The issue turned out to be not so > simple as this. We *are* able to build with older versions of zlib. > The dependency for inflateValidate arises from the bundled libpng; a > system libpng does not necessary have that issue. Actually, the bundled libpng makes a version check for zlib... So it *should* work even with older zlibs. Probably the reporter of the bug had run into an issue with a zlib clone like zlib-ng, e.g. https://github.com/Dead2/zlib-ng/issues/80. Normally, I don't think it's worth adding checks to configure for every possible broken package there is out there. But since someone actually ran into this (and I've already written most of the patch), here's an updated version: http://cr.openjdk.java.net/~ihse/JDK-8175795-check-for-system-zlib-functionality/webrev.02 /Magnus > > /Magnus > > On 2017-12-04 11:57, Magnus Ihse Bursie wrote: >> If we're using the system zlib instead of the bundled zlib, we should >> verify that it includes all relevant functions. We now rely on the >> inflateValidate() function, which was introduced in zlib 1.2.9 which >> is very recent. This patch adds a test to the system zlib to verify >> this and to fail fast in case it's too old. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8175795 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8175795-check-for-system-zlib-functionality/webrev.01 >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Mon Dec 4 11:45:29 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 12:45:29 +0100 Subject: RFR: JDK-8146977 ove the output "Building configuration X (matching Y)" to lower log level Message-ID: <5ebe86c7-8e90-39c1-80c8-d2069ed8e53f@oracle.com> The output "Building configuration X (matching Y)" is not needed when using the build system at the default log level because the build system always writes "Building target 'Z' in configuration 'Y'", so the user already knows the configuration being used. Bug: https://bugs.openjdk.java.net/browse/JDK-8146977 Patch inline: diff --git a/make/InitSupport.gmk b/make/InitSupport.gmk --- a/make/InitSupport.gmk +++ b/make/InitSupport.gmk @@ -279,7 +279,9 @@ ?????????? # generated files. ?????????? ifeq ($$(MAKE_RESTARTS),) ???????????? ifeq ($$(words $$(matching_confs)), 1) -????????????? $$(info Building configuration '$$(matching_confs)' (matching CONF=$$(CONF))) +????????????? ifneq ($$(findstring $$(LOG_LEVEL), info debug trace),) +??????????????? $$(info Building configuration '$$(matching_confs)' (matching CONF=$$(CONF))) +????????????? endif ???????????? else ?????????????? $$(info Building these configurations (matching CONF=$$(CO /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 4 12:44:36 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 13:44:36 +0100 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: References: Message-ID: On 2017-12-04 12:17, David Holmes wrote: > Hi Magnus, > > On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote: >> JDK-8190484 was created as a follow-up bug to the unification of the >> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >> location of these files. This has now been decided to be >> hotspot/share/include and hotspot/os/$OS/include, respectively. >> >> This patch moves the relevant files there, but since this also frees >> up the src/$MODULE/native/include directories for the original >> purpose, it also unifies and simplifies the build logic for these >> directories, so that common code is executed for all modules to just >> copy any exported header files from these directories, should they >> exist. >> >> I'm intending to push this to jdk-hs. > > Do you want this in 10 or 11? If you want 10 then you need to push to > jdk/jdk as there may not be another snapshot from jdk/hs. It was targeted at 11 in the JBS issue. I don't have a strong opinion on forcing this into JDK 10. Also, one of the fixes it depended on was not yet integrated from jdk/hs to jdk/jdk. But if you think it should go into JDK 10 and jdk/jdk, just let me know and I'll move the changeset there, and await the next jdk/hs -> jdk/jdk integration. /Magnus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 > > > Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow > on cleanups. > > Thanks, > David > >> >> /Magnus From david.holmes at oracle.com Mon Dec 4 12:56:02 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Dec 2017 22:56:02 +1000 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: References: Message-ID: <168a5a98-9e15-8389-fbeb-d0cedf13a739@oracle.com> On 4/12/2017 10:44 PM, Magnus Ihse Bursie wrote: > On 2017-12-04 12:17, David Holmes wrote: >> Hi Magnus, >> >> On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote: >>> JDK-8190484 was created as a follow-up bug to the unification of the >>> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>> location of these files. This has now been decided to be >>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>> >>> This patch moves the relevant files there, but since this also frees >>> up the src/$MODULE/native/include directories for the original >>> purpose, it also unifies and simplifies the build logic for these >>> directories, so that common code is executed for all modules to just >>> copy any exported header files from these directories, should they >>> exist. >>> >>> I'm intending to push this to jdk-hs. >> >> Do you want this in 10 or 11? If you want 10 then you need to push to >> jdk/jdk as there may not be another snapshot from jdk/hs. > It was targeted at 11 in the JBS issue. I don't have a strong opinion on > forcing this into JDK 10. Also, one of the fixes it depended on was not > yet integrated from jdk/hs to jdk/jdk. > > But if you think it should go into JDK 10 and jdk/jdk, just let me know > and I'll move the changeset there, and await the next jdk/hs -> jdk/jdk > integration. Things are not quite working that way at the moment - see [1] - hs has potentially taken its last snapshot before JDK 10 is forked. If this must go into 10 then it has to be pushed direct to jdk/jdk. If it may go in 10 or 11, then it can go into jdk/hs (and it will end up in 10 if there is a second snapshot, else 11). If it is only intended for 11 then it must not be pushed until after the Dec 14 fork of JDK 10. I have no opinion one way or the other. David [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029474.html > /Magnus > >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >> >> >> >> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow >> on cleanups. >> >> Thanks, >> David >> >>> >>> /Magnus > From magnus.ihse.bursie at oracle.com Mon Dec 4 15:45:52 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 16:45:52 +0100 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: <168a5a98-9e15-8389-fbeb-d0cedf13a739@oracle.com> References: <168a5a98-9e15-8389-fbeb-d0cedf13a739@oracle.com> Message-ID: On 2017-12-04 13:56, David Holmes wrote: > On 4/12/2017 10:44 PM, Magnus Ihse Bursie wrote: >> On 2017-12-04 12:17, David Holmes wrote: >>> Hi Magnus, >>> >>> On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote: >>>> JDK-8190484 was created as a follow-up bug to the unification of >>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>>> location of these files. This has now been decided to be >>>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>>> >>>> This patch moves the relevant files there, but since this also >>>> frees up the src/$MODULE/native/include directories for the >>>> original purpose, it also unifies and simplifies the build logic >>>> for these directories, so that common code is executed for all >>>> modules to just copy any exported header files from these >>>> directories, should they exist. >>>> >>>> I'm intending to push this to jdk-hs. >>> >>> Do you want this in 10 or 11? If you want 10 then you need to push >>> to jdk/jdk as there may not be another snapshot from jdk/hs. >> It was targeted at 11 in the JBS issue. I don't have a strong opinion >> on forcing this into JDK 10. Also, one of the fixes it depended on >> was not yet integrated from jdk/hs to jdk/jdk. >> >> But if you think it should go into JDK 10 and jdk/jdk, just let me >> know and I'll move the changeset there, and await the next jdk/hs -> >> jdk/jdk integration. > > Things are not quite working that way at the moment - see [1] - hs has > potentially taken its last snapshot before JDK 10 is forked. If this > must go into 10 then it has to be pushed direct to jdk/jdk. If it may > go in 10 or 11, then it can go into jdk/hs (and it will end up in 10 > if there is a second snapshot, else 11). If it is only intended for 11 > then it must not be pushed until after the Dec 14 fork of JDK 10. > > I have no opinion one way or the other. This patch requires a fix which is currently only in jdk/hs. I can push this to jdk/jdk instead, but only after that fix has been pushed from jdk/hs to jdk/jdk. From the mail you sent, it seems like it can potentially take all the time up until Dec 14. If that happens, I can't get this in jdk 10 no matter what I do. But I can hold on for a while and see if jdk/hs ends up in jdk/jdk in time before Dec 14, and if so, push this fix there. If it doesn't, well, seems like there's no chance this can get in jdk 10 whatever. I don't think it's "intended" for 11 as much as it's a problem if it goes into 10, more than that someone at some point thought there would not be time left to fix it in jdk 10 and re-targeted it at 11. (Something which I didn't notice until after I written the patch.) /Magnus > > David > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029474.html > >> /Magnus >> >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >>> >>> >>> >>> >>> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the >>> flow on cleanups. >>> >>> Thanks, >>> David >>> >>>> >>>> /Magnus >> From erik.joelsson at oracle.com Mon Dec 4 16:53:28 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 08:53:28 -0800 Subject: RFR: JDK-8192854 FONTCONFIG_CFLAGS missing from spec.gmk.in In-Reply-To: References: Message-ID: Looks good. /Erik On 2017-12-04 02:18, Magnus Ihse Bursie wrote: > By oversight, when the external fontconfig was introduced in > JDK-8170681, spec.gmk.in was not updated to actually include > FONTCONFIG_CFLAGS (but it was properly exported from lib-fontconfig.m4 > and included in the AWT makefile). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192854 > Patch inline: > diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in > --- a/make/autoconf/spec.gmk.in > +++ b/make/autoconf/spec.gmk.in > @@ -293,6 +293,7 @@ > ?FREETYPE_CFLAGS:=@FREETYPE_CFLAGS@ > ?FREETYPE_BUNDLE_LIB_PATH=@FREETYPE_BUNDLE_LIB_PATH@ > ?FREETYPE_LICENSE=@FREETYPE_LICENSE@ > +FONTCONFIG_CFLAGS:=@FONTCONFIG_CFLAGS@ > ?CUPS_CFLAGS:=@CUPS_CFLAGS@ > ?ALSA_LIBS:=@ALSA_LIBS@ > ?ALSA_CFLAGS:=@ALSA_CFLAGS@ > > /Magnus > From philip.race at oracle.com Mon Dec 4 16:56:59 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 4 Dec 2017 08:56:59 -0800 Subject: RFR: JDK-8192854 FONTCONFIG_CFLAGS missing from spec.gmk.in In-Reply-To: References: Message-ID: +1 -phil. On 12/04/2017 02:18 AM, Magnus Ihse Bursie wrote: > By oversight, when the external fontconfig was introduced in > JDK-8170681, spec.gmk.in was not updated to actually include > FONTCONFIG_CFLAGS (but it was properly exported from lib-fontconfig.m4 > and included in the AWT makefile). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192854 > Patch inline: > diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in > --- a/make/autoconf/spec.gmk.in > +++ b/make/autoconf/spec.gmk.in > @@ -293,6 +293,7 @@ > FREETYPE_CFLAGS:=@FREETYPE_CFLAGS@ > FREETYPE_BUNDLE_LIB_PATH=@FREETYPE_BUNDLE_LIB_PATH@ > FREETYPE_LICENSE=@FREETYPE_LICENSE@ > +FONTCONFIG_CFLAGS:=@FONTCONFIG_CFLAGS@ > CUPS_CFLAGS:=@CUPS_CFLAGS@ > ALSA_LIBS:=@ALSA_LIBS@ > ALSA_CFLAGS:=@ALSA_CFLAGS@ > > /Magnus > From erik.joelsson at oracle.com Mon Dec 4 17:06:03 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 09:06:03 -0800 Subject: RFR: JDK-8175795 configure should verify that system zlib contains needed functionality In-Reply-To: References: <2aa7dc18-a154-05bb-dc71-1aaf48a1580d@oracle.com> <7c9d39e4-102d-4eba-f5a5-d5a3d13f3b70@oracle.com> Message-ID: <9c3b37d1-eaed-72be-7251-dae73c025911@oracle.com> Looks good. /Erik On 2017-12-04 03:30, Magnus Ihse Bursie wrote: > On 2017-12-04 12:14, Magnus Ihse Bursie wrote: >> I retract this review for now. The issue turned out to be not so >> simple as this. We *are* able to build with older versions of zlib. >> The dependency for inflateValidate arises from the bundled libpng; a >> system libpng does not necessary have that issue. > Actually, the bundled libpng makes a version check for zlib... So it > *should* work even with older zlibs. Probably the reporter of the bug > had run into an issue with a zlib clone like zlib-ng, e.g. > https://github.com/Dead2/zlib-ng/issues/80. > > Normally, I don't think it's worth adding checks to configure for > every possible broken package there is out there. But since someone > actually ran into this (and I've already written most of the patch), > here's an updated version: > > http://cr.openjdk.java.net/~ihse/JDK-8175795-check-for-system-zlib-functionality/webrev.02 > > > /Magnus > >> >> /Magnus >> >> On 2017-12-04 11:57, Magnus Ihse Bursie wrote: >>> If we're using the system zlib instead of the bundled zlib, we >>> should verify that it includes all relevant functions. We now rely >>> on the inflateValidate() function, which was introduced in zlib >>> 1.2.9 which is very recent. This patch adds a test to the system >>> zlib to verify this and to fail fast in case it's too old. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175795 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8175795-check-for-system-zlib-functionality/webrev.01 >>> >>> /Magnus >>> >> > From erik.joelsson at oracle.com Mon Dec 4 17:07:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 09:07:17 -0800 Subject: RFR: JDK-8146977 ove the output "Building configuration X (matching Y)" to lower log level In-Reply-To: <5ebe86c7-8e90-39c1-80c8-d2069ed8e53f@oracle.com> References: <5ebe86c7-8e90-39c1-80c8-d2069ed8e53f@oracle.com> Message-ID: <31aeaa8b-0dd8-8555-2fe8-f9e045126e82@oracle.com> Looks good. /Erik On 2017-12-04 03:45, Magnus Ihse Bursie wrote: > The output "Building configuration X (matching Y)" is not needed when > using the build system at the default log level because the build > system always writes "Building target 'Z' in configuration 'Y'", so > the user already knows the configuration being used. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146977 > Patch inline: > diff --git a/make/InitSupport.gmk b/make/InitSupport.gmk > --- a/make/InitSupport.gmk > +++ b/make/InitSupport.gmk > @@ -279,7 +279,9 @@ > ?????????? # generated files. > ?????????? ifeq ($$(MAKE_RESTARTS),) > ???????????? ifeq ($$(words $$(matching_confs)), 1) > -????????????? $$(info Building configuration '$$(matching_confs)' > (matching CONF=$$(CONF))) > +????????????? ifneq ($$(findstring $$(LOG_LEVEL), info debug trace),) > +??????????????? $$(info Building configuration '$$(matching_confs)' > (matching CONF=$$(CONF))) > +????????????? endif > ???????????? else > ?????????????? $$(info Building these configurations (matching CONF=$$(CO > > /Magnus > From erik.joelsson at oracle.com Mon Dec 4 17:33:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 09:33:13 -0800 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: References: Message-ID: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> Hello Magnus, The -copy targets are currently only being generated for modules that have make/copy/Copy-.gmk makefiles present. By removing make/copy/Copy-jdk.accessibility.gmk and make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer created so the logic in CopyCommon will not be executed. This can be solved in two ways. Either generate -copy rules for all modules or leave the files there with just include CopyCommon.gmk as the only contents. I would recommend the latter for now. Most modules do not need to copy anything. Another minor note, when ordering include directories, I usually put the most specific dir first, so that any platform specific header file with the same name would override a more general one. We don't have that situation in this case, but I still think it's good practice. Regarding where to push this. IMO, if it depends on a change currently in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't really matter that much. /Erik On 2017-12-04 03:06, Magnus Ihse Bursie wrote: > JDK-8190484 was created as a follow-up bug to the unification of the > duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location > of these files. This has now been decided to be hotspot/share/include > and hotspot/os/$OS/include, respectively. > > This patch moves the relevant files there, but since this also frees > up the src/$MODULE/native/include directories for the original > purpose, it also unifies and simplifies the build logic for these > directories, so that common code is executed for all modules to just > copy any exported header files from these directories, should they exist. > > I'm intending to push this to jdk-hs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 4 18:05:48 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 19:05:48 +0100 Subject: RFR: JDK-8192995 run-test gtest should use all jvm variants, not just "server" Message-ID: The current implementation of gtest in run-test will use just the server variant of gtest. This is different from the old test/Makefile implementation, which used all available variants. (Or rather, those of server, client and minimal that were present.) The run-test implementation should do the same. I have solved this by augmenting the gtest test descriptor. Now the fully qualified gtest test descriptor looks like this: "gtest:testname/variant", where "variant" is the JVM variant being tested. If the user specifies no variant, all available variants are tested. So "gtest:testname" will result in "gtest:testname/server" and "gtest:testname/client", if both client and server are present. Bug: https://bugs.openjdk.java.net/browse/JDK-8192995 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8192995-run-test-gtest-all-jvm-variants/webrev.01 /Magnus From mandy.chung at oracle.com Mon Dec 4 18:17:25 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 4 Dec 2017 10:17:25 -0800 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> Message-ID: On 12/4/17 9:33 AM, Erik Joelsson wrote: > Hello Magnus, > > The -copy targets are currently only being generated for > modules that have make/copy/Copy-.gmk makefiles present. By > removing make/copy/Copy-jdk.accessibility.gmk and > make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer created > so the logic in CopyCommon will not be executed. > > This can be solved in two ways. Either generate -copy rules > for all modules or leave the files there with just include > CopyCommon.gmk as the only contents. I would recommend the latter for > now. Most modules do not need to copy anything. Is it possible to generate -copy rules for module where src//{share, $OS}/include directory or make/copy/Copy-.gmk is present? > > Another minor note, when ordering include directories, I usually put > the most specific dir first, so that any platform specific header file > with the same name would override a more general one. We don't have > that situation in this case, but I still think it's good practice. > > Regarding where to push this. IMO, if it depends on a change currently > in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't really > matter that much. > I would love this in JDK 10 if time permits and I am happy to see Coleen retarget it to 10.? This is a really nice clean up that shows the benefit from JEP 201 w.r.t. exported native header files.?? But this is not a must for JDK 10 and if it can't make 10, it's okay for 11. Mandy > /Erik > > > On 2017-12-04 03:06, Magnus Ihse Bursie wrote: >> JDK-8190484 was created as a follow-up bug to the unification of the >> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >> location of these files. This has now been decided to be >> hotspot/share/include and hotspot/os/$OS/include, respectively. >> >> This patch moves the relevant files there, but since this also frees >> up the src/$MODULE/native/include directories for the original >> purpose, it also unifies and simplifies the build logic for these >> directories, so that common code is executed for all modules to just >> copy any exported header files from these directories, should they >> exist. >> >> I'm intending to push this to jdk-hs. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >> >> /Magnus > From erik.joelsson at oracle.com Mon Dec 4 18:21:24 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 10:21:24 -0800 Subject: RFR: JDK-8192995 run-test gtest should use all jvm variants, not just "server" In-Reply-To: References: Message-ID: <83cc7e5d-8db2-94bd-8612-490056a02365@oracle.com> Looks good. /Erik On 2017-12-04 10:05, Magnus Ihse Bursie wrote: > The current implementation of gtest in run-test will use just the > server variant of gtest. This is different from the old test/Makefile > implementation, which used all available variants. (Or rather, those > of server, client and minimal that were present.) The run-test > implementation should do the same. > > I have solved this by augmenting the gtest test descriptor. Now the > fully qualified gtest test descriptor looks like this: > "gtest:testname/variant", where "variant" is the JVM variant being > tested. If the user specifies no variant, all available variants are > tested. So "gtest:testname" will result in "gtest:testname/server" and > "gtest:testname/client", if both client and server are present. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192995 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8192995-run-test-gtest-all-jvm-variants/webrev.01 > > /Magnus From philip.race at oracle.com Mon Dec 4 19:52:29 2017 From: philip.race at oracle.com (Philip Race) Date: Mon, 04 Dec 2017 11:52:29 -0800 Subject: [10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder In-Reply-To: References: <171f8e59-8f7d-2ae4-a726-06e706297db3@oracle.com> <582f2df2-6d44-c092-86e3-81ffdd949965@oracle.com> Message-ID: <5A25A77D.6060600@oracle.com> OK .. approved. -phil. On 11/28/17, 2:11 PM, Sergey Bylokhov wrote: > On 28/11/2017 13:38, Phil Race wrote: >> I see this opens was moved to platform-specific code ... 115 opens >> com.sun.java.swing.plaf.windows to >> 116 jdk.jconsole; >> >> So jdk.jconsole definitely accesses this only on Windows ? > > Its is accessed under the windows check: > http://hg.openjdk.java.net/jdk/client/file/ecaa3569ec3d/src/jdk.jconsole/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java#l223 > > > > String lafName = UIManager.getLookAndFeel().getClass().getName(); > IS_WIN = > lafName.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel"); > > >> >> -phil. >> >> On 11/28/2017 09:28 AM, Erik Joelsson wrote: >>> From a build point of view, this looks great. >>> >>> /Erik >>> >>> >>> On 2017-11-27 18:27, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk10. This is the second attempt to move >>>> windows L&F from non-windows platforms. The first attempt >>>> JDK-6461834[1] was reverted because of JDK-8184813[2]. >>>> The root cause of those issue was fixed in JDK-8075255[3], and now >>>> we can move it again. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189656 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8189656/webrev.02 >>>> >>>> The fix contains a few parts: >>>> - The code related to win l&f was moved from the "share" to the >>>> "windows" folder >>>> - The platform-specific export was moved from module-info.java to >>>> module-info.java.extra >>>> - A number of tests which use windows L&F were marked as >>>> windows-specific >>>> - The stub "ThemeReader.java" which was used to build win w&f on >>>> unix was removed. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-6461834 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8184813 >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8075255 >>>> >>> >> > > From magnus.ihse.bursie at oracle.com Mon Dec 4 20:31:07 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 21:31:07 +0100 Subject: RFR: JDK-8193014 Add "special" tests to run-test to cover odd cases Message-ID: <954e1c54-5896-0320-67e5-9c1330b2e525@oracle.com> There's a bunch of some loose odds and ends in the testing which has not yet been supported by the run-test framework. These are: * make test-make * make test-hotspot-internal * make test-failure-handler This patch adds these as normal run-test test targets. Bug: https://bugs.openjdk.java.net/browse/JDK-8193014 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8193014-add-run-test-special-tests/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 4 20:40:33 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Dec 2017 21:40:33 +0100 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> Message-ID: <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> On 2017-12-04 19:17, mandy chung wrote: > > > On 12/4/17 9:33 AM, Erik Joelsson wrote: >> Hello Magnus, >> >> The -copy targets are currently only being generated for >> modules that have make/copy/Copy-.gmk makefiles present. By >> removing make/copy/Copy-jdk.accessibility.gmk and >> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer >> created so the logic in CopyCommon will not be executed. >> >> This can be solved in two ways. Either generate -copy rules >> for all modules or leave the files there with just include >> CopyCommon.gmk as the only contents. I would recommend the latter for >> now. Most modules do not need to copy anything. > > Is it possible to generate -copy rules for module where > src//{share, $OS}/include directory or > make/copy/Copy-.gmk is present? Technically, it's of course possible. But it does not fit very well with the current DeclareRecipesForPhase. I agree with Erik, that for now the reasonable approach is to have files that only include CopyCommon. We can consider for future updates if it's worth generalizing this. Updated webrev that restores the removed Copy-$MODULE.gmk files: http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 >> >> Another minor note, when ordering include directories, I usually put >> the most specific dir first, so that any platform specific header >> file with the same name would override a more general one. We don't >> have that situation in this case, but I still think it's good practice. >> >> Regarding where to push this. IMO, if it depends on a change >> currently in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't >> really matter that much. >> > > I would love this in JDK 10 if time permits and I am happy to see > Coleen retarget it to 10.? This is a really nice clean up that shows > the benefit from JEP 201 w.r.t. exported native header files.?? But > this is not a must for JDK 10 and if it can't make 10, it's okay for 11. Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon as the needed fixes are integrated from jdk/hs. /Magnus > > Mandy > > >> /Erik >> >> >> On 2017-12-04 03:06, Magnus Ihse Bursie wrote: >>> JDK-8190484 was created as a follow-up bug to the unification of the >>> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>> location of these files. This has now been decided to be >>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>> >>> This patch moves the relevant files there, but since this also frees >>> up the src/$MODULE/native/include directories for the original >>> purpose, it also unifies and simplifies the build logic for these >>> directories, so that common code is executed for all modules to just >>> copy any exported header files from these directories, should they >>> exist. >>> >>> I'm intending to push this to jdk-hs. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >>> >>> /Magnus >> > From mandy.chung at oracle.com Mon Dec 4 20:59:08 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 4 Dec 2017 12:59:08 -0800 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> Message-ID: On 12/4/17 12:40 PM, Magnus Ihse Bursie wrote: > Technically, it's of course possible. But it does not fit very well > with the current DeclareRecipesForPhase. I agree with Erik, that for > now the reasonable approach is to have files that only include > CopyCommon. We can consider for future updates if it's worth > generalizing this. > Okay with me. ? It'd be good if we can consider this in the future so that it avoids creating Copy-.gmk for just the include header case. > Updated webrev that restores the removed Copy-$MODULE.gmk files: > http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 > > Looks good. > > Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon > as the needed fixes are integrated from jdk/hs. > Thank you. Mandy From erik.joelsson at oracle.com Mon Dec 4 21:26:16 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 13:26:16 -0800 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> Message-ID: <604642c5-ca4f-4692-39a9-d1fa9fd73c8d@oracle.com> Looks good. /Erik On 2017-12-04 12:40, Magnus Ihse Bursie wrote: > On 2017-12-04 19:17, mandy chung wrote: >> >> >> On 12/4/17 9:33 AM, Erik Joelsson wrote: >>> Hello Magnus, >>> >>> The -copy targets are currently only being generated for >>> modules that have make/copy/Copy-.gmk makefiles present. By >>> removing make/copy/Copy-jdk.accessibility.gmk and >>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer >>> created so the logic in CopyCommon will not be executed. >>> >>> This can be solved in two ways. Either generate -copy rules >>> for all modules or leave the files there with just include >>> CopyCommon.gmk as the only contents. I would recommend the latter >>> for now. Most modules do not need to copy anything. >> >> Is it possible to generate -copy rules for module where >> src//{share, $OS}/include directory or >> make/copy/Copy-.gmk is present? > Technically, it's of course possible. But it does not fit very well > with the current DeclareRecipesForPhase. I agree with Erik, that for > now the reasonable approach is to have files that only include > CopyCommon. We can consider for future updates if it's worth > generalizing this. > > Updated webrev that restores the removed Copy-$MODULE.gmk files: > http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 > > >>> >>> Another minor note, when ordering include directories, I usually put >>> the most specific dir first, so that any platform specific header >>> file with the same name would override a more general one. We don't >>> have that situation in this case, but I still think it's good practice. >>> >>> Regarding where to push this. IMO, if it depends on a change >>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 >>> doesn't really matter that much. >>> >> >> I would love this in JDK 10 if time permits and I am happy to see >> Coleen retarget it to 10.? This is a really nice clean up that shows >> the benefit from JEP 201 w.r.t. exported native header files.?? But >> this is not a must for JDK 10 and if it can't make 10, it's okay for 11. > > Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon > as the needed fixes are integrated from jdk/hs. > > /Magnus > >> >> Mandy >> >> >>> /Erik >>> >>> >>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote: >>>> JDK-8190484 was created as a follow-up bug to the unification of >>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>>> location of these files. This has now been decided to be >>>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>>> >>>> This patch moves the relevant files there, but since this also >>>> frees up the src/$MODULE/native/include directories for the >>>> original purpose, it also unifies and simplifies the build logic >>>> for these directories, so that common code is executed for all >>>> modules to just copy any exported header files from these >>>> directories, should they exist. >>>> >>>> I'm intending to push this to jdk-hs. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >>>> >>>> /Magnus >>> >> > From erik.joelsson at oracle.com Mon Dec 4 21:29:10 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 13:29:10 -0800 Subject: RFR: JDK-8193014 Add "special" tests to run-test to cover odd cases In-Reply-To: <954e1c54-5896-0320-67e5-9c1330b2e525@oracle.com> References: <954e1c54-5896-0320-67e5-9c1330b2e525@oracle.com> Message-ID: <6ee8890c-6220-ecf4-3682-0bacf2a12a24@oracle.com> Looks good. /Erik On 2017-12-04 12:31, Magnus Ihse Bursie wrote: > There's a bunch of some loose odds and ends in the testing which has > not yet been supported by the run-test framework. These are: > * make test-make > * make test-hotspot-internal > * make test-failure-handler > > This patch adds these as normal run-test test targets. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193014 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8193014-add-run-test-special-tests/webrev.01 > > /Magnus From vladimir.x.ivanov at oracle.com Mon Dec 4 21:45:45 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 5 Dec 2017 00:45:45 +0300 Subject: How to disable JVM features? In-Reply-To: References: <5e134e87-aa8f-325a-4b79-900b1dae2afb@oracle.com> Message-ID: <62633c65-945b-26c3-c878-6b25d205641d@oracle.com> Thanks, Magnus! That works for me. Best regards, Vladimir Ivanov On 12/1/17 11:33 PM, Magnus Ihse Bursie wrote: > You cannot disable features. However, you can create your own complete > set of features. Use --with-jvm-variants=custom. The custom variant > starts out with a comletely empty set of features. Then use > --with-jvm-features=compiler1,minimal,... whatever you want. Please be > adviced that not all combinations is possible to build, or makes sense. > Or even if it's possible to build, it might not work. The closer you > stay to a predefined combination, the more likely it is to work. > > /Magnus > > On 2017-11-30 19:35, Vladimir Ivanov wrote: >> Hi, >> >> I'm curious is there a way to disable JVM features from the default list. >> >> Configure mentions --with-jvm-features [1], but it doesn't allow to >> remove features which are enabled by default (tried to override the >> list, but it didn't work). >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> --with-jvm-features? additional JVM features to enable (separated by >> ???????????????????? comma), use '--help' to show possible values [none] >> ... >> The following JVM features are available as arguments to >> --with-jvm-features. >> Which are valid to use depends on the target platform. >> ? compiler1 compiler2 zero minimal dtrace jvmti jvmci graal vm-structs >> jni-check services management all-gcs nmt cds static-build >> link-time-opt ?aot closed-src commercial-features trace > From erik.joelsson at oracle.com Mon Dec 4 23:21:18 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 15:21:18 -0800 Subject: RFR: JDK-8192771: Boot JDK jar tool used to construct the modular JAR for java.jnlp Message-ID: <3f7537ca-48c3-f9a4-f2dd-d9fc3f664062@oracle.com> To be able to bump the classfile version in JDK 10, we need to be able to build certain jar files using the newly built jar tool during the build. This patch enables overriding of the jar cmd in the build. Bug: https://bugs.openjdk.java.net/browse/JDK-8192771 Webrev: http://cr.openjdk.java.net/~erikj/8192771/webrev.01/ /Erik From mandy.chung at oracle.com Mon Dec 4 23:28:10 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 4 Dec 2017 15:28:10 -0800 Subject: RFR: JDK-8192771: Boot JDK jar tool used to construct the modular JAR for java.jnlp In-Reply-To: <3f7537ca-48c3-f9a4-f2dd-d9fc3f664062@oracle.com> References: <3f7537ca-48c3-f9a4-f2dd-d9fc3f664062@oracle.com> Message-ID: This looks fine to me. Mandy On 12/4/17 3:21 PM, Erik Joelsson wrote: > To be able to bump the classfile version in JDK 10, we need to be able > to build certain jar files using the newly built jar tool during the > build. This patch enables overriding of the jar cmd in the build. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192771 > > Webrev: http://cr.openjdk.java.net/~erikj/8192771/webrev.01/ > > /Erik > From david.holmes at oracle.com Mon Dec 4 23:28:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 09:28:47 +1000 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> Message-ID: <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com> Hi Magnus, There may be a further wart here to resolve. From the "bump the classfile version to 54" thread on jdk-dev: --- >>>> Don't you also need to update: >>>> >>>> jdk/src/java.base/share/native/include/classfile_constants.h >>>> >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53 >>>> >>> I cannot find any usages for this constant, nor JVM_CLASSFILE_MINOR_VERSION. I will remove them. >> >> Okay. I don't know the history or use of this file, other than it gets included into jvm.h to export the jvm interface to the jdk. >> > > And classfile_constants.h is also distributed with the image. I am > unsure of the intent/history. To play it safe i will just bump the > number. Hmmm - that seems wrong. jvm.h is not an exported external interface AFAIK. And we just moved it so I don't think it will get distributed any more. Hmm that also suggests that classfile_constants.h may be in the wrong place ... I'll take this up elsewhere. --- So is classfile_constants.h also in the wrong place? And should it be in the image ?? David On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote: > On 2017-12-04 19:17, mandy chung wrote: >> >> >> On 12/4/17 9:33 AM, Erik Joelsson wrote: >>> Hello Magnus, >>> >>> The -copy targets are currently only being generated for >>> modules that have make/copy/Copy-.gmk makefiles present. By >>> removing make/copy/Copy-jdk.accessibility.gmk and >>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer >>> created so the logic in CopyCommon will not be executed. >>> >>> This can be solved in two ways. Either generate -copy rules >>> for all modules or leave the files there with just include >>> CopyCommon.gmk as the only contents. I would recommend the latter for >>> now. Most modules do not need to copy anything. >> >> Is it possible to generate -copy rules for module where >> src//{share, $OS}/include directory or >> make/copy/Copy-.gmk is present? > Technically, it's of course possible. But it does not fit very well with > the current DeclareRecipesForPhase. I agree with Erik, that for now the > reasonable approach is to have files that only include CopyCommon. We > can consider for future updates if it's worth generalizing this. > > Updated webrev that restores the removed Copy-$MODULE.gmk files: > http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 > > >>> >>> Another minor note, when ordering include directories, I usually put >>> the most specific dir first, so that any platform specific header >>> file with the same name would override a more general one. We don't >>> have that situation in this case, but I still think it's good practice. >>> >>> Regarding where to push this. IMO, if it depends on a change >>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't >>> really matter that much. >>> >> >> I would love this in JDK 10 if time permits and I am happy to see >> Coleen retarget it to 10.? This is a really nice clean up that shows >> the benefit from JEP 201 w.r.t. exported native header files.?? But >> this is not a must for JDK 10 and if it can't make 10, it's okay for 11. > > Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon as > the needed fixes are integrated from jdk/hs. > > /Magnus > >> >> Mandy >> >> >>> /Erik >>> >>> >>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote: >>>> JDK-8190484 was created as a follow-up bug to the unification of the >>>> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>>> location of these files. This has now been decided to be >>>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>>> >>>> This patch moves the relevant files there, but since this also frees >>>> up the src/$MODULE/native/include directories for the original >>>> purpose, it also unifies and simplifies the build logic for these >>>> directories, so that common code is executed for all modules to just >>>> copy any exported header files from these directories, should they >>>> exist. >>>> >>>> I'm intending to push this to jdk-hs. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >>>> >>>> >>>> /Magnus >>> >> > From erik.joelsson at oracle.com Mon Dec 4 23:48:29 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Dec 2017 15:48:29 -0800 Subject: RFR: JDK-8191439: Race in building jdk.rmic.interim Message-ID: <30e82917-a933-babb-bf68-b4097256bfd1@oracle.com> We have a race when building jdk.rmic.interim. This is caused by CompileInterimLangtools.gmk and CompileInterimRmic.gmk using the same modular output directory ($(BUILDTOOLS_OUTPUTDIR)/interim_modules), and then makefiles running javac from interim langtools at the same time as CompileInterimRmic is running. This patch splits the output directories. That way, tools running javac will not see any new files created by CompileInterimRmic ever. Bug: https://bugs.openjdk.java.net/browse/JDK-8191439 Webrev: http://cr.openjdk.java.net/~erikj/8191439/webrev.01/ /Erik From mandy.chung at oracle.com Mon Dec 4 23:54:14 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 4 Dec 2017 15:54:14 -0800 Subject: RFR: JDK-8191439: Race in building jdk.rmic.interim In-Reply-To: <30e82917-a933-babb-bf68-b4097256bfd1@oracle.com> References: <30e82917-a933-babb-bf68-b4097256bfd1@oracle.com> Message-ID: <2ebafceb-2c69-2962-5805-2d750eec6022@oracle.com> Looks good to me. Mandy On 12/4/17 3:48 PM, Erik Joelsson wrote: > We have a race when building jdk.rmic.interim. This is caused by > CompileInterimLangtools.gmk and CompileInterimRmic.gmk using the same > modular output directory ($(BUILDTOOLS_OUTPUTDIR)/interim_modules), > and then makefiles running javac from interim langtools at the same > time as CompileInterimRmic is running. This patch splits the output > directories. That way, tools running javac will not see any new files > created by CompileInterimRmic ever. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191439 > > Webrev: http://cr.openjdk.java.net/~erikj/8191439/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Mon Dec 4 23:59:09 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 00:59:09 +0100 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com> References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com> Message-ID: On 2017-12-05 00:28, David Holmes wrote: > Hi Magnus, > > There may be a further wart here to resolve. But of course... > From the "bump the classfile version to 54" thread on jdk-dev: > > --- > > >>>> Don't you also need to update: > >>>> > >>>> jdk/src/java.base/share/native/include/classfile_constants.h > >>>> > >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53 > >>>> > >>> I cannot find any usages for this constant, nor > JVM_CLASSFILE_MINOR_VERSION. I will remove them. > >> > >> Okay. I don't know the history or use of this file, other than it > gets included into jvm.h to export the jvm interface to the jdk. > >> > > >> And classfile_constants.h is also distributed with the image. I am >> unsure of the intent/history. To play it safe i will just bump the >> number. > Hmmm - that seems wrong. jvm.h is not an exported external interface > AFAIK. And we just moved it so I don't think it will get distributed > any more. Hmm that also suggests that classfile_constants.h may be in > the wrong place ... I'll take this up elsewhere. > > --- > > So is classfile_constants.h also in the wrong place? And should it be > in the image ?? It sounds like it. :( It's only included from jvm.h (and src/java.base/share/native/libverify/check_code.c) as far as I can tell. So it should probably move with jvm.h. The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper promised me to make sure it ended up in jdk/jdk before RDP1). The good news is that just moving classfile_constants.h is probably simple, I assume all include paths are already correct. Can you open a new bug (and/or handle it all by yourself)? /Magnus > > David > > On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote: >> On 2017-12-04 19:17, mandy chung wrote: >>> >>> >>> On 12/4/17 9:33 AM, Erik Joelsson wrote: >>>> Hello Magnus, >>>> >>>> The -copy targets are currently only being generated for >>>> modules that have make/copy/Copy-.gmk makefiles present. By >>>> removing make/copy/Copy-jdk.accessibility.gmk and >>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer >>>> created so the logic in CopyCommon will not be executed. >>>> >>>> This can be solved in two ways. Either generate -copy rules >>>> for all modules or leave the files there with just include >>>> CopyCommon.gmk as the only contents. I would recommend the latter >>>> for now. Most modules do not need to copy anything. >>> >>> Is it possible to generate -copy rules for module where >>> src//{share, $OS}/include directory or >>> make/copy/Copy-.gmk is present? >> Technically, it's of course possible. But it does not fit very well >> with the current DeclareRecipesForPhase. I agree with Erik, that for >> now the reasonable approach is to have files that only include >> CopyCommon. We can consider for future updates if it's worth >> generalizing this. >> >> Updated webrev that restores the removed Copy-$MODULE.gmk files: >> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 >> >> >>>> >>>> Another minor note, when ordering include directories, I usually >>>> put the most specific dir first, so that any platform specific >>>> header file with the same name would override a more general one. >>>> We don't have that situation in this case, but I still think it's >>>> good practice. >>>> >>>> Regarding where to push this. IMO, if it depends on a change >>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 >>>> doesn't really matter that much. >>>> >>> >>> I would love this in JDK 10 if time permits and I am happy to see >>> Coleen retarget it to 10.? This is a really nice clean up that shows >>> the benefit from JEP 201 w.r.t. exported native header files.?? But >>> this is not a must for JDK 10 and if it can't make 10, it's okay for >>> 11. >> >> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon >> as the needed fixes are integrated from jdk/hs. >> >> /Magnus >> >>> >>> Mandy >>> >>> >>>> /Erik >>>> >>>> >>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote: >>>>> JDK-8190484 was created as a follow-up bug to the unification of >>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>>>> location of these files. This has now been decided to be >>>>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>>>> >>>>> This patch moves the relevant files there, but since this also >>>>> frees up the src/$MODULE/native/include directories for the >>>>> original purpose, it also unifies and simplifies the build logic >>>>> for these directories, so that common code is executed for all >>>>> modules to just copy any exported header files from these >>>>> directories, should they exist. >>>>> >>>>> I'm intending to push this to jdk-hs. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >>>>> >>>>> >>>>> /Magnus >>>> >>> >> From magnus.ihse.bursie at oracle.com Tue Dec 5 00:00:10 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 01:00:10 +0100 Subject: RFR: JDK-8191439: Race in building jdk.rmic.interim In-Reply-To: <30e82917-a933-babb-bf68-b4097256bfd1@oracle.com> References: <30e82917-a933-babb-bf68-b4097256bfd1@oracle.com> Message-ID: On 2017-12-05 00:48, Erik Joelsson wrote: > We have a race when building jdk.rmic.interim. This is caused by > CompileInterimLangtools.gmk and CompileInterimRmic.gmk using the same > modular output directory ($(BUILDTOOLS_OUTPUTDIR)/interim_modules), > and then makefiles running javac from interim langtools at the same > time as CompileInterimRmic is running. This patch splits the output > directories. That way, tools running javac will not see any new files > created by CompileInterimRmic ever. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191439 > > Webrev: http://cr.openjdk.java.net/~erikj/8191439/webrev.01/ Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Tue Dec 5 00:04:37 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 01:04:37 +0100 Subject: RFR: JDK-8192771: Boot JDK jar tool used to construct the modular JAR for java.jnlp In-Reply-To: <3f7537ca-48c3-f9a4-f2dd-d9fc3f664062@oracle.com> References: <3f7537ca-48c3-f9a4-f2dd-d9fc3f664062@oracle.com> Message-ID: <78db6e26-850f-1e23-c4b0-a59d7c3629af@oracle.com> On 2017-12-05 00:21, Erik Joelsson wrote: > To be able to bump the classfile version in JDK 10, we need to be able > to build certain jar files using the newly built jar tool during the > build. This patch enables overriding of the jar cmd in the build. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192771 > > Webrev: http://cr.openjdk.java.net/~erikj/8192771/webrev.01/ Looks good to me. /Magnus > > /Erik > From mandy.chung at oracle.com Tue Dec 5 00:13:12 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 4 Dec 2017 16:13:12 -0800 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com> Message-ID: <04878fa7-e896-92b0-2fb9-b64c541928ca@oracle.com> On 12/4/17 3:59 PM, Magnus Ihse Bursie wrote: > >>> And classfile_constants.h is also distributed with the image. I am >>> unsure of the intent/history. To play it safe i will just bump the >>> number. >> Hmmm - that seems wrong. jvm.h is not an exported external interface >> AFAIK. And we just moved it so I don't think it will get distributed >> any more. Hmm that also suggests that classfile_constants.h may be in >> the wrong place ... I'll take this up elsewhere. >> >> --- >> >> So is classfile_constants.h also in the wrong place? And should it be >> in the image ?? > > It sounds like it. :( It's only included from jvm.h (and > src/java.base/share/native/libverify/check_code.c) as far as I can > tell. So it should probably move with jvm.h. > > The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper > promised me to make sure it ended up in jdk/jdk before RDP1). The good > news is that just moving classfile_constants.h is probably simple, I > assume all include paths are already correct. > > Can you open a new bug (and/or handle it all by yourself)? > classfile_constants.h was added to ${java.home}/include in JDK 6 [1] as an exported interface. ? It was intended for BCI native agent to use.? With the removal of JVM TI demos, I think we should revisit if classfile_constants.h should be distributed. As far as JDK-8190484, the changeset adequately covers the non-exported header files. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-5107600 From paul.sandoz at oracle.com Tue Dec 5 00:13:23 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 4 Dec 2017 16:13:23 -0800 Subject: RFR: JDK-8192771: Boot JDK jar tool used to construct the modular JAR for java.jnlp In-Reply-To: <3f7537ca-48c3-f9a4-f2dd-d9fc3f664062@oracle.com> References: <3f7537ca-48c3-f9a4-f2dd-d9fc3f664062@oracle.com> Message-ID: +1 I tested this out with the class file version change patch and the build no longer fails. Thanks, Paul. > On 4 Dec 2017, at 15:21, Erik Joelsson wrote: > > To be able to bump the classfile version in JDK 10, we need to be able to build certain jar files using the newly built jar tool during the build. This patch enables overriding of the jar cmd in the build. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192771 > > Webrev: http://cr.openjdk.java.net/~erikj/8192771/webrev.01/ > > /Erik > From david.holmes at oracle.com Tue Dec 5 00:13:46 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 10:13:46 +1000 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com> Message-ID: <4015e9cd-d4fe-b098-efe3-cc7f72b2d1b1@oracle.com> On 5/12/2017 9:59 AM, Magnus Ihse Bursie wrote: > On 2017-12-05 00:28, David Holmes wrote: >> Hi Magnus, >> >> There may be a further wart here to resolve. > But of course... > >> From the "bump the classfile version to 54" thread on jdk-dev: >> >> --- >> >> >>>> Don't you also need to update: >> >>>> >> >>>> jdk/src/java.base/share/native/include/classfile_constants.h >> >>>> >> >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53 >> >>>> >> >>> I cannot find any usages for this constant, nor >> JVM_CLASSFILE_MINOR_VERSION. I will remove them. >> >> >> >> Okay. I don't know the history or use of this file, other than it >> gets included into jvm.h to export the jvm interface to the jdk. >> >> >> > >>> And classfile_constants.h is also distributed with the image. I am >>> unsure of the intent/history. To play it safe i will just bump the >>> number. >> Hmmm - that seems wrong. jvm.h is not an exported external interface >> AFAIK. And we just moved it so I don't think it will get distributed >> any more. Hmm that also suggests that classfile_constants.h may be in >> the wrong place ... I'll take this up elsewhere. >> >> --- >> >> So is classfile_constants.h also in the wrong place? And should it be >> in the image ?? > > It sounds like it. :( It's only included from jvm.h (and > src/java.base/share/native/libverify/check_code.c) as far as I can tell. > So it should probably move with jvm.h. > > The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper > promised me to make sure it ended up in jdk/jdk before RDP1). The good > news is that just moving classfile_constants.h is probably simple, I > assume all include paths are already correct. > > Can you open a new bug (and/or handle it all by yourself)? No need - Mandy just clarified this: > classfile_constants.h was added to ${java.home}/include in JDK 6 [1]. > It was intended for BCI native agent to use. > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-5107600 so that file should be co-located with jni.h and distributed in the image. Thanks, David > /Magnus > >> >> David >> >> On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote: >>> On 2017-12-04 19:17, mandy chung wrote: >>>> >>>> >>>> On 12/4/17 9:33 AM, Erik Joelsson wrote: >>>>> Hello Magnus, >>>>> >>>>> The -copy targets are currently only being generated for >>>>> modules that have make/copy/Copy-.gmk makefiles present. By >>>>> removing make/copy/Copy-jdk.accessibility.gmk and >>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer >>>>> created so the logic in CopyCommon will not be executed. >>>>> >>>>> This can be solved in two ways. Either generate -copy rules >>>>> for all modules or leave the files there with just include >>>>> CopyCommon.gmk as the only contents. I would recommend the latter >>>>> for now. Most modules do not need to copy anything. >>>> >>>> Is it possible to generate -copy rules for module where >>>> src//{share, $OS}/include directory or >>>> make/copy/Copy-.gmk is present? >>> Technically, it's of course possible. But it does not fit very well >>> with the current DeclareRecipesForPhase. I agree with Erik, that for >>> now the reasonable approach is to have files that only include >>> CopyCommon. We can consider for future updates if it's worth >>> generalizing this. >>> >>> Updated webrev that restores the removed Copy-$MODULE.gmk files: >>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 >>> >>> >>>>> >>>>> Another minor note, when ordering include directories, I usually >>>>> put the most specific dir first, so that any platform specific >>>>> header file with the same name would override a more general one. >>>>> We don't have that situation in this case, but I still think it's >>>>> good practice. >>>>> >>>>> Regarding where to push this. IMO, if it depends on a change >>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 >>>>> doesn't really matter that much. >>>>> >>>> >>>> I would love this in JDK 10 if time permits and I am happy to see >>>> Coleen retarget it to 10.? This is a really nice clean up that shows >>>> the benefit from JEP 201 w.r.t. exported native header files.?? But >>>> this is not a must for JDK 10 and if it can't make 10, it's okay for >>>> 11. >>> >>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon >>> as the needed fixes are integrated from jdk/hs. >>> >>> /Magnus >>> >>>> >>>> Mandy >>>> >>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote: >>>>>> JDK-8190484 was created as a follow-up bug to the unification of >>>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>>>>> location of these files. This has now been decided to be >>>>>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>>>>> >>>>>> This patch moves the relevant files there, but since this also >>>>>> frees up the src/$MODULE/native/include directories for the >>>>>> original purpose, it also unifies and simplifies the build logic >>>>>> for these directories, so that common code is executed for all >>>>>> modules to just copy any exported header files from these >>>>>> directories, should they exist. >>>>>> >>>>>> I'm intending to push this to jdk-hs. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>>>>> WebRev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >>>>>> >>>>>> >>>>>> /Magnus >>>>> >>>> >>> > From tim.bell at oracle.com Tue Dec 5 01:14:24 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 04 Dec 2017 17:14:24 -0800 Subject: RFR: JDK-8191439: Race in building jdk.rmic.interim In-Reply-To: <2ebafceb-2c69-2962-5805-2d750eec6022@oracle.com> References: <30e82917-a933-babb-bf68-b4097256bfd1@oracle.com> <2ebafceb-2c69-2962-5805-2d750eec6022@oracle.com> Message-ID: <5A25F2F0.90606@oracle.com> Erik Looks good to me as well. Tim On 12/04/17 15:54, mandy chung wrote: > Looks good to me. > > Mandy > > On 12/4/17 3:48 PM, Erik Joelsson wrote: >> We have a race when building jdk.rmic.interim. This is caused by >> CompileInterimLangtools.gmk and CompileInterimRmic.gmk using the same >> modular output directory ($(BUILDTOOLS_OUTPUTDIR)/interim_modules), >> and then makefiles running javac from interim langtools at the same >> time as CompileInterimRmic is running. This patch splits the output >> directories. That way, tools running javac will not see any new files >> created by CompileInterimRmic ever. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191439 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8191439/webrev.01/ >> >> /Erik From david.holmes at oracle.com Tue Dec 5 05:59:31 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 15:59:31 +1000 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: <604642c5-ca4f-4692-39a9-d1fa9fd73c8d@oracle.com> References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> <604642c5-ca4f-4692-39a9-d1fa9fd73c8d@oracle.com> Message-ID: <8ad0e61f-ec60-8deb-2fa0-127cb9ebd58b@oracle.com> Magnus, It seems these changes have broken all Windows builds: Copying support/modules_include/jdk.accessibility/win32/bridge /usr/bin/cp -fP '/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge' '/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge' /usr/bin/cp: omitting directory '/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge' CopyCommon.gmk:62: recipe for target '/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge' failed make[3]: *** [/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge] Error 1 David ----- On 5/12/2017 7:26 AM, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2017-12-04 12:40, Magnus Ihse Bursie wrote: >> On 2017-12-04 19:17, mandy chung wrote: >>> >>> >>> On 12/4/17 9:33 AM, Erik Joelsson wrote: >>>> Hello Magnus, >>>> >>>> The -copy targets are currently only being generated for >>>> modules that have make/copy/Copy-.gmk makefiles present. By >>>> removing make/copy/Copy-jdk.accessibility.gmk and >>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer >>>> created so the logic in CopyCommon will not be executed. >>>> >>>> This can be solved in two ways. Either generate -copy rules >>>> for all modules or leave the files there with just include >>>> CopyCommon.gmk as the only contents. I would recommend the latter >>>> for now. Most modules do not need to copy anything. >>> >>> Is it possible to generate -copy rules for module where >>> src//{share, $OS}/include directory or >>> make/copy/Copy-.gmk is present? >> Technically, it's of course possible. But it does not fit very well >> with the current DeclareRecipesForPhase. I agree with Erik, that for >> now the reasonable approach is to have files that only include >> CopyCommon. We can consider for future updates if it's worth >> generalizing this. >> >> Updated webrev that restores the removed Copy-$MODULE.gmk files: >> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 >> >> >>>> >>>> Another minor note, when ordering include directories, I usually put >>>> the most specific dir first, so that any platform specific header >>>> file with the same name would override a more general one. We don't >>>> have that situation in this case, but I still think it's good practice. >>>> >>>> Regarding where to push this. IMO, if it depends on a change >>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 >>>> doesn't really matter that much. >>>> >>> >>> I would love this in JDK 10 if time permits and I am happy to see >>> Coleen retarget it to 10.? This is a really nice clean up that shows >>> the benefit from JEP 201 w.r.t. exported native header files.?? But >>> this is not a must for JDK 10 and if it can't make 10, it's okay for 11. >> >> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon >> as the needed fixes are integrated from jdk/hs. >> >> /Magnus >> >>> >>> Mandy >>> >>> >>>> /Erik >>>> >>>> >>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote: >>>>> JDK-8190484 was created as a follow-up bug to the unification of >>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>>>> location of these files. This has now been decided to be >>>>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>>>> >>>>> This patch moves the relevant files there, but since this also >>>>> frees up the src/$MODULE/native/include directories for the >>>>> original purpose, it also unifies and simplifies the build logic >>>>> for these directories, so that common code is executed for all >>>>> modules to just copy any exported header files from these >>>>> directories, should they exist. >>>>> >>>>> I'm intending to push this to jdk-hs. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >>>>> >>>>> >>>>> /Magnus >>>> >>> >> > From david.holmes at oracle.com Tue Dec 5 06:06:58 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 16:06:58 +1000 Subject: (XS) RFR: 8192950: Missing -nativepath for svc tests Message-ID: <714e54fe-815a-0ad9-fe2a-a3c1ed91e29a@oracle.com> Bug is closed but problem is simply that in jprt.properties we only utilise the test-image and set the -nativepath for a specific configuration of tests. Using "-testset svc" we can hit failures because it is not one of those configurations. This fix simply adds it: webrev: http://cr.openjdk.java.net/~dholmes/8192950/webrev/ --- old/make/jprt.properties 2017-12-05 01:02:40.606195148 -0500 +++ new/make/jprt.properties 2017-12-05 01:02:38.494074834 -0500 @@ -177,6 +177,7 @@ # Not all test targets need the test image jprt.test.bundle.targets=\ + ${my.make.rule.test.targets.svc}, \ ${my.make.rule.test.targets.hotspot.reg}, \ ${my.make.rule.test.targets.hotspot.gtest} \ ${my.make.rule.test.targets.nativesanity} \ Thanks, David From magnus.ihse.bursie at oracle.com Tue Dec 5 07:40:09 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 08:40:09 +0100 Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include In-Reply-To: <8ad0e61f-ec60-8deb-2fa0-127cb9ebd58b@oracle.com> References: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com> <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com> <604642c5-ca4f-4692-39a9-d1fa9fd73c8d@oracle.com> <8ad0e61f-ec60-8deb-2fa0-127cb9ebd58b@oracle.com> Message-ID: On 2017-12-05 06:59, David Holmes wrote: > Magnus, > > It seems these changes have broken all Windows builds: Oh f*ck. :-( I didn't test my re-addition of the Copy-jdk.accessibility.gmk file properly. :( I opened https://bugs.openjdk.java.net/browse/JDK-8193045. /Magnus > > Copying support/modules_include/jdk.accessibility/win32/bridge > /usr/bin/cp -fP > '/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge' > '/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge' > > /usr/bin/cp: omitting directory > '/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge' > CopyCommon.gmk:62: recipe for target > '/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge' > failed > make[3]: *** > [/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge] > Error 1 > > David > ----- > > On 5/12/2017 7:26 AM, Erik Joelsson wrote: >> Looks good. >> >> /Erik >> >> >> On 2017-12-04 12:40, Magnus Ihse Bursie wrote: >>> On 2017-12-04 19:17, mandy chung wrote: >>>> >>>> >>>> On 12/4/17 9:33 AM, Erik Joelsson wrote: >>>>> Hello Magnus, >>>>> >>>>> The -copy targets are currently only being generated for >>>>> modules that have make/copy/Copy-.gmk makefiles present. >>>>> By removing make/copy/Copy-jdk.accessibility.gmk and >>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer >>>>> created so the logic in CopyCommon will not be executed. >>>>> >>>>> This can be solved in two ways. Either generate -copy >>>>> rules for all modules or leave the files there with just include >>>>> CopyCommon.gmk as the only contents. I would recommend the latter >>>>> for now. Most modules do not need to copy anything. >>>> >>>> Is it possible to generate -copy rules for module where >>>> src//{share, $OS}/include directory or >>>> make/copy/Copy-.gmk is present? >>> Technically, it's of course possible. But it does not fit very well >>> with the current DeclareRecipesForPhase. I agree with Erik, that for >>> now the reasonable approach is to have files that only include >>> CopyCommon. We can consider for future updates if it's worth >>> generalizing this. >>> >>> Updated webrev that restores the removed Copy-$MODULE.gmk files: >>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 >>> >>> >>>>> >>>>> Another minor note, when ordering include directories, I usually >>>>> put the most specific dir first, so that any platform specific >>>>> header file with the same name would override a more general one. >>>>> We don't have that situation in this case, but I still think it's >>>>> good practice. >>>>> >>>>> Regarding where to push this. IMO, if it depends on a change >>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 >>>>> doesn't really matter that much. >>>>> >>>> >>>> I would love this in JDK 10 if time permits and I am happy to see >>>> Coleen retarget it to 10.? This is a really nice clean up that >>>> shows the benefit from JEP 201 w.r.t. exported native header >>>> files.?? But this is not a must for JDK 10 and if it can't make 10, >>>> it's okay for 11. >>> >>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as >>> soon as the needed fixes are integrated from jdk/hs. >>> >>> /Magnus >>> >>>> >>>> Mandy >>>> >>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote: >>>>>> JDK-8190484 was created as a follow-up bug to the unification of >>>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper >>>>>> location of these files. This has now been decided to be >>>>>> hotspot/share/include and hotspot/os/$OS/include, respectively. >>>>>> >>>>>> This patch moves the relevant files there, but since this also >>>>>> frees up the src/$MODULE/native/include directories for the >>>>>> original purpose, it also unifies and simplifies the build logic >>>>>> for these directories, so that common code is executed for all >>>>>> modules to just copy any exported header files from these >>>>>> directories, should they exist. >>>>>> >>>>>> I'm intending to push this to jdk-hs. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484 >>>>>> WebRev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 >>>>>> >>>>>> >>>>>> /Magnus >>>>> >>>> >>> >> From magnus.ihse.bursie at oracle.com Tue Dec 5 07:41:47 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 08:41:47 +0100 Subject: (XS) RFR: 8192950: Missing -nativepath for svc tests In-Reply-To: <714e54fe-815a-0ad9-fe2a-a3c1ed91e29a@oracle.com> References: <714e54fe-815a-0ad9-fe2a-a3c1ed91e29a@oracle.com> Message-ID: On 2017-12-05 07:06, David Holmes wrote: > Bug is closed but problem is simply that in jprt.properties we only > utilise the test-image and set the -nativepath for a specific > configuration of tests. Using "-testset svc" we can hit failures > because it is not one of those configurations. This fix simply adds it: > > webrev: http://cr.openjdk.java.net/~dholmes/8192950/webrev/ > > --- old/make/jprt.properties??? 2017-12-05 01:02:40.606195148 -0500 > +++ new/make/jprt.properties??? 2017-12-05 01:02:38.494074834 -0500 > @@ -177,6 +177,7 @@ > > ?# Not all test targets need the test image > ?jprt.test.bundle.targets=\ > +? ${my.make.rule.test.targets.svc}, \ > ?? ${my.make.rule.test.targets.hotspot.reg}, \ > ?? ${my.make.rule.test.targets.hotspot.gtest} \ > ?? ${my.make.rule.test.targets.nativesanity} \ Looks good to me. /Magnus > > Thanks, > David From david.holmes at oracle.com Tue Dec 5 07:54:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 17:54:18 +1000 Subject: (XS) RFR: 8192950: Missing -nativepath for svc tests In-Reply-To: References: <714e54fe-815a-0ad9-fe2a-a3c1ed91e29a@oracle.com> Message-ID: Thanks Magnus! David On 5/12/2017 5:41 PM, Magnus Ihse Bursie wrote: > On 2017-12-05 07:06, David Holmes wrote: >> Bug is closed but problem is simply that in jprt.properties we only >> utilise the test-image and set the -nativepath for a specific >> configuration of tests. Using "-testset svc" we can hit failures >> because it is not one of those configurations. This fix simply adds it: >> >> webrev: http://cr.openjdk.java.net/~dholmes/8192950/webrev/ >> >> --- old/make/jprt.properties??? 2017-12-05 01:02:40.606195148 -0500 >> +++ new/make/jprt.properties??? 2017-12-05 01:02:38.494074834 -0500 >> @@ -177,6 +177,7 @@ >> >> ?# Not all test targets need the test image >> ?jprt.test.bundle.targets=\ >> +? ${my.make.rule.test.targets.svc}, \ >> ?? ${my.make.rule.test.targets.hotspot.reg}, \ >> ?? ${my.make.rule.test.targets.hotspot.gtest} \ >> ?? ${my.make.rule.test.targets.nativesanity} \ > > Looks good to me. > > /Magnus >> >> Thanks, >> David > From magnus.ihse.bursie at oracle.com Tue Dec 5 08:19:27 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 09:19:27 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> Message-ID: <6f0c0dd1-b5ac-1885-a474-3d60a4d5f273@oracle.com> On 2017-12-01 18:16, Volker Simonis wrote: > Hi Rajan, > > great to see this finally happen! > > I have just a quick question related to the tests. As far as I can > see, the tests will only succeed if the OpenJDK will be build with the > new open sourced, Oracle root certificates. But what if somebody is > building the OpenJDK with his own set of root certificates (by using > the --with-cacerts-file option)? Do you see any possibility of > restricting these tests only to builds which used the original, > checked in cacerts file? My question is if the --with-cacerts-file option is still relevant after this? I see a good chance of simplifying some build logic here. :-) /Magnus > > Regards, > Volker > > > On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade wrote: >> May I request for your review of this fix to open source the root >> certificates in Oracle's Java SE Root CA program. The fix is to populate >> cacerts keystore with root certificates and add corresponding tests for it >> as per the test plan outlined at JDK-8191711. interoperability tests are >> added against CAs with available test certificates. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 >> >> Thanks, >> Rajan >> From volker.simonis at gmail.com Tue Dec 5 08:44:37 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Dec 2017 09:44:37 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: <6f0c0dd1-b5ac-1885-a474-3d60a4d5f273@oracle.com> References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <6f0c0dd1-b5ac-1885-a474-3d60a4d5f273@oracle.com> Message-ID: On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie wrote: > On 2017-12-01 18:16, Volker Simonis wrote: >> >> Hi Rajan, >> >> great to see this finally happen! >> >> I have just a quick question related to the tests. As far as I can >> see, the tests will only succeed if the OpenJDK will be build with the >> new open sourced, Oracle root certificates. But what if somebody is >> building the OpenJDK with his own set of root certificates (by using >> the --with-cacerts-file option)? Do you see any possibility of >> restricting these tests only to builds which used the original, >> checked in cacerts file? > > > My question is if the --with-cacerts-file option is still relevant after > this? I see a good chance of simplifying some build logic here. :-) > I think the folks from the AdoptOpenJDK project are using this option (CC-ed adoption-discuss). I'm not sure if they want to drop their root certificates in favor of the new ones. It general I think it would be useful to have something like "--add-cacerts-file" which will merge in additional certificates although this will most certainly complicate the build logic :) Regards, Volker > /Magnus > > >> >> Regards, >> Volker >> >> >> On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade >> wrote: >>> >>> May I request for your review of this fix to open source the root >>> certificates in Oracle's Java SE Root CA program. The fix is to populate >>> cacerts keystore with root certificates and add corresponding tests for >>> it >>> as per the test plan outlined at JDK-8191711. interoperability tests are >>> added against CAs with available test certificates. >>> >>> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 >>> >>> Thanks, >>> Rajan >>> > From magnus.ihse.bursie at oracle.com Tue Dec 5 09:08:38 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 10:08:38 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <6f0c0dd1-b5ac-1885-a474-3d60a4d5f273@oracle.com> Message-ID: On 2017-12-05 09:44, Volker Simonis wrote: > On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie > wrote: >> On 2017-12-01 18:16, Volker Simonis wrote: >>> Hi Rajan, >>> >>> great to see this finally happen! >>> >>> I have just a quick question related to the tests. As far as I can >>> see, the tests will only succeed if the OpenJDK will be build with the >>> new open sourced, Oracle root certificates. But what if somebody is >>> building the OpenJDK with his own set of root certificates (by using >>> the --with-cacerts-file option)? Do you see any possibility of >>> restricting these tests only to builds which used the original, >>> checked in cacerts file? >> >> My question is if the --with-cacerts-file option is still relevant after >> this? I see a good chance of simplifying some build logic here. :-) >> > I think the folks from the AdoptOpenJDK project are using this option > (CC-ed adoption-discuss). I'm not sure if they want to drop their root > certificates in favor of the new ones. Maybe they can upstream their root certs as well, if it seems prudent? > It general I think it would be useful to have something like > "--add-cacerts-file" which will merge in additional certificates > although this will most certainly complicate the build logic :) I see your point, but if the idea is that distributors should be able to supply their own set of root certs (which kind of makes sense, after all) we should probably keep the current functionality. Otherwise there's no way to remove a root cert, which is also something you might want to do (if a CA goes rouge, or whatever). But then again, I think this borders just on the line were it's reasonable for configure to provide an option to replace the file. If a distributor is not satisfied with the contents of a file in OpenJDK, they are always free to replace it. The normal way to do this is to use patches that are applied on top of the OpenJDK source distribution. If you want to have your own ca root store, you would just need a patch with your own file. Voil?! The only reason this was made an option is that the OpenJDK distribution didn't include a root store at all by default, so *all* users needed to provide one for it to be usable. Now that this changes, the need to have build support to replace it diminishes greatly. /Magnus > > Regards, > Volker > >> /Magnus >> >> >>> Regards, >>> Volker >>> >>> >>> On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade >>> wrote: >>>> May I request for your review of this fix to open source the root >>>> certificates in Oracle's Java SE Root CA program. The fix is to populate >>>> cacerts keystore with root certificates and add corresponding tests for >>>> it >>>> as per the test plan outlined at JDK-8191711. interoperability tests are >>>> added against CAs with available test certificates. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 >>>> >>>> Thanks, >>>> Rajan >>>> From magnus.ihse.bursie at oracle.com Tue Dec 5 09:12:42 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 10:12:42 +0100 Subject: [urgent] RFR: JDK-8193045 JDK-8190484 breaks build on Windows Message-ID: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com> JDK-8190484 modifies how the copy step of the build process works. Unfortunately, this broke building on Windows in jdk.accessibility. Since JDK-8190484 was pushed to jdk/hs, I intend to push this to jdk/hs as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8193045 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8193045-fix-broken-copy-includes/webrev.01 /Magnus From david.holmes at oracle.com Tue Dec 5 09:21:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 19:21:03 +1000 Subject: [urgent] RFR: JDK-8193045 JDK-8190484 breaks build on Windows In-Reply-To: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com> References: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com> Message-ID: <4f5bdb34-871c-3e99-27af-f3dd38031292@oracle.com> Hi Magnus, On 5/12/2017 7:12 PM, Magnus Ihse Bursie wrote: > JDK-8190484 modifies how the copy step of the build process works. > Unfortunately, this broke building on Windows in jdk.accessibility. > > Since JDK-8190484 was pushed to jdk/hs, I intend to push this to jdk/hs > as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193045 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8193045-fix-broken-copy-includes/webrev.01 This seems reasonable. You are skipping empty directories - which is what the build failures was choking on. Thanks, David > > /Magnus > From volker.simonis at gmail.com Tue Dec 5 09:25:19 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Dec 2017 10:25:19 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <6f0c0dd1-b5ac-1885-a474-3d60a4d5f273@oracle.com> Message-ID: On Tue, Dec 5, 2017 at 10:08 AM, Magnus Ihse Bursie wrote: > On 2017-12-05 09:44, Volker Simonis wrote: >> >> On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie >> wrote: >>> >>> On 2017-12-01 18:16, Volker Simonis wrote: >>>> >>>> Hi Rajan, >>>> >>>> great to see this finally happen! >>>> >>>> I have just a quick question related to the tests. As far as I can >>>> see, the tests will only succeed if the OpenJDK will be build with the >>>> new open sourced, Oracle root certificates. But what if somebody is >>>> building the OpenJDK with his own set of root certificates (by using >>>> the --with-cacerts-file option)? Do you see any possibility of >>>> restricting these tests only to builds which used the original, >>>> checked in cacerts file? >>> >>> >>> My question is if the --with-cacerts-file option is still relevant after >>> this? I see a good chance of simplifying some build logic here. :-) >>> >> I think the folks from the AdoptOpenJDK project are using this option >> (CC-ed adoption-discuss). I'm not sure if they want to drop their root >> certificates in favor of the new ones. > > Maybe they can upstream their root certs as well, if it seems prudent? >> >> It general I think it would be useful to have something like >> "--add-cacerts-file" which will merge in additional certificates >> although this will most certainly complicate the build logic :) > > I see your point, but if the idea is that distributors should be able to > supply their own set of root certs (which kind of makes sense, after all) we > should probably keep the current functionality. Otherwise there's no way to > remove a root cert, which is also something you might want to do (if a CA > goes rouge, or whatever). > > But then again, I think this borders just on the line were it's reasonable > for configure to provide an option to replace the file. If a distributor is > not satisfied with the contents of a file in OpenJDK, they are always free > to replace it. The normal way to do this is to use patches that are applied > on top of the OpenJDK source distribution. If you want to have your own ca > root store, you would just need a patch with your own file. Voil?! The only I think the most common case would be that distributors want to add their certificates to the existing ones? And that's not easily achievable with a patch because the cacerts file is a binary file. So you need to call keytool for importing additional certificates. It would be of course convenient if this could happen as part of the build process. > reason this was made an option is that the OpenJDK distribution didn't > include a root store at all by default, so *all* users needed to provide one > for it to be usable. Now that this changes, the need to have build support > to replace it diminishes greatly. > > /Magnus > > >> >> Regards, >> Volker >> >>> /Magnus >>> >>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade >>>> wrote: >>>>> >>>>> May I request for your review of this fix to open source the root >>>>> certificates in Oracle's Java SE Root CA program. The fix is to >>>>> populate >>>>> cacerts keystore with root certificates and add corresponding tests for >>>>> it >>>>> as per the test plan outlined at JDK-8191711. interoperability tests >>>>> are >>>>> added against CAs with available test certificates. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ >>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 >>>>> >>>>> Thanks, >>>>> Rajan >>>>> > From magnus.ihse.bursie at oracle.com Tue Dec 5 09:30:58 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 10:30:58 +0100 Subject: [urgent] RFR: JDK-8193045 JDK-8190484 breaks build on Windows In-Reply-To: <4f5bdb34-871c-3e99-27af-f3dd38031292@oracle.com> References: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com> <4f5bdb34-871c-3e99-27af-f3dd38031292@oracle.com> Message-ID: On 2017-12-05 10:21, David Holmes wrote: > Hi Magnus, > > On 5/12/2017 7:12 PM, Magnus Ihse Bursie wrote: >> JDK-8190484 modifies how the copy step of the build process works. >> Unfortunately, this broke building on Windows in jdk.accessibility. >> >> Since JDK-8190484 was pushed to jdk/hs, I intend to push this to >> jdk/hs as well. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193045 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8193045-fix-broken-copy-includes/webrev.01 > > > This seems reasonable. Thanks. Do I need a second reviewer to push this? > You are skipping empty directories - which is what the build failures > was choking on. Actually, the build choked on that $(wildcard) found a directory, which then was sent to cp in SetupCopyFiles, but cp didn't want to copy a directory since it was not called (correctly) with -r. On top of that there was also an aesthetic issue with error messages printed from find when looking in non-existing directories. It was ugly but didn't break the build. /Magnus > > Thanks, > David > >> >> /Magnus >> From magnus.ihse.bursie at oracle.com Tue Dec 5 09:32:37 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 10:32:37 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <6f0c0dd1-b5ac-1885-a474-3d60a4d5f273@oracle.com> Message-ID: On 2017-12-05 10:25, Volker Simonis wrote: > On Tue, Dec 5, 2017 at 10:08 AM, Magnus Ihse Bursie > wrote: >> On 2017-12-05 09:44, Volker Simonis wrote: >>> On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie >>> wrote: >>>> On 2017-12-01 18:16, Volker Simonis wrote: >>>>> Hi Rajan, >>>>> >>>>> great to see this finally happen! >>>>> >>>>> I have just a quick question related to the tests. As far as I can >>>>> see, the tests will only succeed if the OpenJDK will be build with the >>>>> new open sourced, Oracle root certificates. But what if somebody is >>>>> building the OpenJDK with his own set of root certificates (by using >>>>> the --with-cacerts-file option)? Do you see any possibility of >>>>> restricting these tests only to builds which used the original, >>>>> checked in cacerts file? >>>> >>>> My question is if the --with-cacerts-file option is still relevant after >>>> this? I see a good chance of simplifying some build logic here. :-) >>>> >>> I think the folks from the AdoptOpenJDK project are using this option >>> (CC-ed adoption-discuss). I'm not sure if they want to drop their root >>> certificates in favor of the new ones. >> Maybe they can upstream their root certs as well, if it seems prudent? >>> It general I think it would be useful to have something like >>> "--add-cacerts-file" which will merge in additional certificates >>> although this will most certainly complicate the build logic :) >> I see your point, but if the idea is that distributors should be able to >> supply their own set of root certs (which kind of makes sense, after all) we >> should probably keep the current functionality. Otherwise there's no way to >> remove a root cert, which is also something you might want to do (if a CA >> goes rouge, or whatever). >> >> But then again, I think this borders just on the line were it's reasonable >> for configure to provide an option to replace the file. If a distributor is >> not satisfied with the contents of a file in OpenJDK, they are always free >> to replace it. The normal way to do this is to use patches that are applied >> on top of the OpenJDK source distribution. If you want to have your own ca >> root store, you would just need a patch with your own file. Voil?! The only > I think the most common case would be that distributors want to add > their certificates to the existing ones? And that's not easily > achievable with a patch because the cacerts file is a binary file. So > you need to call keytool for importing additional certificates. It > would be of course convenient if this could happen as part of the > build process. If you say. Let's see if that *really* becomes an issue. In the meantime, I'm always open for patches from distributors. :) /Magnus > >> reason this was made an option is that the OpenJDK distribution didn't >> include a root store at all by default, so *all* users needed to provide one >> for it to be usable. Now that this changes, the need to have build support >> to replace it diminishes greatly. >> >> /Magnus >> >> >>> Regards, >>> Volker >>> >>>> /Magnus >>>> >>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade >>>>> wrote: >>>>>> May I request for your review of this fix to open source the root >>>>>> certificates in Oracle's Java SE Root CA program. The fix is to >>>>>> populate >>>>>> cacerts keystore with root certificates and add corresponding tests for >>>>>> it >>>>>> as per the test plan outlined at JDK-8191711. interoperability tests >>>>>> are >>>>>> added against CAs with available test certificates. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ >>>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 >>>>>> >>>>>> Thanks, >>>>>> Rajan >>>>>> From dalibor.topic at oracle.com Tue Dec 5 09:52:48 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 5 Dec 2017 10:52:48 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <6f0c0dd1-b5ac-1885-a474-3d60a4d5f273@oracle.com> Message-ID: On 05.12.2017 10:08, Magnus Ihse Bursie wrote: >> I think the folks from the AdoptOpenJDK project are using this option >> (CC-ed adoption-discuss). I'm not sure if they want to drop their root >> certificates in favor of the new ones. > Maybe they can upstream their root certs as well, if it seems prudent? Afaik, pretty much all downstream builds use the Mozilla PKI certificates. It already has a very active upstream at Mozilla, so upstreaming it into OpenJDK doesn't make a lot of sense. ;) > The only reason this was made an option is > that the OpenJDK distribution didn't include a root store at all by > default, so *all* users needed to provide one for it to be usable. Now > that this changes, the need to have build support to replace it > diminishes greatly. Fwiw, it can still be easily replaced on installation of a package by a symbolic link to (or a copy of) the Mozilla root certificates, for example. So I don't think that it's necessary for the build support to remain, once this change goes in. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From david.holmes at oracle.com Tue Dec 5 10:14:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 20:14:35 +1000 Subject: [urgent] RFR: JDK-8193045 JDK-8190484 breaks build on Windows In-Reply-To: References: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com> <4f5bdb34-871c-3e99-27af-f3dd38031292@oracle.com> Message-ID: <9b077bf5-b672-4b81-ceae-6335bc27c009@oracle.com> On 5/12/2017 7:30 PM, Magnus Ihse Bursie wrote: > On 2017-12-05 10:21, David Holmes wrote: >> Hi Magnus, >> >> On 5/12/2017 7:12 PM, Magnus Ihse Bursie wrote: >>> JDK-8190484 modifies how the copy step of the build process works. >>> Unfortunately, this broke building on Windows in jdk.accessibility. >>> >>> Since JDK-8190484 was pushed to jdk/hs, I intend to push this to >>> jdk/hs as well. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193045 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8193045-fix-broken-copy-includes/webrev.01 >> >> >> >> This seems reasonable. > Thanks. Do I need a second reviewer to push this? I don't think so - it's a build issue, and I've verified the fix myself in a JPRT run. :) >> You are skipping empty directories - which is what the build failures >> was choking on. > Actually, the build choked on that $(wildcard) found a directory, which > then was sent to cp in SetupCopyFiles, but cp didn't want to copy a > directory since it was not called (correctly) with -r. Okay I was imprecise in my description :) Thanks, David > On top of that there was also an aesthetic issue with error messages > printed from find when looking in non-existing directories. It was ugly > but didn't break the build. > > /Magnus > >> >> Thanks, >> David >> >>> >>> /Magnus >>> > From magnus.ihse.bursie at oracle.com Tue Dec 5 10:49:20 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 11:49:20 +0100 Subject: RFR: JDK-8193055 ADD_JVM_ARG_IF_OK always fails Message-ID: <4b7023d5-4da8-68a6-ee0b-2bbc85cf85a9@oracle.com> We mistakenly use -XX:-UnlockDiagnosticVMOptions instead of -XX:+UnlockDiagnosticVMOptions in a ADD_JVM_ARG_IF_OK call. This means that the test will always fail and the arguments will never be added to the command line. Since this has been the case all time along, it's probably not that important, but it was added to keep down the logging when using a debug build as boot jdk, which has probably not been tested that much either. We should either fix this or remove the arguments completely. Bug: https://bugs.openjdk.java.net/browse/JDK-8193055 Patch inline: diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 +++ b/make/autoconf/boot-jdk.m4 @@ -354,7 +354,7 @@ ?? AC_MSG_CHECKING([flags for boot jdk java command] ) ?? # Disable special log output when a debug build is used as Boot JDK... -? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions -XX:-UnlockDiagnosticVMOptions -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) +? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) ?? # Force en-US environment ?? ADD_JVM_ARG_IF_OK([-Duser.language=en -Duser.country=US],boot_jdk_jvmargs,[$JAVA]) /Magnus From david.holmes at oracle.com Tue Dec 5 12:03:25 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 22:03:25 +1000 Subject: RFR: JDK-8193055 ADD_JVM_ARG_IF_OK always fails In-Reply-To: <4b7023d5-4da8-68a6-ee0b-2bbc85cf85a9@oracle.com> References: <4b7023d5-4da8-68a6-ee0b-2bbc85cf85a9@oracle.com> Message-ID: Hi Magnus, On 5/12/2017 8:49 PM, Magnus Ihse Bursie wrote: > We mistakenly use -XX:-UnlockDiagnosticVMOptions instead of > -XX:+UnlockDiagnosticVMOptions in a ADD_JVM_ARG_IF_OK call. This means > that the test will always fail and the arguments will never be added to > the command line. > > Since this has been the case all time along, it's probably not that > important, but it was added to keep down the logging when using a debug > build as boot jdk, which has probably not been tested that much either. LogVMOutput will only be turned on in a debug build if you also enable specific (mostly debug only) log/print/trace options. > We should either fix this or remove the arguments completely. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193055 > Patch inline: > diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 > --- a/make/autoconf/boot-jdk.m4 > +++ b/make/autoconf/boot-jdk.m4 > @@ -354,7 +354,7 @@ > ?? AC_MSG_CHECKING([flags for boot jdk java command] ) > > ?? # Disable special log output when a debug build is used as Boot JDK... > -? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions -XX:-UnlockDiagnosticVMOptions > -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) > +? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions > -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) Fix is fine. But you could probably remove them too. Do you recall why this was added? It may relate to something now migrated to Unified Logging. David ----- > ?? # Force en-US environment > ?? ADD_JVM_ARG_IF_OK([-Duser.language=en > -Duser.country=US],boot_jdk_jvmargs,[$JAVA]) > > /Magnus From magnus.ihse.bursie at oracle.com Tue Dec 5 12:27:16 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 13:27:16 +0100 Subject: RFR: JDK-8193055 ADD_JVM_ARG_IF_OK always fails In-Reply-To: References: <4b7023d5-4da8-68a6-ee0b-2bbc85cf85a9@oracle.com> Message-ID: <63c3fb44-af50-0eab-753c-6449b217ff56@oracle.com> On 2017-12-05 13:03, David Holmes wrote: > Hi Magnus, > > On 5/12/2017 8:49 PM, Magnus Ihse Bursie wrote: >> We mistakenly use -XX:-UnlockDiagnosticVMOptions instead of >> -XX:+UnlockDiagnosticVMOptions in a ADD_JVM_ARG_IF_OK call. This >> means that the test will always fail and the arguments will never be >> added to the command line. >> >> Since this has been the case all time along, it's probably not that >> important, but it was added to keep down the logging when using a >> debug build as boot jdk, which has probably not been tested that much >> either. > > LogVMOutput will only be turned on in a debug build if you also enable > specific (mostly debug only) log/print/trace options. I thought that these extra debug options were enabled by default in debug build, and that required this action to disable them. Otherwise it doesn't really make sense. > >> We should either fix this or remove the arguments completely. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193055 >> Patch inline: >> diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 >> --- a/make/autoconf/boot-jdk.m4 >> +++ b/make/autoconf/boot-jdk.m4 >> @@ -354,7 +354,7 @@ >> ??? AC_MSG_CHECKING([flags for boot jdk java command] ) >> >> ??? # Disable special log output when a debug build is used as Boot >> JDK... >> -? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions >> -XX:-UnlockDiagnosticVMOptions >> -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) >> +? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions >> -XX:+UnlockDiagnosticVMOptions >> -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) > > Fix is fine. But you could probably remove them too. Do you recall why > this was added? It may relate to something now migrated to Unified > Logging. At first I thought that it was introduced as part of JDK-8010767, but that only shuffled it around a bit. Going full Indiana Jones I've dug all the way to the bottom of the repo. It was introduced by the very first build-infra incarnation. :-) So, I'd say, we should probably remove it instead. Updating my webrev: diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 +++ b/make/autoconf/boot-jdk.m4 @@ -353,9 +353,6 @@ ?? AC_MSG_CHECKING([flags for boot jdk java command] ) -? # Disable special log output when a debug build is used as Boot JDK... -? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions -XX:-UnlockDiagnosticVMOptions -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) - ?? # Force en-US environment ?? ADD_JVM_ARG_IF_OK([-Duser.language=en -Duser.country=US],boot_jdk_jvmargs,[$JAVA]) /Magnus > > David > ----- > >> ??? # Force en-US environment >> ??? ADD_JVM_ARG_IF_OK([-Duser.language=en >> -Duser.country=US],boot_jdk_jvmargs,[$JAVA]) >> >> /Magnus From david.holmes at oracle.com Tue Dec 5 12:45:07 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Dec 2017 22:45:07 +1000 Subject: RFR: JDK-8193055 ADD_JVM_ARG_IF_OK always fails In-Reply-To: <63c3fb44-af50-0eab-753c-6449b217ff56@oracle.com> References: <4b7023d5-4da8-68a6-ee0b-2bbc85cf85a9@oracle.com> <63c3fb44-af50-0eab-753c-6449b217ff56@oracle.com> Message-ID: <8b470a33-9242-0216-644a-f1e599aa7238@oracle.com> On 5/12/2017 10:27 PM, Magnus Ihse Bursie wrote: > On 2017-12-05 13:03, David Holmes wrote: >> Hi Magnus, >> >> On 5/12/2017 8:49 PM, Magnus Ihse Bursie wrote: >>> We mistakenly use -XX:-UnlockDiagnosticVMOptions instead of >>> -XX:+UnlockDiagnosticVMOptions in a ADD_JVM_ARG_IF_OK call. This >>> means that the test will always fail and the arguments will never be >>> added to the command line. >>> >>> Since this has been the case all time along, it's probably not that >>> important, but it was added to keep down the logging when using a >>> debug build as boot jdk, which has probably not been tested that much >>> either. >> >> LogVMOutput will only be turned on in a debug build if you also enable >> specific (mostly debug only) log/print/trace options. > I thought that these extra debug options were enabled by default in > debug build, and that required this action to disable them. Otherwise it > doesn't really make sense. AFAICS that is not the case - you have to enable other flags explicitly to implicitly enable LogVMOutput. >> >>> We should either fix this or remove the arguments completely. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193055 >>> Patch inline: >>> diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 >>> --- a/make/autoconf/boot-jdk.m4 >>> +++ b/make/autoconf/boot-jdk.m4 >>> @@ -354,7 +354,7 @@ >>> ??? AC_MSG_CHECKING([flags for boot jdk java command] ) >>> >>> ??? # Disable special log output when a debug build is used as Boot >>> JDK... >>> -? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions >>> -XX:-UnlockDiagnosticVMOptions >>> -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) >>> +? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions >>> -XX:+UnlockDiagnosticVMOptions >>> -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) >> >> Fix is fine. But you could probably remove them too. Do you recall why >> this was added? It may relate to something now migrated to Unified >> Logging. > At first I thought that it was introduced as part of JDK-8010767, but > that only shuffled it around a bit. Going full Indiana Jones I've dug > all the way to the bottom of the repo. It was introduced by the very > first build-infra incarnation. :-) > > So, I'd say, we should probably remove it instead. Updating my webrev: > > diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 > --- a/make/autoconf/boot-jdk.m4 > +++ b/make/autoconf/boot-jdk.m4 > @@ -353,9 +353,6 @@ > > ?? AC_MSG_CHECKING([flags for boot jdk java command] ) > > -? # Disable special log output when a debug build is used as Boot JDK... > -? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions -XX:-UnlockDiagnosticVMOptions > -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) > - > ?? # Force en-US environment > ?? ADD_JVM_ARG_IF_OK([-Duser.language=en > -Duser.country=US],boot_jdk_jvmargs,[$JAVA]) Looks fine to me. David ----- > > > /Magnus > > >> >> David >> ----- >> >>> ??? # Force en-US environment >>> ??? ADD_JVM_ARG_IF_OK([-Duser.language=en >>> -Duser.country=US],boot_jdk_jvmargs,[$JAVA]) >>> >>> /Magnus > From magnus.ihse.bursie at oracle.com Tue Dec 5 12:47:58 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 13:47:58 +0100 Subject: RFR: JDK-8193060 Set MAKE env variable in jib profile for gnumake Message-ID: <04507c92-4d54-8df3-d1ff-3147552c3a24@oracle.com> A small addition to jib-profiles.js to set the MAKE environment variable for gnumake. (Used when running tests without configure) Bug: https://bugs.openjdk.java.net/browse/JDK-8193060 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8193060-set-MAKE-env-in-jib-profile/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Dec 5 13:02:08 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 14:02:08 +0100 Subject: RFR: JDK-8193061 Add run-test-prebuilt functionality Message-ID: <0f5afd36-9cb2-9dd2-6225-c0d081cc0956@oracle.com> This addition makes it possible to run tests using the normal RunTests.gmk framework, even if configure has not been run. The typical use case is for automated testing, where a test machine can download a prebuilt JDK image and test image, and the source tree, and then start executing tests as specified by RunTests.gmk in the source tree, but excersicing the prebuilt JDK and test image. This mode of operation has historically been provided by test/Makefile, but that system is messy, not maintained and parallel to the run-test implementation. With this patch, a new "global" target "run-test-prebuilt" is provided. To use it, you must also specify a number of variables, either on the command line or in the environment. These are the variables that run-test-prebuilt cannot guess. With these values as base, run-test-prebuilt creates a "fake" spec file, with some generic values that are likely to work in many cases, and/or values that can be detected in runtime. Bug: https://bugs.openjdk.java.net/browse/JDK-8193061 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8193061-add-run-test-prebuilt/webrev.01 /Magnus From tim.bell at oracle.com Tue Dec 5 15:40:51 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 05 Dec 2017 07:40:51 -0800 Subject: RFR: JDK-8193060 Set MAKE env variable in jib profile for gnumake In-Reply-To: <04507c92-4d54-8df3-d1ff-3147552c3a24@oracle.com> References: <04507c92-4d54-8df3-d1ff-3147552c3a24@oracle.com> Message-ID: <5A26BE03.5070508@oracle.com> Magnus: > A small addition to jib-profiles.js to set the MAKE environment variable > for gnumake. (Used when running tests without configure) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193060 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8193060-set-MAKE-env-in-jib-profile/webrev.01 Looks good. /Tim From volker.simonis at gmail.com Tue Dec 5 17:01:31 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Dec 2017 18:01:31 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> Message-ID: Hi Rajan, 'cacerts' is a binary file and I thought we have at least the convention in the OpenJDK project that we don't want to check in binary artefact's if possible. One problem with 'cacerts' being a binary file is that we can not add a license and copyright to it. Another one is that it is hard to look inside the file to see what it provides. The biggest problem from my point of view is however that updates to the file will be opaque. Wouldn't it make more sense to add the root certificates in plain text format (e.g. like the Mozilla cacert data [1]) and create the binary cacert file at build time? This would also make it easy to merge the OpenJDK built-in root certificates with user/distributor provided ones. But that's really just a nice side effect. The main reason for my request is that I'm somehow feeling uncomfortable to maintain a security-relevant part of the OpenJDK in an opaque, binary blob. What do others think? Regards, Volker [1] https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade wrote: > May I request for your review of this fix to open source the root > certificates in Oracle's Java SE Root CA program. The fix is to populate > cacerts keystore with root certificates and add corresponding tests for it > as per the test plan outlined at JDK-8191711. interoperability tests are > added against CAs with available test certificates. > > Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 > > Thanks, > Rajan > From erik.joelsson at oracle.com Tue Dec 5 17:21:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Dec 2017 09:21:17 -0800 Subject: RFR: JDK-8193055 ADD_JVM_ARG_IF_OK always fails In-Reply-To: <63c3fb44-af50-0eab-753c-6449b217ff56@oracle.com> References: <4b7023d5-4da8-68a6-ee0b-2bbc85cf85a9@oracle.com> <63c3fb44-af50-0eab-753c-6449b217ff56@oracle.com> Message-ID: Looks good. /Erik On 2017-12-05 04:27, Magnus Ihse Bursie wrote: > On 2017-12-05 13:03, David Holmes wrote: >> Hi Magnus, >> >> On 5/12/2017 8:49 PM, Magnus Ihse Bursie wrote: >>> We mistakenly use -XX:-UnlockDiagnosticVMOptions instead of >>> -XX:+UnlockDiagnosticVMOptions in a ADD_JVM_ARG_IF_OK call. This >>> means that the test will always fail and the arguments will never be >>> added to the command line. >>> >>> Since this has been the case all time along, it's probably not that >>> important, but it was added to keep down the logging when using a >>> debug build as boot jdk, which has probably not been tested that >>> much either. >> >> LogVMOutput will only be turned on in a debug build if you also >> enable specific (mostly debug only) log/print/trace options. > I thought that these extra debug options were enabled by default in > debug build, and that required this action to disable them. Otherwise > it doesn't really make sense. > >> >>> We should either fix this or remove the arguments completely. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193055 >>> Patch inline: >>> diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 >>> --- a/make/autoconf/boot-jdk.m4 >>> +++ b/make/autoconf/boot-jdk.m4 >>> @@ -354,7 +354,7 @@ >>> ??? AC_MSG_CHECKING([flags for boot jdk java command] ) >>> >>> ??? # Disable special log output when a debug build is used as Boot >>> JDK... >>> -? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions >>> -XX:-UnlockDiagnosticVMOptions >>> -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) >>> +? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions >>> -XX:+UnlockDiagnosticVMOptions >>> -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) >> >> Fix is fine. But you could probably remove them too. Do you recall >> why this was added? It may relate to something now migrated to >> Unified Logging. > At first I thought that it was introduced as part of JDK-8010767, but > that only shuffled it around a bit. Going full Indiana Jones I've dug > all the way to the bottom of the repo. It was introduced by the very > first build-infra incarnation. :-) > > So, I'd say, we should probably remove it instead. Updating my webrev: > > diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 > --- a/make/autoconf/boot-jdk.m4 > +++ b/make/autoconf/boot-jdk.m4 > @@ -353,9 +353,6 @@ > > ?? AC_MSG_CHECKING([flags for boot jdk java command] ) > > -? # Disable special log output when a debug build is used as Boot JDK... > -? ADD_JVM_ARG_IF_OK([-XX:-PrintVMOptions > -XX:-UnlockDiagnosticVMOptions > -XX:-LogVMOutput],boot_jdk_jvmargs,[$JAVA]) > - > ?? # Force en-US environment > ?? ADD_JVM_ARG_IF_OK([-Duser.language=en > -Duser.country=US],boot_jdk_jvmargs,[$JAVA]) > > > > /Magnus > > >> >> David >> ----- >> >>> ??? # Force en-US environment >>> ??? ADD_JVM_ARG_IF_OK([-Duser.language=en >>> -Duser.country=US],boot_jdk_jvmargs,[$JAVA]) >>> >>> /Magnus > From sean.mullan at oracle.com Tue Dec 5 17:33:36 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 5 Dec 2017 12:33:36 -0500 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> Message-ID: <28b7b2ae-1ea5-70b3-9136-b488659e6823@oracle.com> On 12/5/17 12:01 PM, Volker Simonis wrote: > Hi Rajan, > > 'cacerts' is a binary file and I thought we have at least the > convention in the OpenJDK project that we don't want to check in > binary artefact's if possible. > > One problem with 'cacerts' being a binary file is that we can not add > a license and copyright to it. Another one is that it is hard to look > inside the file to see what it provides. The biggest problem from my > point of view is however that updates to the file will be opaque. > > Wouldn't it make more sense to add the root certificates in plain text > format (e.g. like the Mozilla cacert data [1]) and create the binary > cacert file at build time? This would also make it easy to merge the > OpenJDK built-in root certificates with user/distributor provided > ones. But that's really just a nice side effect. The main reason for > my request is that I'm somehow feeling uncomfortable to maintain a > security-relevant part of the OpenJDK in an opaque, binary blob. > > What do others think? When all is said and done, the certs themselves are binary; we cannot change that. But I agree having some sort of build mechanism that imports each cert from a textual representation (which can be annotated with comments/copyright) to create the binary cacerts keystore would be nice -- however, I think implementing something like what Mozilla/NSS is doing is not a trivial project and would put this JEP in jeopardy for making JDK 10. I suggest filing an RFE for now. --Sean > > Regards, > Volker > > [1] https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt > > On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade wrote: >> May I request for your review of this fix to open source the root >> certificates in Oracle's Java SE Root CA program. The fix is to populate >> cacerts keystore with root certificates and add corresponding tests for it >> as per the test plan outlined at JDK-8191711. interoperability tests are >> added against CAs with available test certificates. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 >> >> Thanks, >> Rajan >> From magnus.ihse.bursie at oracle.com Tue Dec 5 18:55:53 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 19:55:53 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: <28b7b2ae-1ea5-70b3-9136-b488659e6823@oracle.com> References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <28b7b2ae-1ea5-70b3-9136-b488659e6823@oracle.com> Message-ID: On 2017-12-05 18:33, Sean Mullan wrote: > On 12/5/17 12:01 PM, Volker Simonis wrote: >> Hi Rajan, >> >> 'cacerts' is a binary file and I thought we have at least the >> convention in the OpenJDK project that we don't want to check in >> binary artefact's if possible. >> >> One problem with 'cacerts' being a binary file is that we can not add >> a license and copyright to it. Another one is that it is hard to look >> inside the file to see what it provides. The biggest problem from my >> point of view is however that updates to the file will be opaque. >> >> Wouldn't it make more sense to add the root certificates in plain text >> format (e.g. like the Mozilla cacert data [1]) and create the binary >> cacert file at build time? This would also make it easy to merge the >> OpenJDK built-in root certificates with user/distributor provided >> ones. But that's really just a nice side effect. The main reason for >> my request is that I'm somehow feeling uncomfortable to maintain a >> security-relevant part of the OpenJDK in an opaque, binary blob. >> >> What do others think? > > When all is said and done, the certs themselves are binary; we cannot > change that. But I agree having some sort of build mechanism that > imports each cert from a textual representation (which can be > annotated with comments/copyright) to create the binary cacerts > keystore would be nice -- however, I think implementing something like > what Mozilla/NSS is doing is not a trivial project and would put this > JEP in jeopardy for making JDK 10. > > I suggest filing an RFE for now. I agree. It would be nice compiling the binary keystore during the build. (Even though that, if we're talking serious security issues here, opens up a new attack vector if the compilation tool used is compromised.) And I agree that it is not trivial or at all doable for JDK 10. There's no explicit prohibition on binary files, it's just as Volker says, something we try to avoid. /Magnus > > --Sean > >> >> Regards, >> Volker >> >> [1] >> https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt >> >> On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade >> wrote: >>> May I request for your review of this fix to open source the root >>> certificates in Oracle's Java SE Root CA program. The fix is to >>> populate >>> cacerts keystore with root certificates and add corresponding tests >>> for it >>> as per the test plan outlined at JDK-8191711. interoperability tests >>> are >>> added against CAs with available test certificates. >>> >>> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 >>> >>> Thanks, >>> Rajan >>> From erik.joelsson at oracle.com Tue Dec 5 19:02:05 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Dec 2017 11:02:05 -0800 Subject: RFR: JDK-8193060 Set MAKE env variable in jib profile for gnumake In-Reply-To: <04507c92-4d54-8df3-d1ff-3147552c3a24@oracle.com> References: <04507c92-4d54-8df3-d1ff-3147552c3a24@oracle.com> Message-ID: Looks good. /Erik On 2017-12-05 04:47, Magnus Ihse Bursie wrote: > A small addition to jib-profiles.js to set the MAKE environment > variable for gnumake. (Used when running tests without configure) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193060 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8193060-set-MAKE-env-in-jib-profile/webrev.01 > > /Magnus From erik.joelsson at oracle.com Tue Dec 5 20:05:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Dec 2017 12:05:48 -0800 Subject: RFR: JDK-8193061 Add run-test-prebuilt functionality In-Reply-To: <0f5afd36-9cb2-9dd2-6225-c0d081cc0956@oracle.com> References: <0f5afd36-9cb2-9dd2-6225-c0d081cc0956@oracle.com> Message-ID: Looks pretty good, only some minor notes: * RunTestsPrebuilt.gmk:72: indentation * 95: You could use the sequence macro to generate a large set of increasing numbers here. * 182: "... all others use uname -m" /Erik On 2017-12-05 05:02, Magnus Ihse Bursie wrote: > This addition makes it possible to run tests using the normal > RunTests.gmk framework, even if configure has not been run. The > typical use case is for automated testing, where a test machine can > download a prebuilt JDK image and test image, and the source tree, and > then start executing tests as specified by RunTests.gmk in the source > tree, but excersicing the prebuilt JDK and test image. > > This mode of operation has historically been provided by > test/Makefile, but that system is messy, not maintained and parallel > to the run-test implementation. > > With this patch, a new "global" target "run-test-prebuilt" is > provided. To use it, you must also specify a number of variables, > either on the command line or in the environment. These are the > variables that run-test-prebuilt cannot guess. With these values as > base, run-test-prebuilt creates a "fake" spec file, with some generic > values that are likely to work in many cases, and/or values that can > be detected in runtime. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193061 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8193061-add-run-test-prebuilt/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Tue Dec 5 20:14:13 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Dec 2017 21:14:13 +0100 Subject: RFR: JDK-8193061 Add run-test-prebuilt functionality In-Reply-To: References: <0f5afd36-9cb2-9dd2-6225-c0d081cc0956@oracle.com> Message-ID: <06ba2a86-c91b-4d29-3ecc-aa4f884dac88@oracle.com> On 2017-12-05 21:05, Erik Joelsson wrote: > Looks pretty good, only some minor notes: > > * RunTestsPrebuilt.gmk:72: indentation Fixed. > > * 95: You could use the sequence macro to generate a large set of > increasing numbers here. Unfortunately, it's not available since I can't read MakeBase.gmk yet (it requires a SPEC file). :-( I could have copied it, but that didn't seem worth the effort compared to just listing the integers. ... *sound of coin landing in machine* Oh, but wait, that's not correct anymore. I *do* have MakeBase.gmk included here. That also means I should replace "rm -f" with "$(RM)". :-) > * 182: "... all others use uname -m" Fixed. New webrev with above fixes: http://cr.openjdk.java.net/~ihse/JDK-8193061-add-run-test-prebuilt/webrev.02 /Magnus > > /Erik > > > On 2017-12-05 05:02, Magnus Ihse Bursie wrote: >> This addition makes it possible to run tests using the normal >> RunTests.gmk framework, even if configure has not been run. The >> typical use case is for automated testing, where a test machine can >> download a prebuilt JDK image and test image, and the source tree, >> and then start executing tests as specified by RunTests.gmk in the >> source tree, but excersicing the prebuilt JDK and test image. >> >> This mode of operation has historically been provided by >> test/Makefile, but that system is messy, not maintained and parallel >> to the run-test implementation. >> >> With this patch, a new "global" target "run-test-prebuilt" is >> provided. To use it, you must also specify a number of variables, >> either on the command line or in the environment. These are the >> variables that run-test-prebuilt cannot guess. With these values as >> base, run-test-prebuilt creates a "fake" spec file, with some generic >> values that are likely to work in many cases, and/or values that can >> be detected in runtime. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193061 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8193061-add-run-test-prebuilt/webrev.01 >> >> /Magnus > From erik.joelsson at oracle.com Tue Dec 5 21:15:59 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 5 Dec 2017 13:15:59 -0800 Subject: RFR: JDK-8193061 Add run-test-prebuilt functionality In-Reply-To: <06ba2a86-c91b-4d29-3ecc-aa4f884dac88@oracle.com> References: <0f5afd36-9cb2-9dd2-6225-c0d081cc0956@oracle.com> <06ba2a86-c91b-4d29-3ecc-aa4f884dac88@oracle.com> Message-ID: <6377be69-29ea-15fa-4886-03204c74fcc6@oracle.com> Looks good. On 2017-12-05 12:14, Magnus Ihse Bursie wrote: > > > On 2017-12-05 21:05, Erik Joelsson wrote: >> Looks pretty good, only some minor notes: >> >> * RunTestsPrebuilt.gmk:72: indentation > Fixed. >> >> * 95: You could use the sequence macro to generate a large set of >> increasing numbers here. > Unfortunately, it's not available since I can't read MakeBase.gmk yet > (it requires a SPEC file). :-( I could have copied it, but that didn't > seem worth the effort compared to just listing the integers. > ... > *sound of coin landing in machine* > Oh, but wait, that's not correct anymore. I *do* have MakeBase.gmk > included here. That also means I should replace "rm -f" with "$(RM)". :-) > Yes, I did check for it, and you are already using AppendFile. :) /Erik >> * 182: "... all others use uname -m" > Fixed. > > New webrev with above fixes: > http://cr.openjdk.java.net/~ihse/JDK-8193061-add-run-test-prebuilt/webrev.02 > > > /Magnus >> >> /Erik >> >> >> On 2017-12-05 05:02, Magnus Ihse Bursie wrote: >>> This addition makes it possible to run tests using the normal >>> RunTests.gmk framework, even if configure has not been run. The >>> typical use case is for automated testing, where a test machine can >>> download a prebuilt JDK image and test image, and the source tree, >>> and then start executing tests as specified by RunTests.gmk in the >>> source tree, but excersicing the prebuilt JDK and test image. >>> >>> This mode of operation has historically been provided by >>> test/Makefile, but that system is messy, not maintained and parallel >>> to the run-test implementation. >>> >>> With this patch, a new "global" target "run-test-prebuilt" is >>> provided. To use it, you must also specify a number of variables, >>> either on the command line or in the environment. These are the >>> variables that run-test-prebuilt cannot guess. With these values as >>> base, run-test-prebuilt creates a "fake" spec file, with some >>> generic values that are likely to work in many cases, and/or values >>> that can be detected in runtime. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193061 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8193061-add-run-test-prebuilt/webrev.01 >>> >>> /Magnus >> > From david.holmes at oracle.com Thu Dec 7 10:15:29 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Dec 2017 20:15:29 +1000 Subject: Order of entries in make/mapfiles/reorder-* Message-ID: I have to add new entries to the mapfiles. How is the order in the reorder-* files determined? Thanks, David From erik.helin at oracle.com Thu Dec 7 17:05:17 2017 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 7 Dec 2017 18:05:17 +0100 Subject: RFR: 8193189: Allow --boot-jdk to accept a .tar.gz compressed JDK image Message-ID: <63ef4155-627f-d802-af0c-5bde4696f599@oracle.com> Hi all, this small patch allows the --boot-jdk flag to configure to accept a gzip compressed JDK image. For example: $ wget http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz $ bash configure --with-boot-jdk=openjdk-9.0.1_linux-x64_bin.tar.gz The compressed image will be extracted into build//configure-support/boot-jdk. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8193189 Patch: http://cr.openjdk.java.net/~ehelin/8193189/00/ Testing: - configure and make locally on Linux x86-64 Thanks, Erik From erik.joelsson at oracle.com Thu Dec 7 18:05:21 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Dec 2017 10:05:21 -0800 Subject: RFR: 8193189: Allow --boot-jdk to accept a .tar.gz compressed JDK image In-Reply-To: <63ef4155-627f-d802-af0c-5bde4696f599@oracle.com> References: <63ef4155-627f-d802-af0c-5bde4696f599@oracle.com> Message-ID: <87ceca74-0154-8c19-ff9e-1d946498c054@oracle.com> Hello Erik, On macosx, the tar.gz distribution usually has the java home dir in "jdk-9.jdk/Contents/Home". The -z and --strip-components flags for tar probably works well with gnu tar, but we can only rely on that on Linux and Windows. You need to write the unpack logic compatible with both Solaris and bsd tar as well (yes, that means piping with gunzip and manually finding the correct java home dir inside the exploded file tree :). I would also like to see a better failure handling of a non existing file/directory given to --with-boot-jdk. As it looks now, tar is going to crap out. Otherwise the idea seems decent enough. /Erik On 2017-12-07 09:05, Erik Helin wrote: > Hi all, > > this small patch allows the --boot-jdk flag to configure to accept a > gzip compressed JDK image. For example: > > ? $ wget > http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz > ? $ bash configure --with-boot-jdk=openjdk-9.0.1_linux-x64_bin.tar.gz > > The compressed image will be extracted into > build//configure-support/boot-jdk. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8193189 > > Patch: > http://cr.openjdk.java.net/~ehelin/8193189/00/ > > Testing: > - configure and make locally on Linux x86-64 > > Thanks, > Erik From erik.joelsson at oracle.com Thu Dec 7 19:30:22 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Dec 2017 11:30:22 -0800 Subject: RFR: JDK-8188789: Update JDK 9.0.1 and Future OpenJDK bundle names Message-ID: <9c5e720d-1f89-df2d-a9f4-a67a4d1eab44@oracle.com> For openjdk builds published by Oracle, we need to change the name of the jdk bundle to be prefixed with "open". Instead of trying to enforce this in the build itself, I'm just changing the remote artifact name in the jib configuration. Bug: https://bugs.openjdk.java.net/browse/JDK-8188789 Webrev: http://cr.openjdk.java.net/~erikj/8192932/webrev.01/ /Erik From tim.bell at oracle.com Thu Dec 7 19:42:07 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 07 Dec 2017 11:42:07 -0800 Subject: RFR: JDK-8188789: Update JDK 9.0.1 and Future OpenJDK bundle names In-Reply-To: <9c5e720d-1f89-df2d-a9f4-a67a4d1eab44@oracle.com> References: <9c5e720d-1f89-df2d-a9f4-a67a4d1eab44@oracle.com> Message-ID: <5A29998F.5000203@oracle.com> Erik: > For openjdk builds published by Oracle, we need to change the name of > the jdk bundle to be prefixed with "open". Instead of trying to enforce > this in the build itself, I'm just changing the remote artifact name in > the jib configuration. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188789 > > Webrev: http://cr.openjdk.java.net/~erikj/8192932/webrev.01/ Looks good. Tim From david.holmes at oracle.com Fri Dec 8 06:26:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Dec 2017 16:26:36 +1000 Subject: Order of entries in make/mapfiles/reorder-* In-Reply-To: References: Message-ID: Nobody? On 7/12/2017 8:15 PM, David Holmes wrote: > I have to add new entries to the mapfiles. How is the order in the > reorder-* files determined? > > Thanks, > David From magnus.ihse.bursie at oracle.com Fri Dec 8 09:53:51 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 Dec 2017 10:53:51 +0100 Subject: Order of entries in make/mapfiles/reorder-* In-Reply-To: References: Message-ID: On 2017-12-08 07:26, David Holmes wrote: > Nobody? I don't know. They existed long time before I started working on the build system. I believe they were an attempt to optimize the layout based on some test that ran years and years ago. It's likely that they do nothing (at best) or worsen performance (at worst).? Very few libraries has these reorder files any more. If you think you need to update one, I think a reasonable course of action is to remove it instead. Maybe Claes can help me confirm my speculation about performance..? /Magnus > > On 7/12/2017 8:15 PM, David Holmes wrote: >> I have to add new entries to the mapfiles. How is the order in the >> reorder-* files determined? >> >> Thanks, >> David From magnus.ihse.bursie at oracle.com Fri Dec 8 09:55:54 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 Dec 2017 10:55:54 +0100 Subject: RFR: JDK-8188789: Update JDK 9.0.1 and Future OpenJDK bundle names In-Reply-To: <9c5e720d-1f89-df2d-a9f4-a67a4d1eab44@oracle.com> References: <9c5e720d-1f89-df2d-a9f4-a67a4d1eab44@oracle.com> Message-ID: <6fab82a4-9cf6-e11c-0358-ea5218f9ff4d@oracle.com> On 2017-12-07 20:30, Erik Joelsson wrote: > For openjdk builds published by Oracle, we need to change the name of > the jdk bundle to be prefixed with "open". Instead of trying to > enforce this in the build itself, I'm just changing the remote > artifact name in the jib configuration. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188789 > > Webrev: http://cr.openjdk.java.net/~erikj/8192932/webrev.01/ Looks good to me. /Magnus > > /Erik > From david.holmes at oracle.com Fri Dec 8 10:59:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Dec 2017 20:59:38 +1000 Subject: Order of entries in make/mapfiles/reorder-* In-Reply-To: References: Message-ID: On 8/12/2017 7:53 PM, Magnus Ihse Bursie wrote: > On 2017-12-08 07:26, David Holmes wrote: >> Nobody? > I don't know. They existed long time before I started working on the > build system. I believe they were an attempt to optimize the layout > based on some test that ran years and years ago. It's likely that they > do nothing (at best) or worsen performance (at worst).? Very few > libraries has these reorder files any more. If you think you need to > update one, I think a reasonable course of action is to remove it instead. If an exported API is not in the reorder file then the build fails. So I have to add the new methods to it. The content of the files is very mysterious with apparent comments that make no sense # Test Null # Test Hello etc. I'll just add them close to existing related entries. Thanks, David > Maybe Claes can help me confirm my speculation about performance..? > > /Magnus > >> >> On 7/12/2017 8:15 PM, David Holmes wrote: >>> I have to add new entries to the mapfiles. How is the order in the >>> reorder-* files determined? >>> >>> Thanks, >>> David > From erik.helin at oracle.com Fri Dec 8 13:56:39 2017 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 8 Dec 2017 14:56:39 +0100 Subject: RFR: 8193189: Allow --boot-jdk to accept a .tar.gz compressed JDK image In-Reply-To: <87ceca74-0154-8c19-ff9e-1d946498c054@oracle.com> References: <63ef4155-627f-d802-af0c-5bde4696f599@oracle.com> <87ceca74-0154-8c19-ff9e-1d946498c054@oracle.com> Message-ID: <9fcec35f-f06b-3493-6715-64d1f986b288@oracle.com> On 12/07/2017 07:05 PM, Erik Joelsson wrote: > Hello Erik, > > On macosx, the tar.gz distribution usually has the java home dir in > "jdk-9.jdk/Contents/Home". The -z and --strip-components flags for tar > probably works well with gnu tar, but we can only rely on that on Linux > and Windows. You need to write the unpack logic compatible with both > Solaris and bsd tar as well (yes, that means piping with gunzip and > manually finding the correct java home dir inside the exploded file tree > :). > > I would also like to see a better failure handling of a non existing > file/directory given to --with-boot-jdk. As it looks now, tar is going > to crap out. Thanks for the review! Please see new patches at: - full: http://cr.openjdk.java.net/~ehelin/8193189/01/ - inc: http://cr.openjdk.java.net/~ehelin/8193189/00-01/ What do you think? Thanks, Erik > Otherwise the idea seems decent enough. > > /Erik > > On 2017-12-07 09:05, Erik Helin wrote: >> Hi all, >> >> this small patch allows the --boot-jdk flag to configure to accept a >> gzip compressed JDK image. For example: >> >> ? $ wget >> http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz >> >> ? $ bash configure --with-boot-jdk=openjdk-9.0.1_linux-x64_bin.tar.gz >> >> The compressed image will be extracted into >> build//configure-support/boot-jdk. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8193189 >> >> Patch: >> http://cr.openjdk.java.net/~ehelin/8193189/00/ >> >> Testing: >> - configure and make locally on Linux x86-64 >> >> Thanks, >> Erik > From volker.simonis at gmail.com Fri Dec 8 14:45:26 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Dec 2017 15:45:26 +0100 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <28b7b2ae-1ea5-70b3-9136-b488659e6823@oracle.com> Message-ID: On Tue, Dec 5, 2017 at 7:55 PM, Magnus Ihse Bursie wrote: > > On 2017-12-05 18:33, Sean Mullan wrote: >> >> On 12/5/17 12:01 PM, Volker Simonis wrote: >>> >>> Hi Rajan, >>> >>> 'cacerts' is a binary file and I thought we have at least the >>> convention in the OpenJDK project that we don't want to check in >>> binary artefact's if possible. >>> >>> One problem with 'cacerts' being a binary file is that we can not add >>> a license and copyright to it. Another one is that it is hard to look >>> inside the file to see what it provides. The biggest problem from my >>> point of view is however that updates to the file will be opaque. >>> >>> Wouldn't it make more sense to add the root certificates in plain text >>> format (e.g. like the Mozilla cacert data [1]) and create the binary >>> cacert file at build time? This would also make it easy to merge the >>> OpenJDK built-in root certificates with user/distributor provided >>> ones. But that's really just a nice side effect. The main reason for >>> my request is that I'm somehow feeling uncomfortable to maintain a >>> security-relevant part of the OpenJDK in an opaque, binary blob. >>> >>> What do others think? >> >> >> When all is said and done, the certs themselves are binary; we cannot >> change that. But I agree having some sort of build mechanism that imports >> each cert from a textual representation (which can be annotated with >> comments/copyright) to create the binary cacerts keystore would be nice -- >> however, I think implementing something like what Mozilla/NSS is doing is >> not a trivial project and would put this JEP in jeopardy for making JDK 10. >> >> I suggest filing an RFE for now. > > I agree. It would be nice compiling the binary keystore during the build. > (Even though that, if we're talking serious security issues here, opens up a > new attack vector if the compilation tool used is compromised.) And I agree > that it is not trivial or at all doable for JDK 10. > OK, I've opened the RFR "JDK-8193255: Root Certificates should be stored in text format and assembled at build time" for this issue. I've also put some information about how the AdoptOpenJDK builds their cacerts JKS file from the Mozilla certdata.txt data into the JBS issue. I think we should do something similar in the OpenJDK at build time. By the way, how did you create the JKS file which will be contributed to the OpenJDK. I suppose Oracle gets all the contained certificates in a text format and assembles them internally into the binary cacerts file. So you must already have some tooling for doing this (although I understand that it may be not suitable for direct inclusion into the OpenJDK because of copyright/licensing issues). Regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8193255 > There's no explicit prohibition on binary files, it's just as Volker says, > something we try to avoid. > > /Magnus > > >> >> --Sean >> >>> >>> Regards, >>> Volker >>> >>> [1] >>> https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt >>> >>> On Fri, Dec 1, 2017 at 5:54 PM, Rajan Halade >>> wrote: >>>> >>>> May I request for your review of this fix to open source the root >>>> certificates in Oracle's Java SE Root CA program. The fix is to populate >>>> cacerts keystore with root certificates and add corresponding tests for >>>> it >>>> as per the test plan outlined at JDK-8191711. interoperability tests are >>>> added against CAs with available test certificates. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rhalade/8189131/webrev.00/ >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8191486 >>>> >>>> Thanks, >>>> Rajan >>>> > From claes.redestad at oracle.com Fri Dec 8 15:32:06 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 8 Dec 2017 16:32:06 +0100 Subject: Order of entries in make/mapfiles/reorder-* In-Reply-To: References: Message-ID: I think the tool to generate these reorder files exist under src/utils/reorder, but looking at src/utils/reorder/Makefile it seems to have bit-rotted over the years.. the bootclasspath tricks with rt.jar etc likely won't even work today: # This Makefile is intended to produce new reordering files for the # reordering of jar files and shared libraries.? This is not part of the # standard build.? The objects produced by this Makefile must be copied # into their standard locations and checked in. I'm not sure any of this is relevant in the modular world (as most jar files are now merged into lib/modules, which has a separate reordering facility that is automatically generated on build and enforced by jlink). File a bug to investigate and potentially remove it all? /Claes On 2017-12-08 10:53, Magnus Ihse Bursie wrote: > On 2017-12-08 07:26, David Holmes wrote: >> Nobody? > I don't know. They existed long time before I started working on the > build system. I believe they were an attempt to optimize the layout > based on some test that ran years and years ago. It's likely that they > do nothing (at best) or worsen performance (at worst).? Very few > libraries has these reorder files any more. If you think you need to > update one, I think a reasonable course of action is to remove it > instead. > > Maybe Claes can help me confirm my speculation about performance..? > > /Magnus > >> >> On 7/12/2017 8:15 PM, David Holmes wrote: >>> I have to add new entries to the mapfiles. How is the order in the >>> reorder-* files determined? >>> >>> Thanks, >>> David > From erik.joelsson at oracle.com Fri Dec 8 16:37:03 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Dec 2017 08:37:03 -0800 Subject: RFR: 8193189: Allow --boot-jdk to accept a .tar.gz compressed JDK image In-Reply-To: <9fcec35f-f06b-3493-6715-64d1f986b288@oracle.com> References: <63ef4155-627f-d802-af0c-5bde4696f599@oracle.com> <87ceca74-0154-8c19-ff9e-1d946498c054@oracle.com> <9fcec35f-f06b-3493-6715-64d1f986b288@oracle.com> Message-ID: This looks better. One more thing that I forgot in the last review, on mkdir I recommend using the -p flag for nicer handling if the dir already exists and in case CONFIGURESUPPORT_OUTPUTDIR has not yet been created. How does tar react if a bootjdk is already present in CONFIGURESUPPORT_OUTPUTDIR? Should we delete first or just overwrite? /Erik On 2017-12-08 05:56, Erik Helin wrote: > On 12/07/2017 07:05 PM, Erik Joelsson wrote: >> Hello Erik, >> >> On macosx, the tar.gz distribution usually has the java home dir in >> "jdk-9.jdk/Contents/Home". The -z and --strip-components flags for >> tar probably works well with gnu tar, but we can only rely on that on >> Linux and Windows. You need to write the unpack logic compatible with >> both Solaris and bsd tar as well (yes, that means piping with gunzip >> and manually finding the correct java home dir inside the exploded >> file tree :). >> >> I would also like to see a better failure handling of a non existing >> file/directory given to --with-boot-jdk. As it looks now, tar is >> going to crap out. > > Thanks for the review! Please see new patches at: > - full: http://cr.openjdk.java.net/~ehelin/8193189/01/ > - inc: http://cr.openjdk.java.net/~ehelin/8193189/00-01/ > > What do you think? > > Thanks, > Erik > >> Otherwise the idea seems decent enough. >> >> /Erik >> >> On 2017-12-07 09:05, Erik Helin wrote: >>> Hi all, >>> >>> this small patch allows the --boot-jdk flag to configure to accept a >>> gzip compressed JDK image. For example: >>> >>> ? $ wget >>> http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz >>> >>> ? $ bash configure --with-boot-jdk=openjdk-9.0.1_linux-x64_bin.tar.gz >>> >>> The compressed image will be extracted into >>> build//configure-support/boot-jdk. >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8193189 >>> >>> Patch: >>> http://cr.openjdk.java.net/~ehelin/8193189/00/ >>> >>> Testing: >>> - configure and make locally on Linux x86-64 >>> >>> Thanks, >>> Erik >> From tim.bell at oracle.com Fri Dec 8 17:01:16 2017 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 08 Dec 2017 09:01:16 -0800 Subject: Order of entries in make/mapfiles/reorder-* In-Reply-To: <5A2ABCF8.7070801@oracle.com> References: <5A2ABCF8.7070801@oracle.com> Message-ID: <5A2AC55C.7040308@oracle.com> On 12/08/17 08:25, Tim Bell wrote: > Looks like that was back in the 1.5 timeframe, if not before. My mistake. All this predates OpenJDK, so not appropriate for the open list. I'll remove it. My apologies. Tim From david.holmes at oracle.com Fri Dec 8 23:29:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Dec 2017 09:29:49 +1000 Subject: Order of entries in make/mapfiles/reorder-* In-Reply-To: References: Message-ID: Thanks for the pointers! I had not connected these mapfile/reorder-* files directly with the old rt.jar reordering - though I guessed they served a similar purpose. As Tim later mentions the strange comments in the file do seem to match up to the tests. As these mapfiles are needed for the build to actually work they can't be removed without changing the way the build is done. But it seems likely that the order of the entries is no longer relevant. David On 9/12/2017 1:32 AM, Claes Redestad wrote: > I think the tool to generate these reorder files exist under > src/utils/reorder, but looking at > src/utils/reorder/Makefile it seems to have bit-rotted over the years.. > the bootclasspath tricks > with rt.jar etc likely won't even work today: > > # This Makefile is intended to produce new reordering files for the > # reordering of jar files and shared libraries.? This is not part of the > # standard build.? The objects produced by this Makefile must be copied > # into their standard locations and checked in. > > I'm not sure any of this is relevant in the modular world (as most jar > files are now merged > into lib/modules, which has a separate reordering facility that is > automatically generated on > build and enforced by jlink). > > File a bug to investigate and potentially remove it all? > > /Claes > > On 2017-12-08 10:53, Magnus Ihse Bursie wrote: >> On 2017-12-08 07:26, David Holmes wrote: >>> Nobody? >> I don't know. They existed long time before I started working on the >> build system. I believe they were an attempt to optimize the layout >> based on some test that ran years and years ago. It's likely that they >> do nothing (at best) or worsen performance (at worst).? Very few >> libraries has these reorder files any more. If you think you need to >> update one, I think a reasonable course of action is to remove it >> instead. >> >> Maybe Claes can help me confirm my speculation about performance..? >> >> /Magnus >> >>> >>> On 7/12/2017 8:15 PM, David Holmes wrote: >>>> I have to add new entries to the mapfiles. How is the order in the >>>> reorder-* files determined? >>>> >>>> Thanks, >>>> David >> > From rajan.halade at oracle.com Sat Dec 9 01:09:50 2017 From: rajan.halade at oracle.com (Rajan Halade) Date: Sat, 9 Dec 2017 06:39:50 +0530 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <28b7b2ae-1ea5-70b3-9136-b488659e6823@oracle.com> Message-ID: On 12/8/17 8:15 PM, Volker Simonis wrote: > OK, I've opened the RFR "JDK-8193255: Root Certificates should be > stored in text format and assembled at build time" for this issue. > I've also put some information about how the AdoptOpenJDK builds their > cacerts JKS file from the Mozilla certdata.txt data into the JBS > issue. I think we should do something similar in the OpenJDK at build > time. Thank you! > > By the way, how did you create the JKS file which will be contributed > to the OpenJDK. I suppose Oracle gets all the contained certificates > in a text format and assembles them internally into the binary cacerts > file. So you must already have some tooling for doing this (although I > understand that it may be not suitable for direct inclusion into the > OpenJDK because of copyright/licensing issues). I used keytool to import certificates in to keystore. The certificate itself can be in DER or PEM format. PEM is a base64 encoded so we can use it while working on [1]. You can use keytool if needed to export certificate from keystore and then convert to PEM format. Thanks, Rajan > > Regards, > Volker > > [1]https://bugs.openjdk.java.net/browse/JDK-8193255 From weijun.wang at ORACLE.COM Mon Dec 11 09:50:42 2017 From: weijun.wang at ORACLE.COM (Weijun Wang) Date: Mon, 11 Dec 2017 17:50:42 +0800 Subject: RFR 8189131: Open-source the Oracle JDK Root Certificates In-Reply-To: References: <100a5b13-070d-0e56-ffd5-3da16e7a9c68@oracle.com> <28b7b2ae-1ea5-70b3-9136-b488659e6823@oracle.com> Message-ID: <5F199ECD-F51E-40AF-A7F7-078A5E9B728C@oracle.com> > On Dec 8, 2017, at 10:45 PM, Volker Simonis wrote: > > OK, I've opened the RFR "JDK-8193255: Root Certificates should be > stored in text format and assembled at build time" for this issue. In fact, I would recommend we directly release cacerts as a text file containing PEM certificates, for these reasons: - We are navigating away from JKS because it's not standard - Certificates in PKCS12 requires a password to read - I see no necessity for protecting cacerts, either for integrity or confidentiality, with a password - A publicly known password is worse than no password - Arbitrary comments (outside the ----BEGIN/END CERTIFICATE----- blocks) can be added as attributes Thanks Max From erik.helin at oracle.com Mon Dec 11 14:03:38 2017 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 11 Dec 2017 15:03:38 +0100 Subject: RFR: 8193189: Allow --boot-jdk to accept a .tar.gz compressed JDK image In-Reply-To: References: <63ef4155-627f-d802-af0c-5bde4696f599@oracle.com> <87ceca74-0154-8c19-ff9e-1d946498c054@oracle.com> <9fcec35f-f06b-3493-6715-64d1f986b288@oracle.com> Message-ID: <271eb627-e47c-6e77-d978-a0fa05d6a098@oracle.com> On 12/08/2017 05:37 PM, Erik Joelsson wrote: > This looks better. One more thing that I forgot in the last review, on > mkdir I recommend using the -p flag for nicer handling if the dir > already exists and in case CONFIGURESUPPORT_OUTPUTDIR has not yet been > created. Thanks Erik, great suggestion, implemented! > How does tar react if a bootjdk is already present in > CONFIGURESUPPORT_OUTPUTDIR? Should we delete first or just overwrite? I chose the "nuke from orbit" solution and just $RM -rf the boot-jdk directory :) New patches available at: - full: http://cr.openjdk.java.net/~ehelin/8193189/02/ - inc: http://cr.openjdk.java.net/~ehelin/8193189/01-02/ What do you think? Thanks, Erik > /Erik > > > On 2017-12-08 05:56, Erik Helin wrote: >> On 12/07/2017 07:05 PM, Erik Joelsson wrote: >>> Hello Erik, >>> >>> On macosx, the tar.gz distribution usually has the java home dir in >>> "jdk-9.jdk/Contents/Home". The -z and --strip-components flags for >>> tar probably works well with gnu tar, but we can only rely on that on >>> Linux and Windows. You need to write the unpack logic compatible with >>> both Solaris and bsd tar as well (yes, that means piping with gunzip >>> and manually finding the correct java home dir inside the exploded >>> file tree :). >>> >>> I would also like to see a better failure handling of a non existing >>> file/directory given to --with-boot-jdk. As it looks now, tar is >>> going to crap out. >> >> Thanks for the review! Please see new patches at: >> - full: http://cr.openjdk.java.net/~ehelin/8193189/01/ >> - inc: http://cr.openjdk.java.net/~ehelin/8193189/00-01/ >> >> What do you think? >> >> Thanks, >> Erik >> >>> Otherwise the idea seems decent enough. >>> >>> /Erik >>> >>> On 2017-12-07 09:05, Erik Helin wrote: >>>> Hi all, >>>> >>>> this small patch allows the --boot-jdk flag to configure to accept a >>>> gzip compressed JDK image. For example: >>>> >>>> ? $ wget >>>> http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz >>>> >>>> ? $ bash configure --with-boot-jdk=openjdk-9.0.1_linux-x64_bin.tar.gz >>>> >>>> The compressed image will be extracted into >>>> build//configure-support/boot-jdk. >>>> >>>> Enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8193189 >>>> >>>> Patch: >>>> http://cr.openjdk.java.net/~ehelin/8193189/00/ >>>> >>>> Testing: >>>> - configure and make locally on Linux x86-64 >>>> >>>> Thanks, >>>> Erik >>> > From erik.joelsson at oracle.com Mon Dec 11 15:14:06 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Dec 2017 07:14:06 -0800 Subject: RFR: 8193189: Allow --boot-jdk to accept a .tar.gz compressed JDK image In-Reply-To: <271eb627-e47c-6e77-d978-a0fa05d6a098@oracle.com> References: <63ef4155-627f-d802-af0c-5bde4696f599@oracle.com> <87ceca74-0154-8c19-ff9e-1d946498c054@oracle.com> <9fcec35f-f06b-3493-6715-64d1f986b288@oracle.com> <271eb627-e47c-6e77-d978-a0fa05d6a098@oracle.com> Message-ID: Looks good. /Erik On 2017-12-11 06:03, Erik Helin wrote: > On 12/08/2017 05:37 PM, Erik Joelsson wrote: >> This looks better. One more thing that I forgot in the last review, >> on mkdir I recommend using the -p flag for nicer handling if the dir >> already exists and in case CONFIGURESUPPORT_OUTPUTDIR has not yet >> been created. > > Thanks Erik, great suggestion, implemented! > >> How does tar react if a bootjdk is already present in >> CONFIGURESUPPORT_OUTPUTDIR? Should we delete first or just overwrite? > > I chose the "nuke from orbit" solution and just $RM -rf the boot-jdk > directory :) New patches available at: > > - full: http://cr.openjdk.java.net/~ehelin/8193189/02/ > - inc: http://cr.openjdk.java.net/~ehelin/8193189/01-02/ > > What do you think? > > Thanks, > Erik > >> /Erik >> >> >> On 2017-12-08 05:56, Erik Helin wrote: >>> On 12/07/2017 07:05 PM, Erik Joelsson wrote: >>>> Hello Erik, >>>> >>>> On macosx, the tar.gz distribution usually has the java home dir in >>>> "jdk-9.jdk/Contents/Home". The -z and --strip-components flags for >>>> tar probably works well with gnu tar, but we can only rely on that >>>> on Linux and Windows. You need to write the unpack logic compatible >>>> with both Solaris and bsd tar as well (yes, that means piping with >>>> gunzip and manually finding the correct java home dir inside the >>>> exploded file tree :). >>>> >>>> I would also like to see a better failure handling of a non >>>> existing file/directory given to --with-boot-jdk. As it looks now, >>>> tar is going to crap out. >>> >>> Thanks for the review! Please see new patches at: >>> - full: http://cr.openjdk.java.net/~ehelin/8193189/01/ >>> - inc: http://cr.openjdk.java.net/~ehelin/8193189/00-01/ >>> >>> What do you think? >>> >>> Thanks, >>> Erik >>> >>>> Otherwise the idea seems decent enough. >>>> >>>> /Erik >>>> >>>> On 2017-12-07 09:05, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this small patch allows the --boot-jdk flag to configure to accept >>>>> a gzip compressed JDK image. For example: >>>>> >>>>> ? $ wget >>>>> http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz >>>>> >>>>> ? $ bash configure --with-boot-jdk=openjdk-9.0.1_linux-x64_bin.tar.gz >>>>> >>>>> The compressed image will be extracted into >>>>> build//configure-support/boot-jdk. >>>>> >>>>> Enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8193189 >>>>> >>>>> Patch: >>>>> http://cr.openjdk.java.net/~ehelin/8193189/00/ >>>>> >>>>> Testing: >>>>> - configure and make locally on Linux x86-64 >>>>> >>>>> Thanks, >>>>> Erik >>>> >> From joe.darcy at oracle.com Tue Dec 12 07:04:40 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 11 Dec 2017 23:04:40 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 Message-ID: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> Hello, With the JDK 11 line of development opening up in a few days, a few changes are needed to prepared to turn a JDK 10 code base into a JDK 11 one including: JDK-8173382: Add -source 11 and -target 11 to javac JDK-8193291: Add SourceVersion.RELEASE_11 Webev: http://cr.openjdk.java.net/~darcy/8173382.1/ CSRs: JDK-8193350: Add -source 11 and -target 11 to javac JDK-8193351: Add SourceVersion.RELEASE_11 Please review the preliminary webrev and CSRs. Note that breaking with previous contentions, the current iteration of the change does *not* add -source/-target "1.11" as an alias for "11". Only "11" is recognized. I didn't see how to add support for an "11" value for "--release" so I problem listed two tests until that is sorted out. The build is simultaneously updated to user -source/-target 11, hence the inclusion of build-dev. Various langtools tests and test infrastructure is updated too. Thanks, -Joe From magnus.ihse.bursie at oracle.com Tue Dec 12 09:39:32 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 12 Dec 2017 10:39:32 +0100 Subject: RFR: 8193189: Allow --boot-jdk to accept a .tar.gz compressed JDK image In-Reply-To: <271eb627-e47c-6e77-d978-a0fa05d6a098@oracle.com> References: <63ef4155-627f-d802-af0c-5bde4696f599@oracle.com> <87ceca74-0154-8c19-ff9e-1d946498c054@oracle.com> <9fcec35f-f06b-3493-6715-64d1f986b288@oracle.com> <271eb627-e47c-6e77-d978-a0fa05d6a098@oracle.com> Message-ID: On 2017-12-11 15:03, Erik Helin wrote: > On 12/08/2017 05:37 PM, Erik Joelsson wrote: >> This looks better. One more thing that I forgot in the last review, >> on mkdir I recommend using the -p flag for nicer handling if the dir >> already exists and in case CONFIGURESUPPORT_OUTPUTDIR has not yet >> been created. > > Thanks Erik, great suggestion, implemented! > >> How does tar react if a bootjdk is already present in >> CONFIGURESUPPORT_OUTPUTDIR? Should we delete first or just overwrite? > > I chose the "nuke from orbit" solution and just $RM -rf the boot-jdk > directory :) New patches available at: > > - full: http://cr.openjdk.java.net/~ehelin/8193189/02/ > - inc: http://cr.openjdk.java.net/~ehelin/8193189/01-02/ Looks good to me. /Magnus > > What do you think? > > Thanks, > Erik > >> /Erik >> >> >> On 2017-12-08 05:56, Erik Helin wrote: >>> On 12/07/2017 07:05 PM, Erik Joelsson wrote: >>>> Hello Erik, >>>> >>>> On macosx, the tar.gz distribution usually has the java home dir in >>>> "jdk-9.jdk/Contents/Home". The -z and --strip-components flags for >>>> tar probably works well with gnu tar, but we can only rely on that >>>> on Linux and Windows. You need to write the unpack logic compatible >>>> with both Solaris and bsd tar as well (yes, that means piping with >>>> gunzip and manually finding the correct java home dir inside the >>>> exploded file tree :). >>>> >>>> I would also like to see a better failure handling of a non >>>> existing file/directory given to --with-boot-jdk. As it looks now, >>>> tar is going to crap out. >>> >>> Thanks for the review! Please see new patches at: >>> - full: http://cr.openjdk.java.net/~ehelin/8193189/01/ >>> - inc: http://cr.openjdk.java.net/~ehelin/8193189/00-01/ >>> >>> What do you think? >>> >>> Thanks, >>> Erik >>> >>>> Otherwise the idea seems decent enough. >>>> >>>> /Erik >>>> >>>> On 2017-12-07 09:05, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this small patch allows the --boot-jdk flag to configure to accept >>>>> a gzip compressed JDK image. For example: >>>>> >>>>> ? $ wget >>>>> http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz >>>>> >>>>> ? $ bash configure --with-boot-jdk=openjdk-9.0.1_linux-x64_bin.tar.gz >>>>> >>>>> The compressed image will be extracted into >>>>> build//configure-support/boot-jdk. >>>>> >>>>> Enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8193189 >>>>> >>>>> Patch: >>>>> http://cr.openjdk.java.net/~ehelin/8193189/00/ >>>>> >>>>> Testing: >>>>> - configure and make locally on Linux x86-64 >>>>> >>>>> Thanks, >>>>> Erik >>>> >> From erik.joelsson at oracle.com Tue Dec 12 15:36:11 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Dec 2017 16:36:11 +0100 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> Message-ID: <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com> Build change looks good. /Erik On 2017-12-12 08:04, joe darcy wrote: > Hello, > > With the JDK 11 line of development opening up in a few days, a few > changes are needed to prepared to turn a JDK 10 code base into a JDK > 11 one including: > > ??? JDK-8173382: Add -source 11 and -target 11 to javac > ??? JDK-8193291: Add SourceVersion.RELEASE_11 > > ??? Webev: > ??????? http://cr.openjdk.java.net/~darcy/8173382.1/ > ??? CSRs: > ??????? JDK-8193350: Add -source 11 and -target 11 to javac > ??????? JDK-8193351: Add SourceVersion.RELEASE_11 > > Please review the preliminary webrev and CSRs. > > Note that breaking with previous contentions, the current iteration of > the change does *not* add -source/-target "1.11" as an alias for "11". > Only "11" is recognized. > > I didn't see how to add support for an "11" value for "--release" so I > problem listed two tests until that is sorted out. > > The build is simultaneously updated to user -source/-target 11, hence > the inclusion of build-dev. > > Various langtools tests and test infrastructure is updated too. > > Thanks, > > -Joe > From paul.sandoz at oracle.com Tue Dec 12 17:31:58 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Dec 2017 09:31:58 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> Message-ID: Hi Joe, I would like to see the class file version increment [*] in the same patch (the unified repo makes this easier now). Then we have everything in one changeset (except for any ctsym changes?) that can be easily templated when the next increment is required, since we will be doing this far more regularly from now on. Are there any technical impediments as to why this would be problematic? Thanks, Paul. [*] here is the increment to 54 http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54 > On 11 Dec 2017, at 23:04, joe darcy wrote: > > Hello, > > With the JDK 11 line of development opening up in a few days, a few changes are needed to prepared to turn a JDK 10 code base into a JDK 11 one including: > > JDK-8173382: Add -source 11 and -target 11 to javac > JDK-8193291: Add SourceVersion.RELEASE_11 > > Webev: > http://cr.openjdk.java.net/~darcy/8173382.1/ > CSRs: > JDK-8193350: Add -source 11 and -target 11 to javac > JDK-8193351: Add SourceVersion.RELEASE_11 > > Please review the preliminary webrev and CSRs. > > Note that breaking with previous contentions, the current iteration of the change does *not* add -source/-target "1.11" as an alias for "11". Only "11" is recognized. > > I didn't see how to add support for an "11" value for "--release" so I problem listed two tests until that is sorted out. > > The build is simultaneously updated to user -source/-target 11, hence the inclusion of build-dev. > > Various langtools tests and test infrastructure is updated too. > > Thanks, > > -Joe > From joe.darcy at oracle.com Tue Dec 12 17:52:08 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 12 Dec 2017 09:52:08 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> Message-ID: <48fdaf67-bf68-2701-8951-753699029bf4@oracle.com> Hi Paul, There is sense in working in including the class file version update at the same time if the added complexity doesn't delay the changes. Did the patch for the increment to 54 require previous changes in the bundled ASM? Thanks, -Joe On 12/12/2017 9:31 AM, Paul Sandoz wrote: > Hi Joe, > > I would like to see the class file version increment [*] in the same > patch (the unified repo makes this easier now). > > Then we have everything in one changeset (except for any ctsym > changes?) that can be easily templated when the next increment is > required, since we will be doing this far more regularly from now on. > > Are there any technical impediments as to why this would be problematic? > > Thanks, > Paul. > > [*] here is the increment to 54 > http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54 > From paul.sandoz at oracle.com Tue Dec 12 18:03:31 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Dec 2017 10:03:31 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <48fdaf67-bf68-2701-8951-753699029bf4@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <48fdaf67-bf68-2701-8951-753699029bf4@oracle.com> Message-ID: <95C47796-7ED5-4855-95E4-85724A73143A@oracle.com> > On 12 Dec 2017, at 09:52, joe darcy wrote: > > Hi Paul, > > There is sense in working in including the class file version update at the same time if the added complexity doesn't delay the changes. > I sense it should be so complex and delay since the additional code changes can be copied from the prior changes which recently went through significant review. If it helps, and since i am proposing additional work, i can merge in such changes into your patch. > Did the patch for the increment to 54 require previous changes in the bundled ASM? > The increment in and of itself requires only minimal changes to the internal ASM, it does not require the integration of a new version of ASM. Constant dynamic only requires a minimal update to the internal ASM to skip over the new constant pool entry, since we don?t currently use ASM process or generate constant dynamic entries. Paul. > Thanks, > > -Joe > > > On 12/12/2017 9:31 AM, Paul Sandoz wrote: >> Hi Joe, >> >> I would like to see the class file version increment [*] in the same patch (the unified repo makes this easier now). >> >> Then we have everything in one changeset (except for any ctsym changes?) that can be easily templated when the next increment is required, since we will be doing this far more regularly from now on. >> >> Are there any technical impediments as to why this would be problematic? >> >> Thanks, >> Paul. >> >> [*] here is the increment to 54 http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54 >> > From paul.sandoz at oracle.com Tue Dec 12 18:17:46 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Dec 2017 10:17:46 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <95C47796-7ED5-4855-95E4-85724A73143A@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <48fdaf67-bf68-2701-8951-753699029bf4@oracle.com> <95C47796-7ED5-4855-95E4-85724A73143A@oracle.com> Message-ID: > On 12 Dec 2017, at 10:03, Paul Sandoz wrote: > > > >> On 12 Dec 2017, at 09:52, joe darcy wrote: >> >> Hi Paul, >> >> There is sense in working in including the class file version update at the same time if the added complexity doesn't delay the changes. >> > > I sense it should be so complex and delay since the additional code changes can be copied from the prior changes which recently went through significant review. "I sense it should *not* be?? Paul. From david.holmes at oracle.com Tue Dec 12 21:11:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 07:11:06 +1000 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> Message-ID: <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> Hi Joe, On 12/12/2017 5:04 PM, joe darcy wrote: > Hello, > > With the JDK 11 line of development opening up in a few days, a few > changes are needed to prepared to turn a JDK 10 code base into a JDK 11 > one including: > > ??? JDK-8173382: Add -source 11 and -target 11 to javac > ??? JDK-8193291: Add SourceVersion.RELEASE_11 > > ??? Webev: > ??????? http://cr.openjdk.java.net/~darcy/8173382.1/ > ??? CSRs: > ??????? JDK-8193350: Add -source 11 and -target 11 to javac > ??????? JDK-8193351: Add SourceVersion.RELEASE_11 > > Please review the preliminary webrev and CSRs. I don't see a change to the actual JDK version as part of this ?? hat's the change that will cause hotspot to fail to build in debug mode as soon as the version is bumped - I filed: https://bugs.openjdk.java.net/browse/JDK-8193364 to at least get over that. > Note that breaking with previous contentions, the current iteration of > the change does *not* add -source/-target "1.11" as an alias for "11". > Only "11" is recognized. > > I didn't see how to add support for an "11" value for "--release" so I > problem listed two tests until that is sorted out. Okay. It's very hard to discern what uses of "RELEASE_11" pertain to "-release" support and what just pertain to -source/-target. ?? > The build is simultaneously updated to user -source/-target 11, hence > the inclusion of build-dev. > > Various langtools tests and test infrastructure is updated too. test/langtools/tools/javac/versions/Versions.java looks like it needed some updates for JDK 10! Thanks, David > > Thanks, > > -Joe > From david.holmes at oracle.com Tue Dec 12 21:16:58 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 07:16:58 +1000 Subject: Why are hotspot tests not always linked with libc? Message-ID: <8bac7bb2-6362-1e9b-c31f-12e61864a83c@oracle.com> In make/test/JtregNativeHotspot.gmk we have this ever expanding list: ifeq ($(TOOLCHAIN_TYPE), solstudio) BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_liboverflow := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libSimpleClassFileLoadHook := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libGetOwnedMonitorInfoTest := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libGetNamedModuleTest := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libIsModifiableModuleTest := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleReadsTest := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleExportsAndOpensTest := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleUsesAndProvidesTest := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAClassFileLoadHook := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAClassLoadPrepare := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAThreadStart := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libAllowedFunctions := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libRedefineDoubleDelete := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc endif Why do we need to do this instead of always linking in the basic libraries? We're investigating a test-image build failure on Solaris x64 slowdebug that seems to be caused by implicit use of functions in libc. Thanks, David From joe.darcy at oracle.com Tue Dec 12 21:27:06 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 12 Dec 2017 13:27:06 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> Message-ID: <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> Hi David, On 12/12/2017 1:11 PM, David Holmes wrote: > Hi Joe, > > On 12/12/2017 5:04 PM, joe darcy wrote: >> Hello, >> >> With the JDK 11 line of development opening up in a few days, a few >> changes are needed to prepared to turn a JDK 10 code base into a JDK >> 11 one including: >> >> JDK-8173382: Add -source 11 and -target 11 to javac >> JDK-8193291: Add SourceVersion.RELEASE_11 >> >> Webev: >> http://cr.openjdk.java.net/~darcy/8173382.1/ >> CSRs: >> JDK-8193350: Add -source 11 and -target 11 to javac >> JDK-8193351: Add SourceVersion.RELEASE_11 >> >> Please review the preliminary webrev and CSRs. > > I don't see a change to the actual JDK version as part of this ?? Correct; the webrev to date is the langtools portion of the new JDK groundbreaking, the same subset of groundbreaking I looked at for the 9 -> 10 transition. Other pieces are needed too, including HotSpot changes and the actual version update. > hat's the change that will cause hotspot to fail to build in debug > mode as soon as the version is bumped - I filed: > > https://bugs.openjdk.java.net/browse/JDK-8193364 > > to at least get over that. > >> Note that breaking with previous contentions, the current iteration >> of the change does *not* add -source/-target "1.11" as an alias for >> "11". Only "11" is recognized. >> >> I didn't see how to add support for an "11" value for "--release" so >> I problem listed two tests until that is sorted out. > > Okay. It's very hard to discern what uses of "RELEASE_11" pertain to > "-release" support and what just pertain to -source/-target. ?? In this iteration, mostly -source/-target. The code that populates the list of releases supported by --release has had some updates since I last looked at it and I didn't figure that part out before sending out this review. > >> The build is simultaneously updated to user -source/-target 11, hence >> the inclusion of build-dev. >> >> Various langtools tests and test infrastructure is updated too. > > test/langtools/tools/javac/versions/Versions.java looks like it needed > some updates for JDK 10! Better late than never ;-) Thanks, -Joe From david.holmes at oracle.com Tue Dec 12 21:32:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 07:32:04 +1000 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> Message-ID: <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> Hi Joe, On 13/12/2017 7:27 AM, joe darcy wrote: > Hi David, > > > On 12/12/2017 1:11 PM, David Holmes wrote: >> Hi Joe, >> >> On 12/12/2017 5:04 PM, joe darcy wrote: >>> Hello, >>> >>> With the JDK 11 line of development opening up in a few days, a few >>> changes are needed to prepared to turn a JDK 10 code base into a JDK >>> 11 one including: >>> >>> ???? JDK-8173382: Add -source 11 and -target 11 to javac >>> ???? JDK-8193291: Add SourceVersion.RELEASE_11 >>> >>> ???? Webev: >>> ???????? http://cr.openjdk.java.net/~darcy/8173382.1/ >>> ???? CSRs: >>> ???????? JDK-8193350: Add -source 11 and -target 11 to javac >>> ???????? JDK-8193351: Add SourceVersion.RELEASE_11 >>> >>> Please review the preliminary webrev and CSRs. >> >> I don't see a change to the actual JDK version as part of this ?? > > Correct; the webrev to date is the langtools portion of the new JDK > groundbreaking, the same subset of groundbreaking I looked at for the 9 > -> 10 transition. Other pieces are needed too, including HotSpot changes > and the actual version update. So what is the overall transition strategy here? I don't see how you can change javac to default to -source/-target 11 prior to bumping the actual version to 11. Or do you expect all the additional pieces to come together at the same time? Thanks, David >> hat's the change that will cause hotspot to fail to build in debug >> mode as soon as the version is bumped - I filed: >> >> https://bugs.openjdk.java.net/browse/JDK-8193364 >> >> to at least get over that. >> >>> Note that breaking with previous contentions, the current iteration >>> of the change does *not* add -source/-target "1.11" as an alias for >>> "11". Only "11" is recognized. >>> >>> I didn't see how to add support for an "11" value for "--release" so >>> I problem listed two tests until that is sorted out. >> >> Okay. It's very hard to discern what uses of "RELEASE_11" pertain to >> "-release" support and what just pertain to -source/-target. ?? > > In this iteration, mostly -source/-target. The code that populates the > list of releases supported by --release has had some updates since I > last looked at it and I didn't figure that part out before sending out > this review. > >> >>> The build is simultaneously updated to user -source/-target 11, hence >>> the inclusion of build-dev. >>> >>> Various langtools tests and test infrastructure is updated too. >> >> test/langtools/tools/javac/versions/Versions.java looks like it needed >> some updates for JDK 10! > > Better late than never ;-) > > Thanks, > > -Joe > From joe.darcy at oracle.com Tue Dec 12 23:20:26 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 12 Dec 2017 15:20:26 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> Message-ID: <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> Hi David, On 12/12/2017 1:32 PM, David Holmes wrote: > Hi Joe, > > On 13/12/2017 7:27 AM, joe darcy wrote: >> Hi David, >> >> >> On 12/12/2017 1:11 PM, David Holmes wrote: >>> Hi Joe, >>> >>> On 12/12/2017 5:04 PM, joe darcy wrote: >>>> Hello, >>>> >>>> With the JDK 11 line of development opening up in a few days, a few >>>> changes are needed to prepared to turn a JDK 10 code base into a >>>> JDK 11 one including: >>>> >>>> JDK-8173382: Add -source 11 and -target 11 to javac >>>> JDK-8193291: Add SourceVersion.RELEASE_11 >>>> >>>> Webev: >>>> http://cr.openjdk.java.net/~darcy/8173382.1/ >>>> CSRs: >>>> JDK-8193350: Add -source 11 and -target 11 to javac >>>> JDK-8193351: Add SourceVersion.RELEASE_11 >>>> >>>> Please review the preliminary webrev and CSRs. >>> >>> I don't see a change to the actual JDK version as part of this ?? >> >> Correct; the webrev to date is the langtools portion of the new JDK >> groundbreaking, the same subset of groundbreaking I looked at for the >> 9 -> 10 transition. Other pieces are needed too, including HotSpot >> changes and the actual version update. > > So what is the overall transition strategy here? I don't see how you > can change javac to default to -source/-target 11 prior to bumping the > actual version to 11. Or do you expect all the additional pieces to > come together at the same time? > For background, what we've done in the past is at the very start of a new JDK release, first create -source/-target ${N+1} that begin as aliases for ${N} and are the default -source/-target for javac. [1] As new language features are developed, the javac implementation adds allowFeatureFoo() predicates which turn into return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature So the operational distinction between -source ${N} and -source ${N+1} comes about after language changes have been made for release ${N+1}. For -target, since there is often not a hard dependency between new Java language features and JVM features, an operational distinction between successive values of -target, and thus successive class file versions, can come about later in the release. For example, in JDK 10 the language feature var/local variable type inference enabled by -source 10 was in JDK 10 builds a few months before -target 10 mapped to an updated class file version. We could follow the same path for the JDK 10 -> 11 transition. Paul has suggested also updating the class file version at the same time this time around. HTH, -Joe [1] Way back when, the new -source/-target values were added without simultaneously being made the default. This increased maintenance costs of javac tests and led us to implement the current policy. From daniel.daugherty at oracle.com Wed Dec 13 02:13:04 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Dec 2017 21:13:04 -0500 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build Message-ID: Greetings, I have a 1-liner fix to solve a Solaris slowdebug test-image build problem: ??? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build ??? https://bugs.openjdk.java.net/browse/JDK-8193407 Here is the context diff: $ hg diff diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 -0500 +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 -0500 @@ -113,6 +113,7 @@ ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc ?endif ?ifeq ($(OPENJDK_TARGET_OS), linux) David Holmes suggested the possible fix and I have tested the fix with Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. David is the first (R)eviewer. Since this affects a Compiler team test, it would be good to hear from someone on the Compiler team. Since it is a Makefile change, it would be good to hear from someone on the build-dev at ... alias... Thanks, in advance, for questions, comments, or suggestions. Dan From david.holmes at oracle.com Wed Dec 13 02:16:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 12:16:09 +1000 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: References: Message-ID: <12514e92-a045-154c-655f-132a693584c4@oracle.com> Hi Dan, On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a 1-liner fix to solve a Solaris slowdebug test-image build > problem: > > ??? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build > ??? https://bugs.openjdk.java.net/browse/JDK-8193407 > > Here is the context diff: > > $ hg diff > diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk > --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 -0500 > +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 -0500 > @@ -113,6 +113,7 @@ > ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc > ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc > ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc > +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc > ?endif > > ?ifeq ($(OPENJDK_TARGET_OS), linux) > > > David Holmes suggested the possible fix and I have tested the fix with > Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. Thanks for that! > David is the first (R)eviewer. Since this affects a Compiler team > test, it would be good to hear from someone on the Compiler team. > Since it is a Makefile change, it would be good to hear from someone > on the build-dev at ... alias... I think that is a bit of overkill. I was going to say push this under trivial rules! Aside: I've started a separate email thread on why we need to list -lc explicitly in the makefile. Thanks, David > Thanks, in advance, for questions, comments, or suggestions. > > Dan > From vladimir.kozlov at oracle.com Wed Dec 13 02:24:04 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Dec 2017 18:24:04 -0800 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: <12514e92-a045-154c-655f-132a693584c4@oracle.com> References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> Message-ID: Reviewed. Looks good. Thanks, Vladimir On 12/12/17 6:16 PM, David Holmes wrote: > Hi Dan, > > On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a 1-liner fix to solve a Solaris slowdebug test-image build >> problem: >> >> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >> >> Here is the context diff: >> >> $ hg diff >> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 -0500 >> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 -0500 >> @@ -113,6 +113,7 @@ >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := >> -lc >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >> ??endif >> >> ??ifeq ($(OPENJDK_TARGET_OS), linux) >> >> >> David Holmes suggested the possible fix and I have tested the fix with >> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. > > Thanks for that! > >> David is the first (R)eviewer. Since this affects a Compiler team >> test, it would be good to hear from someone on the Compiler team. >> Since it is a Makefile change, it would be good to hear from someone >> on the build-dev at ... alias... > > I think that is a bit of overkill. I was going to say push this under > trivial rules! > > Aside: I've started a separate email thread on why we need to list -lc > explicitly in the makefile. > > Thanks, > David > >> Thanks, in advance, for questions, comments, or suggestions. >> >> Dan >> From daniel.daugherty at oracle.com Wed Dec 13 02:19:23 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Dec 2017 21:19:23 -0500 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: <12514e92-a045-154c-655f-132a693584c4@oracle.com> References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> Message-ID: <55dffa5e-ba86-ed99-d56d-0e819e56e96e@oracle.com> On 12/12/17 9:16 PM, David Holmes wrote: > Hi Dan, > > On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a 1-liner fix to solve a Solaris slowdebug test-image build >> problem: >> >> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >> >> Here is the context diff: >> >> $ hg diff >> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 -0500 >> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 -0500 >> @@ -113,6 +113,7 @@ >> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >> ??endif >> >> ??ifeq ($(OPENJDK_TARGET_OS), linux) >> >> >> David Holmes suggested the possible fix and I have tested the fix with >> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. > > Thanks for that! > >> David is the first (R)eviewer. Since this affects a Compiler team >> test, it would be good to hear from someone on the Compiler team. >> Since it is a Makefile change, it would be good to hear from someone >> on the build-dev at ... alias... > > I think that is a bit of overkill. I was going to say push this under > trivial rules! No problem. I'm just trying to be polite... :-) I'll go ahead and push it shortly... I'll wait long enough to clear my email queue and we'll see if anyone else chimes in... :-) > Aside: I've started a separate email thread on why we need to list -lc > explicitly in the makefile. Yup. It would be good to get rid of that if we can... Dan > > Thanks, > David > >> Thanks, in advance, for questions, comments, or suggestions. >> >> Dan >> From daniel.daugherty at oracle.com Wed Dec 13 02:24:46 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Dec 2017 21:24:46 -0500 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> Message-ID: <3e35557e-2535-9dc8-30cd-393d7376526d@oracle.com> Vladimir, Thanks for the review! Dan On 12/12/17 9:24 PM, Vladimir Kozlov wrote: > Reviewed. Looks good. > > Thanks, > Vladimir > > On 12/12/17 6:16 PM, David Holmes wrote: >> Hi Dan, >> >> On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a 1-liner fix to solve a Solaris slowdebug test-image build >>> problem: >>> >>> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >>> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >>> >>> Here is the context diff: >>> >>> $ hg diff >>> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >>> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 >>> -0500 >>> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 >>> -0500 >>> @@ -113,6 +113,7 @@ >>> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >>> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >>> ??endif >>> >>> ??ifeq ($(OPENJDK_TARGET_OS), linux) >>> >>> >>> David Holmes suggested the possible fix and I have tested the fix with >>> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. >> >> Thanks for that! >> >>> David is the first (R)eviewer. Since this affects a Compiler team >>> test, it would be good to hear from someone on the Compiler team. >>> Since it is a Makefile change, it would be good to hear from someone >>> on the build-dev at ... alias... >> >> I think that is a bit of overkill. I was going to say push this under >> trivial rules! >> >> Aside: I've started a separate email thread on why we need to list >> -lc explicitly in the makefile. >> >> Thanks, >> David >> >>> Thanks, in advance, for questions, comments, or suggestions. >>> >>> Dan >>> From david.holmes at oracle.com Wed Dec 13 04:56:29 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 14:56:29 +1000 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> Message-ID: <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> Hi Joe, On 13/12/2017 9:20 AM, joe darcy wrote: > Hi David, > > > On 12/12/2017 1:32 PM, David Holmes wrote: >> Hi Joe, >> >> On 13/12/2017 7:27 AM, joe darcy wrote: >>> Hi David, >>> >>> >>> On 12/12/2017 1:11 PM, David Holmes wrote: >>>> Hi Joe, >>>> >>>> On 12/12/2017 5:04 PM, joe darcy wrote: >>>>> Hello, >>>>> >>>>> With the JDK 11 line of development opening up in a few days, a few >>>>> changes are needed to prepared to turn a JDK 10 code base into a >>>>> JDK 11 one including: >>>>> >>>>> ???? JDK-8173382: Add -source 11 and -target 11 to javac >>>>> ???? JDK-8193291: Add SourceVersion.RELEASE_11 >>>>> >>>>> ???? Webev: >>>>> ???????? http://cr.openjdk.java.net/~darcy/8173382.1/ >>>>> ???? CSRs: >>>>> ???????? JDK-8193350: Add -source 11 and -target 11 to javac >>>>> ???????? JDK-8193351: Add SourceVersion.RELEASE_11 >>>>> >>>>> Please review the preliminary webrev and CSRs. >>>> >>>> I don't see a change to the actual JDK version as part of this ?? >>> >>> Correct; the webrev to date is the langtools portion of the new JDK >>> groundbreaking, the same subset of groundbreaking I looked at for the >>> 9 -> 10 transition. Other pieces are needed too, including HotSpot >>> changes and the actual version update. >> >> So what is the overall transition strategy here? I don't see how you >> can change javac to default to -source/-target 11 prior to bumping the >> actual version to 11. Or do you expect all the additional pieces to >> come together at the same time? >> > > For background, what we've done in the past is at the very start of a > new JDK release, first create -source/-target ${N+1} that begin as > aliases for ${N} and are the default -source/-target for javac. [1] As > new language features are developed, the javac implementation adds > allowFeatureFoo() predicates which turn into > > ??? return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature > > So the operational distinction between -source ${N} and -source ${N+1} > comes about after language changes have been made for release ${N+1}. > For -target, since there is often not a hard dependency between new Java > language features and JVM features, an operational distinction between > successive values of -target, and thus successive class file versions, > can come about later in the release. For example, in JDK 10 the language > feature var/local variable type inference enabled by -source 10 was in > JDK 10 builds a few months before -target 10 mapped to an updated class > file version. > > We could follow the same path for the JDK 10 -> 11 transition. Paul has > suggested also updating the class file version at the same time this > time around. I'm a little unclear as to the distinction between allowing for -source/-target 11 and switching them to be the default. Especially if you incorporate the classfile version change then we would have a JDK reporting itself as JDK 10 but which uses -source/-target 11 and produces version 55 classfiles. I would have thought it a two step process: - prepare for new defaults - switch to new defaults (in conjunction with version change) Anyway, none of the proposed changes have any impact on hotspot AFAICT. It is only when the actual version is updated to 11 that hotspot, and other entities will have to be updated. I'm still unclear if someone is actually driving the entire "update to version 11" process? Is there an umbrella issue for it? Thanks, David > > HTH, > > -Joe > > [1] Way back when, the new -source/-target values were added without > simultaneously being made the default. This increased maintenance costs > of javac tests and led us to implement the current policy. From erik.joelsson at oracle.com Wed Dec 13 09:01:26 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Dec 2017 10:01:26 +0100 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: <55dffa5e-ba86-ed99-d56d-0e819e56e96e@oracle.com> References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> <55dffa5e-ba86-ed99-d56d-0e819e56e96e@oracle.com> Message-ID: On 2017-12-13 03:19, Daniel D. Daugherty wrote: > On 12/12/17 9:16 PM, David Holmes wrote: >> Hi Dan, >> >> On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a 1-liner fix to solve a Solaris slowdebug test-image build >>> problem: >>> >>> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >>> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >>> >>> Here is the context diff: >>> >>> $ hg diff >>> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >>> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 >>> -0500 >>> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 >>> -0500 >>> @@ -113,6 +113,7 @@ >>> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >>> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >>> ??endif >>> >>> ??ifeq ($(OPENJDK_TARGET_OS), linux) >>> >>> >>> David Holmes suggested the possible fix and I have tested the fix with >>> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. >> >> Thanks for that! >> >>> David is the first (R)eviewer. Since this affects a Compiler team >>> test, it would be good to hear from someone on the Compiler team. >>> Since it is a Makefile change, it would be good to hear from someone >>> on the build-dev at ... alias... >> >> I think that is a bit of overkill. I was going to say push this under >> trivial rules! > > No problem. I'm just trying to be polite... :-) > > I'll go ahead and push it shortly... I'll wait long enough to clear my > email queue and we'll see if anyone else chimes in... :-) > I agree that it's trivial, but appreciate the cross post to build-dev so that we are in the loop. /Erik > >> Aside: I've started a separate email thread on why we need to list >> -lc explicitly in the makefile. > > Yup. It would be good to get rid of that if we can... > > Dan > > >> >> Thanks, >> David >> >>> Thanks, in advance, for questions, comments, or suggestions. >>> >>> Dan >>> > From erik.joelsson at oracle.com Wed Dec 13 08:59:39 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Dec 2017 09:59:39 +0100 Subject: Why are hotspot tests not always linked with libc? In-Reply-To: <8bac7bb2-6362-1e9b-c31f-12e61864a83c@oracle.com> References: <8bac7bb2-6362-1e9b-c31f-12e61864a83c@oracle.com> Message-ID: I agree that it should just always be added automatically when linking with solstudio. /Erik On 2017-12-12 22:16, David Holmes wrote: > In make/test/JtregNativeHotspot.gmk we have this ever expanding list: > > ifeq ($(TOOLCHAIN_TYPE), solstudio) > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_liboverflow := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libSimpleClassFileLoadHook := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libGetOwnedMonitorInfoTest := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libGetNamedModuleTest := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libIsModifiableModuleTest := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleReadsTest := -lc > > BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleExportsAndOpensTest > := -lc > > BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleUsesAndProvidesTest > := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAClassFileLoadHook := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAClassLoadPrepare := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAThreadStart := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libAllowedFunctions := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libRedefineDoubleDelete := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc > ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc > endif > > Why do we need to do this instead of always linking in the basic > libraries? > > We're investigating a test-image build failure on Solaris x64 > slowdebug that seems to be caused by implicit use of functions in libc. > > Thanks, > David From magnus.ihse.bursie at oracle.com Wed Dec 13 11:58:27 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 13 Dec 2017 12:58:27 +0100 Subject: Why are hotspot tests not always linked with libc? In-Reply-To: References: <8bac7bb2-6362-1e9b-c31f-12e61864a83c@oracle.com> Message-ID: <32d20458-d589-317f-a89c-871b56f18502@oracle.com> On 2017-12-13 09:59, Erik Joelsson wrote: > I agree that it should just always be added automatically when linking > with solstudio. Agree. In fact, some of the common libraries, like pthread, that is not likely to cause problems if linked but not used, could probably be added as well to all libraries, so we can minimize the number of test specific CFLAGS/LIBS. /Magnus > > /Erik > > > On 2017-12-12 22:16, David Holmes wrote: >> In make/test/JtregNativeHotspot.gmk we have this ever expanding list: >> >> ifeq ($(TOOLCHAIN_TYPE), solstudio) >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_liboverflow := -lc >> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libSimpleClassFileLoadHook := -lc >> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libGetOwnedMonitorInfoTest := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libGetNamedModuleTest := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libIsModifiableModuleTest := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleReadsTest := -lc >> >> BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleExportsAndOpensTest >> := -lc >> >> BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAddModuleUsesAndProvidesTest >> := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAClassFileLoadHook := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAClassLoadPrepare := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libMAAThreadStart := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libAllowedFunctions := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libRedefineDoubleDelete := -lc >> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >> ??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >> endif >> >> Why do we need to do this instead of always linking in the basic >> libraries? >> >> We're investigating a test-image build failure on Solaris x64 >> slowdebug that seems to be caused by implicit use of functions in libc. >> >> Thanks, >> David > From daniel.daugherty at oracle.com Wed Dec 13 14:01:03 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Dec 2017 09:01:03 -0500 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> <55dffa5e-ba86-ed99-d56d-0e819e56e96e@oracle.com> Message-ID: <65cefd55-caac-f553-520f-e4a22a650229@oracle.com> On 12/13/17 4:01 AM, Erik Joelsson wrote: > On 2017-12-13 03:19, Daniel D. Daugherty wrote: >> On 12/12/17 9:16 PM, David Holmes wrote: >>> Hi Dan, >>> >>> On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a 1-liner fix to solve a Solaris slowdebug test-image build >>>> problem: >>>> >>>> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >>>> >>>> Here is the context diff: >>>> >>>> $ hg diff >>>> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >>>> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 >>>> -0500 >>>> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 >>>> -0500 >>>> @@ -113,6 +113,7 @@ >>>> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >>>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >>>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >>>> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >>>> ??endif >>>> >>>> ??ifeq ($(OPENJDK_TARGET_OS), linux) >>>> >>>> >>>> David Holmes suggested the possible fix and I have tested the fix with >>>> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. >>> >>> Thanks for that! >>> >>>> David is the first (R)eviewer. Since this affects a Compiler team >>>> test, it would be good to hear from someone on the Compiler team. >>>> Since it is a Makefile change, it would be good to hear from someone >>>> on the build-dev at ... alias... >>> >>> I think that is a bit of overkill. I was going to say push this >>> under trivial rules! >> >> No problem. I'm just trying to be polite... :-) >> >> I'll go ahead and push it shortly... I'll wait long enough to clear my >> email queue and we'll see if anyone else chimes in... :-) >> > I agree that it's trivial, but appreciate the cross post to build-dev > so that we are in the loop. Thanks for the review! Dan > > /Erik >> >>> Aside: I've started a separate email thread on why we need to list >>> -lc explicitly in the makefile. >> >> Yup. It would be good to get rid of that if we can... >> >> Dan >> >> >>> >>> Thanks, >>> David >>> >>>> Thanks, in advance, for questions, comments, or suggestions. >>>> >>>> Dan >>>> >> > From paul.sandoz at oracle.com Wed Dec 13 16:44:33 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 13 Dec 2017 08:44:33 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> Message-ID: <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> > On 12 Dec 2017, at 20:56, David Holmes wrote: > > Anyway, none of the proposed changes have any impact on hotspot AFAICT. It is only when the actual version is updated to 11 that hotspot, and other entities will have to be updated. I'm still unclear if someone is actually driving the entire "update to version 11" process? Is there an umbrella issue for it? > No yet, i was hoping we could consolidate as much as possible under one issue thereby minimising coordination/process i.e. combine the release and class file versions under one patch. Then stand back and see what is missing e.g. ctsym stuff etc. Paul. From paul.sandoz at oracle.com Wed Dec 13 18:22:33 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 13 Dec 2017 10:22:33 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> Message-ID: <65256BE6-46F9-4633-A6FA-455D58787C3A@oracle.com> Joe, Here's a patch on top of your patch: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-release-classfile-version/webrev/ Currently building/testing with both patches applied. Paul. > On 13 Dec 2017, at 08:44, Paul Sandoz wrote: > > > >> On 12 Dec 2017, at 20:56, David Holmes wrote: >> >> Anyway, none of the proposed changes have any impact on hotspot AFAICT. It is only when the actual version is updated to 11 that hotspot, and other entities will have to be updated. I'm still unclear if someone is actually driving the entire "update to version 11" process? Is there an umbrella issue for it? >> > > No yet, i was hoping we could consolidate as much as possible under one issue thereby minimising coordination/process i.e. combine the release and class file versions under one patch. Then stand back and see what is missing e.g. ctsym stuff etc. > > Paul. From joe.darcy at oracle.com Wed Dec 13 18:36:33 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 13 Dec 2017 10:36:33 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> Message-ID: Hi David, On 12/12/2017 8:56 PM, David Holmes wrote: > Hi Joe, > > On 13/12/2017 9:20 AM, joe darcy wrote: >> Hi David, >> >> >> On 12/12/2017 1:32 PM, David Holmes wrote: >>> [snip] >>> >> >> For background, what we've done in the past is at the very start of a >> new JDK release, first create -source/-target ${N+1} that begin as >> aliases for ${N} and are the default -source/-target for javac. [1] >> As new language features are developed, the javac implementation adds >> allowFeatureFoo() predicates which turn into >> >> return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature >> >> So the operational distinction between -source ${N} and -source >> ${N+1} comes about after language changes have been made for release >> ${N+1}. For -target, since there is often not a hard dependency >> between new Java language features and JVM features, an operational >> distinction between successive values of -target, and thus successive >> class file versions, can come about later in the release. For >> example, in JDK 10 the language feature var/local variable type >> inference enabled by -source 10 was in JDK 10 builds a few months >> before -target 10 mapped to an updated class file version. >> >> We could follow the same path for the JDK 10 -> 11 transition. Paul >> has suggested also updating the class file version at the same time >> this time around. > > I'm a little unclear as to the distinction between allowing for > -source/-target 11 and switching them to be the default. Especially if > you incorporate the classfile version change then we would have a JDK > reporting itself as JDK 10 but which uses -source/-target 11 and > produces version 55 classfiles. I would have thought it a two step > process: > - prepare for new defaults > - switch to new defaults (in conjunction with version change) > > Anyway, none of the proposed changes have any impact on hotspot > AFAICT. It is only when the actual version is updated to 11 that > hotspot, and other entities will have to be updated. I'm still unclear > if someone is actually driving the entire "update to version 11" > process? Is there an umbrella issue for it? > There are various changes associated with a JDK N to (N+1) update including (but not limited to): 1) New -source/-target value in javac 2) Make new -source/-target value the default in javac 3) Change build of the JDK to use new -source/-target 4) Increment version 5) Support new --release value in javac 6) Output new class file format 7) Have HotSpot accept new class file format ... For the last few releases, we've done 1) through 4) in b01 of the new release, although typically via multiple changesets since 4) has been done separately from 1) through 3) and 3) had to be done separately from 1) and 2) since different repos were affected before the repo consolidation. It is desirable but not strictly necessary to bundle this set of updates into as few changesets as possible. In particular, I think it is acceptable if the master repo has source code states before the first promoted build where not all of 1) through 4) are fixed. Cheers, -Joe From jonathan.gibbons at oracle.com Wed Dec 13 20:43:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Dec 2017 12:43:13 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> Message-ID: On 12/13/17 10:36 AM, joe darcy wrote: > Hi David, > > > On 12/12/2017 8:56 PM, David Holmes wrote: >> Hi Joe, >> >> On 13/12/2017 9:20 AM, joe darcy wrote: >>> Hi David, >>> >>> >>> On 12/12/2017 1:32 PM, David Holmes wrote: >>>> > > [snip] > >>>> >>> >>> For background, what we've done in the past is at the very start of >>> a new JDK release, first create -source/-target ${N+1} that begin as >>> aliases for ${N} and are the default -source/-target for javac. [1] >>> As new language features are developed, the javac implementation >>> adds allowFeatureFoo() predicates which turn into >>> >>> ???? return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature >>> >>> So the operational distinction between -source ${N} and -source >>> ${N+1} comes about after language changes have been made for release >>> ${N+1}. For -target, since there is often not a hard dependency >>> between new Java language features and JVM features, an operational >>> distinction between successive values of -target, and thus >>> successive class file versions, can come about later in the release. >>> For example, in JDK 10 the language feature var/local variable type >>> inference enabled by -source 10 was in JDK 10 builds a few months >>> before -target 10 mapped to an updated class file version. >>> >>> We could follow the same path for the JDK 10 -> 11 transition. Paul >>> has suggested also updating the class file version at the same time >>> this time around. >> >> I'm a little unclear as to the distinction between allowing for >> -source/-target 11 and switching them to be the default. Especially >> if you incorporate the classfile version change then we would have a >> JDK reporting itself as JDK 10 but which uses -source/-target 11 and >> produces version 55 classfiles. I would have thought it a two step >> process: >> - prepare for new defaults >> - switch to new defaults (in conjunction with version change) >> >> Anyway, none of the proposed changes have any impact on hotspot >> AFAICT. It is only when the actual version is updated to 11 that >> hotspot, and other entities will have to be updated. I'm still >> unclear if someone is actually driving the entire "update to version >> 11" process? Is there an umbrella issue for it? >> > > There are various changes associated with a JDK N to (N+1) update > including (but not limited to): > > ??? 1) New -source/-target value in javac > ??? 2) Make new -source/-target value the default in javac > ??? 3) Change build of the JDK to use new -source/-target > ??? 4) Increment version > ??? 5) Support new --release value in javac > ??? 6) Output new class file format > ??? 7) Have HotSpot accept new class file format > ??? ... > > For the last few releases, we've done 1) through 4) in b01 of the new > release, although typically via multiple changesets since 4) has been > done separately from 1) through 3) and 3) had to be done separately > from 1) and 2) since different repos were affected before the repo > consolidation. > > It is desirable but not strictly necessary to bundle this set of > updates into as few changesets as possible. In particular, I think it > is acceptable if the master repo has source code states before the > first promoted build where not all of 1) through 4) are fixed. > > Cheers, > > -Joe There's also 3a) Update build of the INTERIM components (used for bootstrapping the build) to use latest GA release Somewhat related, as a one-off,?? JDK 9 javac added a class called JDK9Wrappers to provide reflective access to new-in-JDK-9 API. These wrappers can now be removed, and the API used directly. -- Jon From mark.reinhold at oracle.com Wed Dec 13 21:18:43 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 Dec 2017 13:18:43 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> Message-ID: <20171213131843.760702080@eggemoggin.niobe.net> 2017/12/13 8:44:33 -0800, paul.sandoz at oracle.com: >> On 12 Dec 2017, at 20:56, david.holmes at oracle.com wrote: >> >> Anyway, none of the proposed changes have any impact on hotspot >> AFAICT. It is only when the actual version is updated to 11 that >> hotspot, and other entities will have to be updated. I'm still >> unclear if someone is actually driving the entire "update to version >> 11" process? Is there an umbrella issue for it? > > No yet, i was hoping we could consolidate as much as possible under > one issue thereby minimising coordination/process i.e. combine the > release and class file versions under one patch. Then stand back and > see what is missing e.g. ctsym stuff etc. How much of this can we parameterize and/or automate? We are going to have to do it every six months, after all. Could we define a CLASSFILE_VERSION in make/autoconf/version-numbers and then propagate that value everywhere else? (In any actual release it'll be VERSION_FEATURE + 44, but make it a separate variable to allow for experimentation as with, e.g., MVT.) Looking at Joe's webrev, many of the changes from 10 to 11 could instead be changed to Runtime.getRuntime().version().major() (in Java code) or VERSION_FEATURE (in Makefiles). In javax.lang.model.SourceVersion we could define a new constant, say RELEASE_CURRENT, whose value is that of the latest release. Then annotations such as @SupportedSourceVersion(SourceVersion.RELEASE_11) could be replaced by @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT) Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target and then many references to JDK10 could instead refer to that. In cases where additional code is needed, can we generate it during the build via another Gensrc*.gmk Makefile? That'd be more work now, but it could save us a lot of time in the long run. - Mark From paul.sandoz at oracle.com Wed Dec 13 22:09:44 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 13 Dec 2017 14:09:44 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <20171213131843.760702080@eggemoggin.niobe.net> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> Message-ID: <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> > On 13 Dec 2017, at 13:18, mark.reinhold at oracle.com wrote: > > 2017/12/13 8:44:33 -0800, paul.sandoz at oracle.com: >>> On 12 Dec 2017, at 20:56, david.holmes at oracle.com wrote: >>> >>> Anyway, none of the proposed changes have any impact on hotspot >>> AFAICT. It is only when the actual version is updated to 11 that >>> hotspot, and other entities will have to be updated. I'm still >>> unclear if someone is actually driving the entire "update to version >>> 11" process? Is there an umbrella issue for it? >> >> No yet, i was hoping we could consolidate as much as possible under >> one issue thereby minimising coordination/process i.e. combine the >> release and class file versions under one patch. Then stand back and >> see what is missing e.g. ctsym stuff etc. > > How much of this can we parameterize and/or automate? I suspect quite a bit, as you present below, and i agree we should try and automate as much as possible. At the moment it?s very spaghetti-like and quite fragile. I suggest we get the initial version bump for 11 out of the way as soon as JDK 10 branches off from the mainline then work on automation for subsequent releases. Paul. > We are going to > have to do it every six months, after all. > > Could we define a CLASSFILE_VERSION in make/autoconf/version-numbers and > then propagate that value everywhere else? (In any actual release it'll > be VERSION_FEATURE + 44, but make it a separate variable to allow for > experimentation as with, e.g., MVT.) > > Looking at Joe's webrev, many of the changes from 10 to 11 could instead > be changed to Runtime.getRuntime().version().major() (in Java code) or > VERSION_FEATURE (in Makefiles). > > In javax.lang.model.SourceVersion we could define a new constant, say > RELEASE_CURRENT, whose value is that of the latest release. Then > annotations such as > > @SupportedSourceVersion(SourceVersion.RELEASE_11) > > could be replaced by > > @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT) > > Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target > and then many references to JDK10 could instead refer to that. > > In cases where additional code is needed, can we generate it during > the build via another Gensrc*.gmk Makefile? That'd be more work now, > but it could save us a lot of time in the long run. > > - Mark From brian.goetz at oracle.com Wed Dec 13 22:32:23 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 13 Dec 2017 17:32:23 -0500 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> Message-ID: <1c469e01-0b07-27de-9a18-b9cee976193d@oracle.com> Don't forget to add the new version to the list of validated versions in multi-release JARs... On 12/13/2017 1:36 PM, joe darcy wrote: > > There are various changes associated with a JDK N to (N+1) update > including (but not limited to): > > ??? 1) New -source/-target value in javac > ??? 2) Make new -source/-target value the default in javac > ??? 3) Change build of the JDK to use new -source/-target > ??? 4) Increment version > ??? 5) Support new --release value in javac > ??? 6) Output new class file format > ??? 7) Have HotSpot accept new class file format From mark.reinhold at oracle.com Wed Dec 13 22:36:35 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 Dec 2017 14:36:35 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> Message-ID: <20171213143635.259953232@eggemoggin.niobe.net> 2017/12/13 14:09:44 -0800, paul.sandoz at oracle.com: >> On 13 Dec 2017, at 13:18, mark.reinhold at oracle.com wrote: >> How much of this can we parameterize and/or automate? > > I suspect quite a bit, as you present below, and i agree we should try > and automate as much as possible. At the moment it?s very > spaghetti-like and quite fragile. > > I suggest we get the initial version bump for 11 out of the way as > soon as JDK 10 branches off from the mainline then work on automation > for subsequent releases. I understand that other incoming changes are waiting for the 11 version bump, but can't we at least do the straightforward parameterizations and introduce _CURRENT constants in this round? We can leave anything that requires code generation to post-11. - Mark From paul.sandoz at oracle.com Wed Dec 13 23:49:53 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 13 Dec 2017 15:49:53 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <20171213143635.259953232@eggemoggin.niobe.net> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> <20171213143635.259953232@eggemoggin.niobe.net> Message-ID: <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com> > On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote: > > 2017/12/13 14:09:44 -0800, paul.sandoz at oracle.com: >>> On 13 Dec 2017, at 13:18, mark.reinhold at oracle.com wrote: >>> How much of this can we parameterize and/or automate? >> >> I suspect quite a bit, as you present below, and i agree we should try >> and automate as much as possible. At the moment it?s very >> spaghetti-like and quite fragile. >> >> I suggest we get the initial version bump for 11 out of the way as >> soon as JDK 10 branches off from the mainline then work on automation >> for subsequent releases. > > I understand that other incoming changes are waiting for the 11 version > bump, but can't we at least do the straightforward parameterizations and > introduce _CURRENT constants in this round? We can leave anything that > requires code generation to post-11. > On the lang tools side that does seem easy, but I?ll defer to Joe. With some guidance from the build engineers i would gladly consolidate class file version declaration in C/++ files with a passed in macro, if this can be expediently worked out. I wanna push condy as early as possible in 11 :-) If we could do something in jvm.h that would be ideal. We already have the definitions JVM_CLASSFILE_MAJOR_VERSION and JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so how can the build process inject values into those macros? For class file versions embedded in Java code it would make it easier if we had programmatic access. Perhaps we could have static methods on Runtime.Version to get the major/minor class file versions? Paul. From joe.darcy at oracle.com Thu Dec 14 01:14:00 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 13 Dec 2017 17:14:00 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <20171213131843.760702080@eggemoggin.niobe.net> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> Message-ID: <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com> Hello, On 12/13/2017 1:18 PM, mark.reinhold at oracle.com wrote: > 2017/12/13 8:44:33 -0800, paul.sandoz at oracle.com: >>> On 12 Dec 2017, at 20:56, david.holmes at oracle.com wrote: [snip] >>> >>> Looking at Joe's webrev, many of the changes from 10 to 11 could instead >>> be changed to Runtime.getRuntime().version().major() (in Java code) or >>> VERSION_FEATURE (in Makefiles). >>> >>> In javax.lang.model.SourceVersion we could define a new constant, say >>> RELEASE_CURRENT, whose value is that of the latest release. Then >>> annotations such as >>> >>> @SupportedSourceVersion(SourceVersion.RELEASE_11) >>> >>> could be replaced by >>> >>> @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT) >>> >>> Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target >>> and then many references to JDK10 could instead refer to that. >>> >>> In cases where additional code is needed, can we generate it during >>> the build via another Gensrc*.gmk Makefile? That'd be more work now, >>> but it could save us a lot of time in the long run. >>> Some comments on the design of javax.lang.model API. The SourceVersion enum type has two methods latest() latestSupported() The former returns the value corresponding to the proposed RELEASE_CURRENT. The latter's behavior is a bit more complicated and depends on the version of JDK upon which the javax.lang.model API is running. (It is supported and technically possible to run the javax.lang.model API from JDK (N+1) on top of JDK N; in that case latestSupported() returns RELEASE_{$N} rather than RELEASE_{$N+1}.) By design, the results of SourceVersion. latest() are not a JLS 15.28 "Constant Expressions" [1] and thus cannot be used to populate annotations directly. During JSR 269 we did consider defining a constant or enum constant like RELEASE_CURRENT, but rejected this for a few reasons. First, this value would not be a constant across time since the current release keeps changing. Given the compile-constants-into-class files behavior of javac, in general there would be subtle source compatibility implications to evolving the constant. In particular, a recompile would be necessary to pick up the revised "constant" value. One intended use of the SourceVersion enum constants is for annotation processors to indicate which source versions they support as part of the processor <-> compiler handshake described in javax.annotation.processing.Processor. Supporting a new source version can require nontrivial updates to the logic of a processor since new kinds of constructs can be added to the language. Therefore, it would also be an attractive nuisance to make annotating a processor type with @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT) too easy since the claim could easily not be true. (Processors can get this effect today if they override AbstractProcessor.getSupportedSourceVersion() to return SourceVersion.latest() or write their own Processor implementation from scratch to do so.) For these reasons, I don't think it is prudent to have a public API for RELEASE_CURRENT as a constant. However, it is reasonable in limited contexts such as within the javac testing code to use that patterns and I'll adjust the next iteration of the webrev accordingly. Cheers, -Joe [1] https://docs.oracle.com/javase/specs/jls/se9/html/jls-15.html#jls-15.28 [2] http://download.java.net/java/jdk10/docs/api/javax/annotation/processing/Processor.html From david.holmes at oracle.com Thu Dec 14 01:16:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Dec 2017 11:16:18 +1000 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> Message-ID: <66b253ae-ad36-846b-da02-b2b7831912f3@oracle.com> Hi Joe, On 14/12/2017 4:36 AM, joe darcy wrote: > There are various changes associated with a JDK N to (N+1) update > including (but not limited to): > > ??? 1) New -source/-target value in javac > ??? 2) Make new -source/-target value the default in javac > ??? 3) Change build of the JDK to use new -source/-target > ??? 4) Increment version > ??? 5) Support new --release value in javac > ??? 6) Output new class file format > ??? 7) Have HotSpot accept new class file format > ??? ... > > For the last few releases, we've done 1) through 4) in b01 of the new > release, although typically via multiple changesets since 4) has been > done separately from 1) through 3) and 3) had to be done separately from > 1) and 2) since different repos were affected before the repo > consolidation. > > It is desirable but not strictly necessary to bundle this set of updates > into as few changesets as possible. In particular, I think it is > acceptable if the master repo has source code states before the first > promoted build where not all of 1) through 4) are fixed. So what is currently being proposed would seem to be: > 1) New -source/-target value in javac > 2) Make new -source/-target value the default in javac > 3) Change build of the JDK to use new -source/-target > 6) Output new class file format > 7) Have HotSpot accept new class file format for b01, with: > 4) Increment version > 5) Support new --release value in javac + whatever hotspot needs for new version, after that. David ----- > Cheers, > > -Joe From joe.darcy at oracle.com Thu Dec 14 01:27:35 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 13 Dec 2017 17:27:35 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <66b253ae-ad36-846b-da02-b2b7831912f3@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <66b253ae-ad36-846b-da02-b2b7831912f3@oracle.com> Message-ID: <4e3a5a23-5eea-1d45-9262-ca5affbc1e30@oracle.com> Hi David, On 12/13/2017 5:16 PM, David Holmes wrote: > Hi Joe, > > On 14/12/2017 4:36 AM, joe darcy wrote: >> There are various changes associated with a JDK N to (N+1) update >> including (but not limited to): >> >> 1) New -source/-target value in javac >> 2) Make new -source/-target value the default in javac >> 3) Change build of the JDK to use new -source/-target >> 4) Increment version >> 5) Support new --release value in javac >> 6) Output new class file format >> 7) Have HotSpot accept new class file format >> ... >> >> For the last few releases, we've done 1) through 4) in b01 of the new >> release, although typically via multiple changesets since 4) has been >> done separately from 1) through 3) and 3) had to be done separately >> from 1) and 2) since different repos were affected before the repo >> consolidation. >> >> It is desirable but not strictly necessary to bundle this set of >> updates into as few changesets as possible. In particular, I think it >> is acceptable if the master repo has source code states before the >> first promoted build where not all of 1) through 4) are fixed. > > So what is currently being proposed would seem to be: > > > 1) New -source/-target value in javac > > 2) Make new -source/-target value the default in javac > > 3) Change build of the JDK to use new -source/-target > > 6) Output new class file format > > 7) Have HotSpot accept new class file format > > for b01, with: > > > 4) Increment version > > 5) Support new --release value in javac > + whatever hotspot needs for new version, after that. > The changes out for review, mine plus Paul's combined, do cover the first batch of items you list above. Items 4) and 5) could still occur in b01, even if not bundled with this group of changesets. One could argue that ideally the full grouping of changes covering all these items should occur as the first changeset of a new release. Maybe we'll get there after another round or two of practice :-) -Joe From mark.reinhold at oracle.com Thu Dec 14 03:51:08 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 Dec 2017 19:51:08 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> <20171213143635.259953232@eggemoggin.niobe.net> <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com> Message-ID: <20171213195108.806956474@eggemoggin.niobe.net> 2017/12/13 15:49:53 -0800, paul.sandoz at oracle.com: > On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote: >> I understand that other incoming changes are waiting for the 11 version >> bump, but can't we at least do the straightforward parameterizations and >> introduce _CURRENT constants in this round? We can leave anything that >> requires code generation to post-11. > > On the lang tools side that does seem easy, but I?ll defer to Joe. > > With some guidance from the build engineers i would gladly consolidate > class file version declaration in C/++ files with a passed in macro, > if this can be expediently worked out. I wanna push condy as early as > possible in 11 :-) Understood, but let's do the right thing (or at least closer to that) with this yak while we're here. > If we could do something in jvm.h that would be ideal. We already have > the definitions JVM_CLASSFILE_MAJOR_VERSION and > JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so > how can the build process inject values into those macros? I just went through this for the versioning changes. The attached patch (against d2a837cf9ff1) does what you want, I think. > For class file versions embedded in Java code it would make it easier > if we had programmatic access. Perhaps we could have static methods on > Runtime.Version to get the major/minor class file versions? Sure, or maybe better to make them instance methods of Runtime. Parsing `System.getProperty("java.class.version")` every time is no fun. - Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: conf-cf-version Type: text/x-patch Size: 4563 bytes Desc: not available URL: From david.holmes at oracle.com Thu Dec 14 04:40:31 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Dec 2017 14:40:31 +1000 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <20171213195108.806956474@eggemoggin.niobe.net> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> <20171213143635.259953232@eggemoggin.niobe.net> <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com> <20171213195108.806956474@eggemoggin.niobe.net> Message-ID: On 14/12/2017 1:51 PM, mark.reinhold at oracle.com wrote: > 2017/12/13 15:49:53 -0800, paul.sandoz at oracle.com: >> On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote: >>> I understand that other incoming changes are waiting for the 11 version >>> bump, but can't we at least do the straightforward parameterizations and >>> introduce _CURRENT constants in this round? We can leave anything that >>> requires code generation to post-11. >> >> On the lang tools side that does seem easy, but I?ll defer to Joe. >> >> With some guidance from the build engineers i would gladly consolidate >> class file version declaration in C/++ files with a passed in macro, >> if this can be expediently worked out. I wanna push condy as early as >> possible in 11 :-) > > Understood, but let's do the right thing (or at least closer to that) > with this yak while we're here. > >> If we could do something in jvm.h that would be ideal. We already have >> the definitions JVM_CLASSFILE_MAJOR_VERSION and >> JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so >> how can the build process inject values into those macros? > > I just went through this for the versioning changes. The attached patch > (against d2a837cf9ff1) does what you want, I think. We can't do that. src/java.base/share/native/include/classfile_constants.h is an exported interface - at least at present - so it can't depend on something that has to come from the build. You'd have to generate the exported version with the appropriate value substituted. David ----- >> For class file versions embedded in Java code it would make it easier >> if we had programmatic access. Perhaps we could have static methods on >> Runtime.Version to get the major/minor class file versions? > > Sure, or maybe better to make them instance methods of Runtime. Parsing > `System.getProperty("java.class.version")` every time is no fun. > > - Mark > From erik.joelsson at oracle.com Thu Dec 14 08:12:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Dec 2017 09:12:48 +0100 Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the JDK In-Reply-To: References: Message-ID: Hello, Adding build-dev. Here is a webrev with this file and the necessary build changes to make it end up in the built images. http://cr.openjdk.java.net/~erikj/8193208/webrev.jdk10.01/ /Erik On 2017-12-14 06:56, joe darcy wrote: > Hello, > > FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to > live alongside the existing license-related files at the top level of > the JDK repo, which clarifies the licensing of non-GPL components of > the JDK. > > Cheers, > > -Joe > > --- /dev/null > +++ b/ADDITIONAL_LICENSE_INFO > @@ -0,0 +1,37 @@ > +????????????????????? ADDITIONAL INFORMATION ABOUT LICENSING > + > +Certain files distributed by Oracle America, Inc. and/or its > affiliates are > +subject to the following clarification and special exception to the > GPLv2, > +based on the GNU Project exception for its Classpath libraries, known > as the > +GNU Classpath Exception. > + > +Note that Oracle includes multiple, independent programs in this > software > +package.? Some of those programs are provided under licenses deemed > +incompatible with the GPLv2 by the Free Software Foundation and others. > +For example, the package includes programs licensed under the Apache > +License, Version 2.0 and may include FreeType. Such programs are > licensed > +to you under their original licenses. > + > +Oracle facilitates your further distribution of this package by > adding the > +Classpath Exception to the necessary parts of its GPLv2 code, which > permits > +you to use that code in combination with other independent modules not > +licensed under the GPLv2. However, note that this would not permit > you to > +commingle code under an incompatible license with Oracle's GPLv2 > licensed > +code by, for example, cutting and pasting such code into a file also > +containing Oracle's GPLv2 licensed code and then distributing the > result. > + > +Additionally, if you were to remove the Classpath Exception from any > of the > +files to which it applies and distribute the result, you would likely be > +required to license some or all of the other code in that > distribution under > +the GPLv2 as well, and since the GPLv2 is incompatible with the > license terms > +of some items included in the distribution by Oracle, removing the > Classpath > +Exception could therefore effectively compromise your ability to further > +distribute the package. > + > +Failing to distribute notices associated with some files may also create > +unexpected legal consequences. > + > +Proceed with caution and we recommend that you obtain the advice of a > lawyer > +skilled in open source matters before removing the Classpath > Exception or > +making modifications to this package which may subsequently be > redistributed > +and/or involve the use of third party software. > From Alan.Bateman at oracle.com Thu Dec 14 09:12:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Dec 2017 09:12:59 +0000 Subject: 8193503: javah launcher was not removed by JDK-8191054 Message-ID: Jon removed the code for javah from the jdk.compiler module with JDK-8191054 but the build still creates a launcher that is now DOA with "Error: Could not find or load main class com.sun.tools.javah.Main in module jdk.compiler". This is caught by one of the launcher tests that checks the options of every tool in the bin directory. The changes to drop the build of the javah launcher are trivial and I think we should get this into jdk/jdk before the fork for jdk/jdk10. -Alan diff --git a/make/launcher/Launcher-jdk.compiler.gmk b/make/launcher/Launcher-jdk.compiler.gmk --- a/make/launcher/Launcher-jdk.compiler.gmk +++ b/make/launcher/Launcher-jdk.compiler.gmk @@ -1,5 +1,5 @@ ?# -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights reserved. ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ?# ?# This code is free software; you can redistribute it and/or modify it @@ -31,11 +31,6 @@ ??? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ ?)) -$(eval $(call SetupBuildLauncher, javah, \ -??? MAIN_CLASS := com.sun.tools.javah.Main, \ -??? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ -)) - ?$(eval $(call SetupBuildLauncher, serialver, \ ???? MAIN_CLASS := sun.tools.serialver.SerialVer, \ ???? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ diff --git a/test/jdk/tools/launcher/ToolsOpts.java b/test/jdk/tools/launcher/ToolsOpts.java --- a/test/jdk/tools/launcher/ToolsOpts.java +++ b/test/jdk/tools/launcher/ToolsOpts.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -24,7 +24,7 @@ ?/* ? * @test ? * @bug 8002091 - * @summary Test options patterns for javac,javah,javap and javadoc using + * @summary Test options patterns for javac,javap and javadoc using ? * javac as a test launcher. Create a dummy javac and intercept options to check ? * reception of options as passed through the launcher without having to launch ? * javac. Only -J and -cp ./* options should be consumed by the launcher. From erik.joelsson at oracle.com Thu Dec 14 09:21:22 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Dec 2017 10:21:22 +0100 Subject: 8193503: javah launcher was not removed by JDK-8191054 In-Reply-To: References: Message-ID: Looks good! /Erik On 2017-12-14 10:12, Alan Bateman wrote: > Jon removed the code for javah from the jdk.compiler module with > JDK-8191054 but the build still creates a launcher that is now DOA > with "Error: Could not find or load main class > com.sun.tools.javah.Main in module jdk.compiler". This is caught by > one of the launcher tests that checks the options of every tool in the > bin directory. > > The changes to drop the build of the javah launcher are trivial and I > think we should get this into jdk/jdk before the fork for jdk/jdk10. > > -Alan > > > diff --git a/make/launcher/Launcher-jdk.compiler.gmk > b/make/launcher/Launcher-jdk.compiler.gmk > --- a/make/launcher/Launcher-jdk.compiler.gmk > +++ b/make/launcher/Launcher-jdk.compiler.gmk > @@ -1,5 +1,5 @@ > ?# > -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights > reserved. > ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ?# > ?# This code is free software; you can redistribute it and/or modify it > @@ -31,11 +31,6 @@ > ??? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > ?)) > > -$(eval $(call SetupBuildLauncher, javah, \ > -??? MAIN_CLASS := com.sun.tools.javah.Main, \ > -??? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > -)) > - > ?$(eval $(call SetupBuildLauncher, serialver, \ > ???? MAIN_CLASS := sun.tools.serialver.SerialVer, \ > ???? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > diff --git a/test/jdk/tools/launcher/ToolsOpts.java > b/test/jdk/tools/launcher/ToolsOpts.java > --- a/test/jdk/tools/launcher/ToolsOpts.java > +++ b/test/jdk/tools/launcher/ToolsOpts.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -24,7 +24,7 @@ > ?/* > ? * @test > ? * @bug 8002091 > - * @summary Test options patterns for javac,javah,javap and javadoc > using > + * @summary Test options patterns for javac,javap and javadoc using > ? * javac as a test launcher. Create a dummy javac and intercept > options to check > ? * reception of options as passed through the launcher without having > to launch > ? * javac. Only -J and -cp ./* options should be consumed by the > launcher. From joe.darcy at oracle.com Thu Dec 14 09:30:33 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 14 Dec 2017 01:30:33 -0800 Subject: 8193503: javah launcher was not removed by JDK-8191054 In-Reply-To: References: Message-ID: <691829f1-282f-bf7f-ab74-85dcdda6ca2a@oracle.com> On 12/14/2017 1:12 AM, Alan Bateman wrote: > Jon removed the code for javah from the jdk.compiler module with > JDK-8191054 but the build still creates a launcher that is now DOA > with "Error: Could not find or load main class > com.sun.tools.javah.Main in module jdk.compiler". This is caught by > one of the launcher tests that checks the options of every tool in the > bin directory. > > The changes to drop the build of the javah launcher are trivial and I > think we should get this into jdk/jdk before the fork for jdk/jdk10. I added a similar comment in JDK-8193492: tools/launcher/VersionCheck.java need to be updated after JDK-8191054 https://bugs.openjdk.java.net/browse/JDK-8193492?focusedCommentId=14140245&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14140245 and with the update to Launcher-jdk.compiler.gmk the javah binary does indeed seem to be omitted from the bin dir. +1 -Joe > > -Alan > > > diff --git a/make/launcher/Launcher-jdk.compiler.gmk > b/make/launcher/Launcher-jdk.compiler.gmk > --- a/make/launcher/Launcher-jdk.compiler.gmk > +++ b/make/launcher/Launcher-jdk.compiler.gmk > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -31,11 +31,6 @@ > CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > )) > > -$(eval $(call SetupBuildLauncher, javah, \ > - MAIN_CLASS := com.sun.tools.javah.Main, \ > - CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > -)) > - > $(eval $(call SetupBuildLauncher, serialver, \ > MAIN_CLASS := sun.tools.serialver.SerialVer, \ > CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > diff --git a/test/jdk/tools/launcher/ToolsOpts.java > b/test/jdk/tools/launcher/ToolsOpts.java > --- a/test/jdk/tools/launcher/ToolsOpts.java > +++ b/test/jdk/tools/launcher/ToolsOpts.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,7 +24,7 @@ > /* > * @test > * @bug 8002091 > - * @summary Test options patterns for javac,javah,javap and javadoc > using > + * @summary Test options patterns for javac,javap and javadoc using > * javac as a test launcher. Create a dummy javac and intercept > options to check > * reception of options as passed through the launcher without having > to launch > * javac. Only -J and -cp ./* options should be consumed by the > launcher. From erik.joelsson at oracle.com Thu Dec 14 09:37:27 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Dec 2017 10:37:27 +0100 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> <20171213143635.259953232@eggemoggin.niobe.net> <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com> <20171213195108.806956474@eggemoggin.niobe.net> Message-ID: <1416fd03-cee1-2fb8-f672-6bb3fef07bd6@oracle.com> On 2017-12-14 05:40, David Holmes wrote: > On 14/12/2017 1:51 PM, mark.reinhold at oracle.com wrote: >> I just went through this for the versioning changes.? The attached patch >> (against d2a837cf9ff1) does what you want, I think. > > We can't do that. > src/java.base/share/native/include/classfile_constants.h is an > exported interface - at least at present - so it can't depend on > something that has to come from the build. You'd have to generate the > exported version with the appropriate value substituted. > I'm preparing a patch where we generate classfile_constants.h during the build, based on Mark's patch. /Erik From GROEGES at uk.ibm.com Thu Dec 14 09:53:15 2017 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 14 Dec 2017 09:53:15 +0000 Subject: Proposal: make/Main.gmk Add extra extension/override points to the make file Message-ID: Hi, I would like to propose the changes below to allow the make/Main.gmk file to be more extensible. These changes will allow an extension make file to be able to extend or override certain variable and targets. I would appreciate any feedback. I would also like to find out how I go about opbtaining a sponson contributor for this change. diff -r 8ca86cfb126f make/Main.gmk --- a/make/Main.gmk Wed Dec 06 15:51:06 2017 -0800 +++ b/make/Main.gmk Wed Dec 13 16:27:04 2017 +0000 @@ -56,6 +56,9 @@ # All modules for the current target platform. ALL_MODULES := $(call FindAllModules) +# If not already set, set the JVM lib target so that the JVM will be built. +JVM_LIBS_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-libs + ################################################################################ ################################################################################# @@ -645,7 +648,7 @@ generate-exported-symbols: java.base-libs jdk.jdwp.agent-libs # Building one JVM variant is enough to start building the other libs - $(LIBS_TARGETS): hotspot-$(JVM_VARIANT_MAIN)-libs + $(LIBS_TARGETS): $(JVM_LIBS_TARGETS) $(LAUNCHER_TARGETS): java.base-libs @@ -721,8 +724,12 @@ java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, $(JMOD_TARGETS)) endif - # Building java.base-jmod requires all of hotspot to be built. - java.base-jmod: hotspot + # If not already set, set the JVM lib target so that the JVM will be built. + JAVA_BASE_JMOD_DEPS ?= hotspot + + # Building java.base-jmod requires all of VM (ie hotspot) to be built. + java.base-jmod: $(JAVA_BASE_JMOD_DEPS) + # Declare dependencies from -jmod to all other module targets # When creating a BUILDJDK, the java compilation has already been done by the @@ -748,7 +755,7 @@ # in java.base-copy) and tzdb.dat (done in java.base-gendata) to the # appropriate location otherwise jimage, jlink and jmod won't start. This # also applies when creating the buildjdk. - DEFAULT_JMOD_DEPS := java.base-libs java.base-copy java.base-gendata \ + DEFAULT_JMOD_DEPS += java.base-libs java.base-copy java.base-gendata \ jdk.jlink-launchers # When cross compiling and buildjdk is to be created, depend on creating the # buildjdk instead of the default dependencies. @@ -808,8 +815,7 @@ # populated (java, copy and gendata targets) and the basic libs and launchers # have been built. exploded-image-optimize: java copy gendata java.base-libs java.base-launchers \ - buildtools-modules - + buildtools-modules $(JVM_IMAGE_TARGETS) bootcycle-images: jdk-image docs-jdk-api-javadoc: $(GENSRC_TARGETS) rmic @@ -892,12 +898,17 @@ ################################################################################ # Virtual targets without recipes +JVM_TOOLS_TARGETS ?= buildtools-hotspot buildtools: buildtools-langtools interim-langtools interim-rmic \ - buildtools-jdk buildtools-hotspot + buildtools-jdk $(JVM_TOOLS_TARGETS) -hotspot: $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig - -hotspot-libs: hotspot-jsig +# Setup JVM variables if not already set for a different jvm other than hotspot +JVM_RULE ?= hotspot +JVM_RULE_TARGETS ?= $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig +JVM_LIB ?= hotspot-libs +JVM_LIB_TARGETS ?= hotspot-jsig +$(JVM_RULE): $(JVM_RULE_TARGETS) +$(JVM_LIB): $(JVM_LIB_TARGETS) # Create targets hotspot-libs and hotspot-gensrc. $(foreach v, $(JVM_VARIANTS), \ @@ -936,7 +947,7 @@ $(foreach m, $(ALL_COPY_MODULES), $(eval $m: $m-copy)) # Building java.base includes building all of hotspot. -java.base: hotspot +java.base: $(JVM_BUILD_TARGETS) demos: demos-jdk @@ -1003,13 +1014,19 @@ # This target builds the documentation image docs-image: docs-jdk -# This target builds the test image -test-image: prepare-test-image test-image-hotspot-jtreg-native \ +# If not already set, set the targets to built the test image +TEST_IMAGE_TARGETS ?= prepare-test-image test-image-hotspot-jtreg-native \ test-image-jdk-jtreg-native test-image-failure-handler test-image-hotspot-gtest \ test-image-demos-jdk +# This target builds the test image +test-image: $(TEST_IMAGE_TARGETS) + +# If not already set, set the targets to built all images +ALL_IMAGES_TARGETS ?= product-images test-image docs-image + # all-images builds all our deliverables as images. -all-images: product-images test-image docs-image +all-images: $(ALL_IMAGES_TARGETS) # all-bundles packages all our deliverables as tar.gz bundles. all-bundles: product-bundles test-bundles docs-bundles Thanks Steve Groeger Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk10_main_gmk.diff Type: application/octet-stream Size: 4219 bytes Desc: not available URL: From erik.joelsson at oracle.com Thu Dec 14 10:59:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Dec 2017 11:59:48 +0100 Subject: Proposal: make/Main.gmk Add extra extension/override points to the make file In-Reply-To: References: Message-ID: <15575345-dcb5-bbb8-d1ea-b254e92176a6@oracle.com> Hello Steve, It's certainly an interesting test of the existing extension points when someone else needs to use them. The use case of replacing hotspot completely is definitely new to me. First of all, Main.gmk only contains one call to IncludeCustomExtension close to the beginning of the file. We have a pattern of adding a second at the bottom for some other files so if you feel that would make things simpler, feel free to do so. In this case it would be added right before the .PHONY declaration and look like this: "$(eval $(call IncludeCustomExtension, Main-post.gmk))". In some of the cases you seem to simply want to add one or more extra targets to a list. That kind of extension can often simply be done by adding the rule declaration in your custom extension file. In some cases it needs to be set in a -post file. In other cases it seems to be about replacing hotspot completely with another jvm. That could be made more explicit with conditionals that completely turn off building of hotspot. Not sure which I like best. Depends a bit on your actual requirements on some of the things below. From what I can tell, we should be able to collect the relevant parts in a handful of JVM_* variables that we can put at the top with one comment explaining the need for the overrides. If this is indeed about replacing hotspot, that comment needs to make that clear. See comments below. On 2017-12-14 10:53, Steve Groeger wrote: > Hi, > > I would like to propose the changes below to allow the make/Main.gmk file to be more extensible. > These changes will allow an extension make file to be able to extend or override certain variable and > targets. > > I would appreciate any feedback. I would also like to find out how I go about opbtaining a sponson > contributor for this change. > > diff -r 8ca86cfb126f make/Main.gmk > --- a/make/Main.gmk Wed Dec 06 15:51:06 2017 -0800 > +++ b/make/Main.gmk Wed Dec 13 16:27:04 2017 +0000 > @@ -56,6 +56,9 @@ > # All modules for the current target platform. > ALL_MODULES := $(call FindAllModules) > > +# If not already set, set the JVM lib target so that the JVM will be built. > +JVM_LIBS_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-libs > + I assume this is about replacing hotspot. I would prefer the variable to be named JVM_MAIN_LIBS_TARGET as it's for the main variant only. > ################################################################################ > ################################################################################# > > @@ -645,7 +648,7 @@ > generate-exported-symbols: java.base-libs jdk.jdwp.agent-libs > > # Building one JVM variant is enough to start building the other libs > - $(LIBS_TARGETS): hotspot-$(JVM_VARIANT_MAIN)-libs > + $(LIBS_TARGETS): $(JVM_LIBS_TARGETS) > > $(LAUNCHER_TARGETS): java.base-libs > > @@ -721,8 +724,12 @@ > java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, $(JMOD_TARGETS)) > endif > > - # Building java.base-jmod requires all of hotspot to be built. > - java.base-jmod: hotspot > + # If not already set, set the JVM lib target so that the JVM will be built. > + JAVA_BASE_JMOD_DEPS ?= hotspot > + > + # Building java.base-jmod requires all of VM (ie hotspot) to be built. > + java.base-jmod: $(JAVA_BASE_JMOD_DEPS) > + Assuming this is about replacing hotspot. Perhaps rename the variable "JVM_MAIN_TARGET" or something similar as it could be reused below. If you need to add additional prereqs to java.base-jmod, you can easily do so in your custom extension file. > > # Declare dependencies from -jmod to all other module targets > # When creating a BUILDJDK, the java compilation has already been done by the > > @@ -748,7 +755,7 @@ > # in java.base-copy) and tzdb.dat (done in java.base-gendata) to the > # appropriate location otherwise jimage, jlink and jmod won't start. This > # also applies when creating the buildjdk. > - DEFAULT_JMOD_DEPS := java.base-libs java.base-copy java.base-gendata \ > + DEFAULT_JMOD_DEPS += java.base-libs java.base-copy java.base-gendata \ > jdk.jlink-launchers Unless you actually use the CREAET_BUILDJDK feature (typically for cross compiling), you could simply add your extra prereqs in a Main-post.gmk file like this: $(JMOD_TARGETS) $(INTERIM_JMOD_TARGETS): If you actually do need it, then the above would be necessary and I'm ok with that. > > > # When cross compiling and buildjdk is to be created, depend on creating the > # buildjdk instead of the default dependencies. > > @@ -808,8 +815,7 @@ > # populated (java, copy and gendata targets) and the basic libs and launchers > # have been built. > exploded-image-optimize: java copy gendata java.base-libs java.base-launchers \ > - buildtools-modules > - > + buildtools-modules $(JVM_IMAGE_TARGETS) > bootcycle-images: jdk-image > This looks like you simply need to add extra prereqs to exploded-image-optimize. Since that's a phony target, you can just declare it in your own file: exploded-image-optimize: $(JVM_IMAGE_TARGETS) > > docs-jdk-api-javadoc: $(GENSRC_TARGETS) rmic > > @@ -892,12 +898,17 @@ > ################################################################################ > # Virtual targets without recipes > > > +JVM_TOOLS_TARGETS ?= buildtools-hotspot > buildtools: buildtools-langtools interim-langtools interim-rmic \ > - buildtools-jdk buildtools-hotspot > + buildtools-jdk $(JVM_TOOLS_TARGETS) > > > -hotspot: $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig > - > -hotspot-libs: hotspot-jsig > +# Setup JVM variables if not already set for a different jvm other than hotspot > +JVM_RULE ?= hotspot > +JVM_RULE_TARGETS ?= $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig > +JVM_LIB ?= hotspot-libs > +JVM_LIB_TARGETS ?= hotspot-jsig > +$(JVM_RULE): $(JVM_RULE_TARGETS) > +$(JVM_LIB): $(JVM_LIB_TARGETS) > This one I don't understand the reason for. If replacing hotspot then, does it matter that much that there is still a non functioning target "hotspot" still in the makefile? Same with "hotspot-libs". If you actually want to set values to these variables, why bother with reusing these declarations and not just construct your own in your custom extension file? > > # Create targets hotspot-libs and hotspot-gensrc. > $(foreach v, $(JVM_VARIANTS), \ > > @@ -936,7 +947,7 @@ > $(foreach m, $(ALL_COPY_MODULES), $(eval $m: $m-copy)) > > > # Building java.base includes building all of hotspot. > -java.base: hotspot > +java.base: $(JVM_BUILD_TARGETS) > This variable needs a default value. Replace with JVM_MAIN_TARGET above. > > demos: demos-jdk > > @@ -1003,13 +1014,19 @@ > # This target builds the documentation image > docs-image: docs-jdk > > -# This target builds the test image > -test-image: prepare-test-image test-image-hotspot-jtreg-native \ > +# If not already set, set the targets to built the test image > +TEST_IMAGE_TARGETS ?= prepare-test-image test-image-hotspot-jtreg-native \ > test-image-jdk-jtreg-native test-image-failure-handler test-image-hotspot-gtest \ > test-image-demos-jdk > > +# This target builds the test image > +test-image: $(TEST_IMAGE_TARGETS) > + Is this just about removing the *-hotspot-* targets from this list? In that case, introduce JVM_TEST_IMAGE_TARGETS. > +# If not already set, set the targets to built all images > +ALL_IMAGES_TARGETS ?= product-images test-image docs-image > + > > # all-images builds all our deliverables as images. > -all-images: product-images test-image docs-image > +all-images: $(ALL_IMAGES_TARGETS) This makes me curious as to what you need to remove. We have typically only needed to add targets which can be done from the custom extension file. /Erik > > > # all-bundles packages all our deliverables as tar.gz bundles. > all-bundles: product-bundles test-bundles docs-bundles > > Thanks > Steve Groeger > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From magnus.ihse.bursie at oracle.com Thu Dec 14 11:38:41 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Dec 2017 12:38:41 +0100 Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the JDK In-Reply-To: References: Message-ID: <7CB19AFD-90BA-40B4-9BB0-B5FE7D400D03@oracle.com> Looks good to me. /Magnus > 14 dec. 2017 kl. 09:12 skrev Erik Joelsson : > > Hello, > > Adding build-dev. Here is a webrev with this file and the necessary build changes to make it end up in the built images. > > http://cr.openjdk.java.net/~erikj/8193208/webrev.jdk10.01/ > > /Erik > >> On 2017-12-14 06:56, joe darcy wrote: >> Hello, >> >> FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to live alongside the existing license-related files at the top level of the JDK repo, which clarifies the licensing of non-GPL components of the JDK. >> >> Cheers, >> >> -Joe >> >> --- /dev/null >> +++ b/ADDITIONAL_LICENSE_INFO >> @@ -0,0 +1,37 @@ >> + ADDITIONAL INFORMATION ABOUT LICENSING >> + >> +Certain files distributed by Oracle America, Inc. and/or its affiliates are >> +subject to the following clarification and special exception to the GPLv2, >> +based on the GNU Project exception for its Classpath libraries, known as the >> +GNU Classpath Exception. >> + >> +Note that Oracle includes multiple, independent programs in this software >> +package. Some of those programs are provided under licenses deemed >> +incompatible with the GPLv2 by the Free Software Foundation and others. >> +For example, the package includes programs licensed under the Apache >> +License, Version 2.0 and may include FreeType. Such programs are licensed >> +to you under their original licenses. >> + >> +Oracle facilitates your further distribution of this package by adding the >> +Classpath Exception to the necessary parts of its GPLv2 code, which permits >> +you to use that code in combination with other independent modules not >> +licensed under the GPLv2. However, note that this would not permit you to >> +commingle code under an incompatible license with Oracle's GPLv2 licensed >> +code by, for example, cutting and pasting such code into a file also >> +containing Oracle's GPLv2 licensed code and then distributing the result. >> + >> +Additionally, if you were to remove the Classpath Exception from any of the >> +files to which it applies and distribute the result, you would likely be >> +required to license some or all of the other code in that distribution under >> +the GPLv2 as well, and since the GPLv2 is incompatible with the license terms >> +of some items included in the distribution by Oracle, removing the Classpath >> +Exception could therefore effectively compromise your ability to further >> +distribute the package. >> + >> +Failing to distribute notices associated with some files may also create >> +unexpected legal consequences. >> + >> +Proceed with caution and we recommend that you obtain the advice of a lawyer >> +skilled in open source matters before removing the Classpath Exception or >> +making modifications to this package which may subsequently be redistributed >> +and/or involve the use of third party software. > From erik.joelsson at oracle.com Thu Dec 14 11:58:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Dec 2017 12:58:13 +0100 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <1416fd03-cee1-2fb8-f672-6bb3fef07bd6@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> <20171213143635.259953232@eggemoggin.niobe.net> <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com> <20171213195108.806956474@eggemoggin.niobe.net> <1416fd03-cee1-2fb8-f672-6bb3fef07bd6@oracle.com> Message-ID: <5aa6d969-c5c6-577b-752d-6cc344152407@oracle.com> And here it is: http://cr.openjdk.java.net/~erikj/8173382/webrev.01/ Feel free to incorporate this into whichever changeset you want, or I can push this separately. /Erik On 2017-12-14 10:37, Erik Joelsson wrote: > > On 2017-12-14 05:40, David Holmes wrote: >> On 14/12/2017 1:51 PM, mark.reinhold at oracle.com wrote: >>> I just went through this for the versioning changes.? The attached >>> patch >>> (against d2a837cf9ff1) does what you want, I think. >> >> We can't do that. >> src/java.base/share/native/include/classfile_constants.h is an >> exported interface - at least at present - so it can't depend on >> something that has to come from the build. You'd have to generate the >> exported version with the appropriate value substituted. >> > I'm preparing a patch where we generate classfile_constants.h during > the build, based on Mark's patch. > > /Erik From Alan.Bateman at oracle.com Thu Dec 14 12:51:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Dec 2017 12:51:05 +0000 Subject: 8193503: javah launcher was not removed by JDK-8191054 In-Reply-To: References: Message-ID: On 14/12/2017 09:21, Erik Joelsson wrote: > Looks good! > > /Erik I'll get this in now and also create another issue to remove the other remnants of javah from the build (they won't impact the build output but will need to be cleaned up). -Alan From GROEGES at uk.ibm.com Thu Dec 14 15:30:39 2017 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 14 Dec 2017 15:30:39 +0000 Subject: Proposal: make/Main.gmk Add extra extension/override points to the make file In-Reply-To: <15575345-dcb5-bbb8-d1ea-b254e92176a6@oracle.com> References: <15575345-dcb5-bbb8-d1ea-b254e92176a6@oracle.com>, Message-ID: Erik, Thank you very much for you very constructive comments. We do have our own JVM (OpenJ9) which does replace hotspot and which these proposed changes are attempting to implement with as minimal changes needed within the OpenJDK code as possible. I will attempt to implement some of your suggestions within our current extension make file and pottentially use the post extension file. Once I have done that I will see if there are still changes needed in the make/Main.gmk and will post them to you and the mailing list for further review. I have made a few comments below. Thanks Steve Groeger Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -----Erik Joelsson wrote: ----- To: Steve Groeger , build-dev at openjdk.java.net From: Erik Joelsson Date: 12/14/2017 10:59 Subject: Re: Proposal: make/Main.gmk Add extra extension/override points to the make file Hello Steve, It's certainly an interesting test of the existing extension points when someone else needs to use them. The use case of replacing hotspot completely is definitely new to me. First of all, Main.gmk only contains one call to IncludeCustomExtension close to the beginning of the file. We have a pattern of adding a second at the bottom for some other files so if you feel that would make things simpler, feel free to do so. In this case it would be added right before the .PHONY declaration and look like this: "$(eval $(call IncludeCustomExtension, Main-post.gmk))". In some of the cases you seem to simply want to add one or more extra targets to a list. That kind of extension can often simply be done by adding the rule declaration in your custom extension file. In some cases it needs to be set in a -post file. In other cases it seems to be about replacing hotspot completely with another jvm. That could be made more explicit with conditionals that completely turn off building of hotspot. Not sure which I like best. Depends a bit on your actual requirements on some of the things below. From what I can tell, we should be able to collect the relevant parts in a handful of JVM_* variables that we can put at the top with one comment explaining the need for the overrides. If this is indeed about replacing hotspot, that comment needs to make that clear. See comments below. On 2017-12-14 10:53, Steve Groeger wrote: > Hi, > > I would like to propose the changes below to allow the make/Main.gmk file to be more extensible. > These changes will allow an extension make file to be able to extend or override certain variable and > targets. > > I would appreciate any feedback. I would also like to find out how I go about opbtaining a sponson > contributor for this change. > > diff -r 8ca86cfb126f make/Main.gmk > --- a/make/Main.gmk Wed Dec 06 15:51:06 2017 -0800 > +++ b/make/Main.gmk Wed Dec 13 16:27:04 2017 +0000 > @@ -56,6 +56,9 @@ > # All modules for the current target platform. > ALL_MODULES := $(call FindAllModules) > > +# If not already set, set the JVM lib target so that the JVM will be built. > +JVM_LIBS_TARGETS ?= hotspot-$(JVM_VARIANT_MAIN)-libs > + I assume this is about replacing hotspot. I would prefer the variable to be named JVM_MAIN_LIBS_TARGET as it's for the main variant only. This is OK. Happy to rename the variable. I was expecting requests to change the variable names. > ################################################################################ > ################################################################################# > > @@ -645,7 +648,7 @@ > generate-exported-symbols: java.base-libs jdk.jdwp.agent-libs > > # Building one JVM variant is enough to start building the other libs > - $(LIBS_TARGETS): hotspot-$(JVM_VARIANT_MAIN)-libs > + $(LIBS_TARGETS): $(JVM_LIBS_TARGETS) > > $(LAUNCHER_TARGETS): java.base-libs > > @@ -721,8 +724,12 @@ > java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, $(JMOD_TARGETS)) > endif > > - # Building java.base-jmod requires all of hotspot to be built. > - java.base-jmod: hotspot > + # If not already set, set the JVM lib target so that the JVM will be built. > + JAVA_BASE_JMOD_DEPS ?= hotspot > + > + # Building java.base-jmod requires all of VM (ie hotspot) to be built. > + java.base-jmod: $(JAVA_BASE_JMOD_DEPS) > + Assuming this is about replacing hotspot. Perhaps rename the variable "JVM_MAIN_TARGET" or something similar as it could be reused below. If you need to add additional prereqs to java.base-jmod, you can easily do so in your custom extension file. Yes, we were removing the hotspot target and adding the targets that are required for our own JVMM. I will attempt to just do this in our extension file as suggested. If we need to have the variable then it is OK for the rename to "JVM_MAIN_TARGET" > > # Declare dependencies from -jmod to all other module targets > # When creating a BUILDJDK, the java compilation has already been done by the > > @@ -748,7 +755,7 @@ > # in java.base-copy) and tzdb.dat (done in java.base-gendata) to the > # appropriate location otherwise jimage, jlink and jmod won't start. This > # also applies when creating the buildjdk. > - DEFAULT_JMOD_DEPS := java.base-libs java.base-copy java.base-gendata \ > + DEFAULT_JMOD_DEPS += java.base-libs java.base-copy java.base-gendata \ > jdk.jlink-launchers Unless you actually use the CREAET_BUILDJDK feature (typically for cross compiling), you could simply add your extra prereqs in a Main-post.gmk file like this: $(JMOD_TARGETS) $(INTERIM_JMOD_TARGETS): If you actually do need it, then the above would be necessary and I'm ok with that. We would be using the CREATE_BUILDJDK as we do cross compiling. I can add the extra prereqs in the Main-post.gmk, but this would still need a chnage to Main.gmk to add the use of that the Main-post.gmk in this file. Will try and see if this works. Will try using Main-post.gmk and see if that provides the results we need. > > > # When cross compiling and buildjdk is to be created, depend on creating the > # buildjdk instead of the default dependencies. > > @@ -808,8 +815,7 @@ > # populated (java, copy and gendata targets) and the basic libs and launchers > # have been built. > exploded-image-optimize: java copy gendata java.base-libs java.base-launchers \ > - buildtools-modules > - > + buildtools-modules $(JVM_IMAGE_TARGETS) > bootcycle-images: jdk-image > This looks like you simply need to add extra prereqs to exploded-image-optimize. Since that's a phony target, you can just declare it in your own file: exploded-image-optimize: $(JVM_IMAGE_TARGETS) OK, thanks. Will give that a try and see if that gives the results we need. > > docs-jdk-api-javadoc: $(GENSRC_TARGETS) rmic > > @@ -892,12 +898,17 @@ > ################################################################################ > # Virtual targets without recipes > > > +JVM_TOOLS_TARGETS ?= buildtools-hotspot > buildtools: buildtools-langtools interim-langtools interim-rmic \ > - buildtools-jdk buildtools-hotspot > + buildtools-jdk $(JVM_TOOLS_TARGETS) > > > -hotspot: $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig > - > -hotspot-libs: hotspot-jsig > +# Setup JVM variables if not already set for a different jvm other than hotspot > +JVM_RULE ?= hotspot > +JVM_RULE_TARGETS ?= $(HOTSPOT_VARIANT_TARGETS) hotspot-jsig > +JVM_LIB ?= hotspot-libs > +JVM_LIB_TARGETS ?= hotspot-jsig > +$(JVM_RULE): $(JVM_RULE_TARGETS) > +$(JVM_LIB): $(JVM_LIB_TARGETS) > This one I don't understand the reason for. If replacing hotspot then, does it matter that much that there is still a non functioning target "hotspot" still in the makefile? Same with "hotspot-libs". If you actually want to set values to these variables, why bother with reusing these declarations and not just construct your own in your custom extension file? That is a fair statment. I was tying to reduce the number of targets we had but there is no real issue with having non-functioning targets and defining the ones we require in our own custom extensions file. Will try that and see if it results in what we need. > > # Create targets hotspot-libs and hotspot-gensrc. > $(foreach v, $(JVM_VARIANTS), \ > > @@ -936,7 +947,7 @@ > $(foreach m, $(ALL_COPY_MODULES), $(eval $m: $m-copy)) > > > # Building java.base includes building all of hotspot. > -java.base: hotspot > +java.base: $(JVM_BUILD_TARGETS) > This variable needs a default value. Replace with JVM_MAIN_TARGET above. > > demos: demos-jdk > > @@ -1003,13 +1014,19 @@ > # This target builds the documentation image > docs-image: docs-jdk > > -# This target builds the test image > -test-image: prepare-test-image test-image-hotspot-jtreg-native \ > +# If not already set, set the targets to built the test image > +TEST_IMAGE_TARGETS ?= prepare-test-image test-image-hotspot-jtreg-native \ > test-image-jdk-jtreg-native test-image-failure-handler test-image-hotspot-gtest \ > test-image-demos-jdk > > +# This target builds the test image > +test-image: $(TEST_IMAGE_TARGETS) > + Is this just about removing the *-hotspot-* targets from this list? In that case, introduce JVM_TEST_IMAGE_TARGETS. Yes, it is about removing the *-hotspot-* targets from this list. So you mean have: JVM_TEST_IMAGE_TARGETS ?= test-image-hotspot-jtreg-native test-image-hotspot-gtest test-image: prepare-test-image test-image-jdk-jtreg-native test-image-failure-handler \ test-image-demos-jdk $(JVM_TEST_IMAGE_TARGETS) > +# If not already set, set the targets to built all images > +ALL_IMAGES_TARGETS ?= product-images test-image docs-image > + > > # all-images builds all our deliverables as images. > -all-images: product-images test-image docs-image > +all-images: $(ALL_IMAGES_TARGETS) This makes me curious as to what you need to remove. We have typically only needed to add targets which can be done from the custom extension file. This was strange for me also. All we were removing was the docs-image target. Will try this again with out removing that target and see if that causes us any issues. /Erik > > > # all-bundles packages all our deliverables as tar.gz bundles. > all-bundles: product-bundles test-bundles docs-bundles > > Thanks > Steve Groeger > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From tim.bell at oracle.com Thu Dec 14 15:40:21 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 14 Dec 2017 07:40:21 -0800 Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the JDK In-Reply-To: References: Message-ID: <5A329B65.90708@oracle.com> Erik, Joe: > Hello, > > Adding build-dev. Here is a webrev with this file and the necessary > build changes to make it end up in the built images. > > http://cr.openjdk.java.net/~erikj/8193208/webrev.jdk10.01/ > > /Erik > > On 2017-12-14 06:56, joe darcy wrote: >> Hello, >> >> FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to >> live alongside the existing license-related files at the top level of >> the JDK repo, which clarifies the licensing of non-GPL components of >> the JDK. >> >> Cheers, >> >> -Joe Looks good. Tim From paul.sandoz at oracle.com Thu Dec 14 16:36:58 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 14 Dec 2017 08:36:58 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <5aa6d969-c5c6-577b-752d-6cc344152407@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> <20171213143635.259953232@eggemoggin.niobe.net> <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com> <20171213195108.806956474@eggemoggin.niobe.net> <1416fd03-cee1-2fb8-f672-6bb3fef07bd6@oracle.com> <5aa6d969-c5c6-577b-752d-6cc344152407@oracle.com> Message-ID: <7771FC1F-DA2E-4E63-99DD-8C7348B638C2@oracle.com> > On 14 Dec 2017, at 03:58, Erik Joelsson wrote: > > And here it is: http://cr.openjdk.java.net/~erikj/8173382/webrev.01/ > > Feel free to incorporate this into whichever changeset you want, or I can push this separately. > Thanks! that is exactly what i was looking for. I will merge it into my patch. Paul. From paul.sandoz at oracle.com Thu Dec 14 16:42:38 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 14 Dec 2017 08:42:38 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <20171213195108.806956474@eggemoggin.niobe.net> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com> <20171213143635.259953232@eggemoggin.niobe.net> <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com> <20171213195108.806956474@eggemoggin.niobe.net> Message-ID: <792D57C3-183C-4AB6-9D30-3DB60C8EF67E@oracle.com> > On 13 Dec 2017, at 19:51, mark.reinhold at oracle.com wrote: > > 2017/12/13 15:49:53 -0800, paul.sandoz at oracle.com: >> On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote: >>> I understand that other incoming changes are waiting for the 11 version >>> bump, but can't we at least do the straightforward parameterizations and >>> introduce _CURRENT constants in this round? We can leave anything that >>> requires code generation to post-11. >> >> On the lang tools side that does seem easy, but I?ll defer to Joe. >> >> With some guidance from the build engineers i would gladly consolidate >> class file version declaration in C/++ files with a passed in macro, >> if this can be expediently worked out. I wanna push condy as early as >> possible in 11 :-) > > Understood, but let's do the right thing (or at least closer to that) > with this yak while we're here. > >> If we could do something in jvm.h that would be ideal. We already have >> the definitions JVM_CLASSFILE_MAJOR_VERSION and >> JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so >> how can the build process inject values into those macros? > > I just went through this for the versioning changes. The attached patch > (against d2a837cf9ff1) does what you want, I think. > Thanks, Eric?s patch takes this a few steps further and i will merge that into mine. >> For class file versions embedded in Java code it would make it easier >> if we had programmatic access. Perhaps we could have static methods on >> Runtime.Version to get the major/minor class file versions? > > Sure, or maybe better to make them instance methods of Runtime. Yes, given Runtime.Version's focus on representing a version string for the platform. > Parsing > `System.getProperty("java.class.version")` every time is no fun. > Indeed. I?ll follow up on this yak shave with a separate issue. Paul. From jonathan.gibbons at oracle.com Thu Dec 14 18:41:44 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 14 Dec 2017 10:41:44 -0800 Subject: 8193503: javah launcher was not removed by JDK-8191054 In-Reply-To: References: Message-ID: <5A32C5E8.2050702@oracle.com> Alan, Thanks for catching and handling this. Sorry for the scramble. I'm surprised it wasn't caught by the jdk-tier1 tests I ran before pushing the changeset. -- Jon On 12/14/2017 01:12 AM, Alan Bateman wrote: > Jon removed the code for javah from the jdk.compiler module with > JDK-8191054 but the build still creates a launcher that is now DOA > with "Error: Could not find or load main class > com.sun.tools.javah.Main in module jdk.compiler". This is caught by > one of the launcher tests that checks the options of every tool in the > bin directory. > > The changes to drop the build of the javah launcher are trivial and I > think we should get this into jdk/jdk before the fork for jdk/jdk10. > > -Alan > > > diff --git a/make/launcher/Launcher-jdk.compiler.gmk > b/make/launcher/Launcher-jdk.compiler.gmk > --- a/make/launcher/Launcher-jdk.compiler.gmk > +++ b/make/launcher/Launcher-jdk.compiler.gmk > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -31,11 +31,6 @@ > CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > )) > > -$(eval $(call SetupBuildLauncher, javah, \ > - MAIN_CLASS := com.sun.tools.javah.Main, \ > - CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > -)) > - > $(eval $(call SetupBuildLauncher, serialver, \ > MAIN_CLASS := sun.tools.serialver.SerialVer, \ > CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \ > diff --git a/test/jdk/tools/launcher/ToolsOpts.java > b/test/jdk/tools/launcher/ToolsOpts.java > --- a/test/jdk/tools/launcher/ToolsOpts.java > +++ b/test/jdk/tools/launcher/ToolsOpts.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,7 +24,7 @@ > /* > * @test > * @bug 8002091 > - * @summary Test options patterns for javac,javah,javap and javadoc > using > + * @summary Test options patterns for javac,javap and javadoc using > * javac as a test launcher. Create a dummy javac and intercept > options to check > * reception of options as passed through the launcher without having > to launch > * javac. Only -J and -cp ./* options should be consumed by the > launcher. From erik.joelsson at oracle.com Fri Dec 15 12:40:33 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Dec 2017 13:40:33 +0100 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com> Message-ID: <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com> Looking at JDK-8188015, I was just reminded of JDK-8188012 and JDK-8188013 which indicates that we have more than one place where 10 needs to be bumped to 11 make/BuildNashorn.gmk make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java /Erik On 2017-12-12 16:36, Erik Joelsson wrote: > Build change looks good. > > /Erik > > > On 2017-12-12 08:04, joe darcy wrote: >> Hello, >> >> With the JDK 11 line of development opening up in a few days, a few >> changes are needed to prepared to turn a JDK 10 code base into a JDK >> 11 one including: >> >> ??? JDK-8173382: Add -source 11 and -target 11 to javac >> ??? JDK-8193291: Add SourceVersion.RELEASE_11 >> >> ??? Webev: >> ??????? http://cr.openjdk.java.net/~darcy/8173382.1/ >> ??? CSRs: >> ??????? JDK-8193350: Add -source 11 and -target 11 to javac >> ??????? JDK-8193351: Add SourceVersion.RELEASE_11 >> >> Please review the preliminary webrev and CSRs. >> >> Note that breaking with previous contentions, the current iteration >> of the change does *not* add -source/-target "1.11" as an alias for >> "11". Only "11" is recognized. >> >> I didn't see how to add support for an "11" value for "--release" so >> I problem listed two tests until that is sorted out. >> >> The build is simultaneously updated to user -source/-target 11, hence >> the inclusion of build-dev. >> >> Various langtools tests and test infrastructure is updated too. >> >> Thanks, >> >> -Joe >> > From erik.helin at oracle.com Fri Dec 15 13:23:55 2017 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 15 Dec 2017 14:23:55 +0100 Subject: RFR: 8193620: Update path to autogen.sh in log message Message-ID: Hi all, while working a bit on the configure code I noticed that the error message when autoconf is missing prints the wrong path to autogen.sh. This tiny patch updates the error message: diff -r 589a6f1d86e9 -r 3ba5af45725a make/autoconf/configure --- a/make/autoconf/configure Sat Dec 09 07:50:50 2017 -0800 +++ b/make/autoconf/configure Fri Dec 15 13:55:46 2017 +0100 @@ -60,7 +60,7 @@ run_autogen_or_fail() { if test "x`which autoconf 2> /dev/null | grep -v '^no autoconf in'`" = x; then echo "Cannot locate autoconf, unable to correct situation." - echo "Please install autoconf and run 'bash autogen.sh' to update the generated files." + echo "Please install autoconf and run 'bash $conf_script_dir/autogen.sh' to update the generated files." echo "Error: Cannot continue" 1>&2 exit 1 else Bug: https://bugs.openjdk.java.net/browse/JDK-8193620 Testing: - Tested locally by uninstalling autconf, updating a configure file and verifying that error message is correct Thanks, Erik From erik.joelsson at oracle.com Fri Dec 15 14:39:15 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Dec 2017 15:39:15 +0100 Subject: RFR: 8193620: Update path to autogen.sh in log message In-Reply-To: References: Message-ID: <84e6ddd0-d3c2-a469-dd34-899d105db484@oracle.com> Looks good. /Erik On 2017-12-15 14:23, Erik Helin wrote: > Hi all, > > while working a bit on the configure code I noticed that the error > message when autoconf is missing prints the wrong path to autogen.sh. > This tiny patch updates the error message: > > diff -r 589a6f1d86e9 -r 3ba5af45725a make/autoconf/configure > --- a/make/autoconf/configure?? Sat Dec 09 07:50:50 2017 -0800 > +++ b/make/autoconf/configure?? Fri Dec 15 13:55:46 2017 +0100 > @@ -60,7 +60,7 @@ > ?run_autogen_or_fail() { > ?? if test "x`which autoconf 2> /dev/null | grep -v '^no autoconf > in'`" = x; then > ???? echo "Cannot locate autoconf, unable to correct situation." > -??? echo "Please install autoconf and run 'bash autogen.sh' to update > the generated files." > +??? echo "Please install autoconf and run 'bash > $conf_script_dir/autogen.sh' to update the generated files." > ???? echo "Error: Cannot continue" 1>&2 > ???? exit 1 > ?? else > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8193620 > > Testing: > - Tested locally by uninstalling autconf, updating a configure file > and verifying that error message is correct > > Thanks, > Erik From iris.clark at oracle.com Fri Dec 15 16:43:34 2017 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 15 Dec 2017 08:43:34 -0800 (PST) Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com> <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com> Message-ID: <7f251611-e355-4c72-80e3-faca842f84be@default> Hi. Another build target we need to update is LICENSE_URL in make/Docs.gmk. Here's the equivalent bug for 10: https://bugs.openjdk.java.net/browse/JDK-8189919 I've requested this link: http://www.oracle.com/technetwork/java/javase/terms/license/java11speclicense.html Thanks, iris -----Original Message----- From: Erik Joelsson Sent: Friday, December 15, 2017 4:41 AM To: joe darcy ; compiler-dev at openjdk.java.net; build-dev ; STUART.MARKS Cc: David Holmes Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 Looking at JDK-8188015, I was just reminded of JDK-8188012 and JDK-8188013 which indicates that we have more than one place where 10 needs to be bumped to 11 make/BuildNashorn.gmk make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java /Erik On 2017-12-12 16:36, Erik Joelsson wrote: > Build change looks good. > > /Erik > > > On 2017-12-12 08:04, joe darcy wrote: >> Hello, >> >> With the JDK 11 line of development opening up in a few days, a few >> changes are needed to prepared to turn a JDK 10 code base into a JDK >> 11 one including: >> >> ??? JDK-8173382: Add -source 11 and -target 11 to javac >> ??? JDK-8193291: Add SourceVersion.RELEASE_11 >> >> ??? Webev: >> ??????? http://cr.openjdk.java.net/~darcy/8173382.1/ >> ??? CSRs: >> ??????? JDK-8193350: Add -source 11 and -target 11 to javac >> ??????? JDK-8193351: Add SourceVersion.RELEASE_11 >> >> Please review the preliminary webrev and CSRs. >> >> Note that breaking with previous contentions, the current iteration >> of the change does *not* add -source/-target "1.11" as an alias for >> "11". Only "11" is recognized. >> >> I didn't see how to add support for an "11" value for "--release" so >> I problem listed two tests until that is sorted out. >> >> The build is simultaneously updated to user -source/-target 11, hence >> the inclusion of build-dev. >> >> Various langtools tests and test infrastructure is updated too. >> >> Thanks, >> >> -Joe >> > From paul.sandoz at oracle.com Fri Dec 15 18:40:31 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 15 Dec 2017 10:40:31 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <7f251611-e355-4c72-80e3-faca842f84be@default> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com> <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com> <7f251611-e355-4c72-80e3-faca842f84be@default> Message-ID: <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com> Hi Iris, Erik We should be able to automate all the following by referring to the latest release variable, yes? Nashorn build targets version 9 source https://bugs.openjdk.java.net/browse/JDK-8188012 http://hg.openjdk.java.net/jdk10/master/rev/0e67ab18b511 symbolgenerator targets jdk 9 source https://bugs.openjdk.java.net/browse/JDK-8188013 http://hg.openjdk.java.net/jdk10/master/rev/b4c8426fe105 Update link to license in Docs.gmk https://bugs.openjdk.java.net/browse/JDK-818999 http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12 Paul. > On 15 Dec 2017, at 08:43, Iris Clark wrote: > > Hi. > > Another build target we need to update is LICENSE_URL in make/Docs.gmk. Here's the equivalent bug for 10: > > https://bugs.openjdk.java.net/browse/JDK-8189919 > > I've requested this link: > > http://www.oracle.com/technetwork/java/javase/terms/license/java11speclicense.html > > Thanks, > iris > > -----Original Message----- > From: Erik Joelsson > Sent: Friday, December 15, 2017 4:41 AM > To: joe darcy ; compiler-dev at openjdk.java.net; build-dev ; STUART.MARKS > Cc: David Holmes > Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 > > Looking at JDK-8188015, I was just reminded of JDK-8188012 and > JDK-8188013 which indicates that we have more than one place where 10 needs to be bumped to 11 > > make/BuildNashorn.gmk > make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > > /Erik > > On 2017-12-12 16:36, Erik Joelsson wrote: >> Build change looks good. >> >> /Erik >> >> >> On 2017-12-12 08:04, joe darcy wrote: >>> Hello, >>> >>> With the JDK 11 line of development opening up in a few days, a few >>> changes are needed to prepared to turn a JDK 10 code base into a JDK >>> 11 one including: >>> >>> JDK-8173382: Add -source 11 and -target 11 to javac >>> JDK-8193291: Add SourceVersion.RELEASE_11 >>> >>> Webev: >>> http://cr.openjdk.java.net/~darcy/8173382.1/ >>> CSRs: >>> JDK-8193350: Add -source 11 and -target 11 to javac >>> JDK-8193351: Add SourceVersion.RELEASE_11 >>> >>> Please review the preliminary webrev and CSRs. >>> >>> Note that breaking with previous contentions, the current iteration >>> of the change does *not* add -source/-target "1.11" as an alias for >>> "11". Only "11" is recognized. >>> >>> I didn't see how to add support for an "11" value for "--release" so >>> I problem listed two tests until that is sorted out. >>> >>> The build is simultaneously updated to user -source/-target 11, hence >>> the inclusion of build-dev. >>> >>> Various langtools tests and test infrastructure is updated too. >>> >>> Thanks, >>> >>> -Joe >>> >> > From iris.clark at oracle.com Fri Dec 15 21:10:02 2017 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 15 Dec 2017 13:10:02 -0800 (PST) Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com> <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com> <7f251611-e355-4c72-80e3-faca842f84be@default> <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com> Message-ID: <34893f28-fc68-42cc-8161-5cb58746e2f3@default> Hi, Paul. > We should be able to automate all the following by referring to the latest release variable, yes? [ ... ] > Update link to license in Docs.gmk > https://bugs.openjdk.java.net/browse/JDK-818999 > http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12 Yes! iris -----Original Message----- From: Paul Sandoz Sent: Friday, December 15, 2017 10:41 AM To: Iris Clark Cc: Erik Joelsson ; Joseph D. Darcy ; compiler-dev at openjdk.java.net; build-dev ; Stuart Marks ; David Holmes Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 Hi Iris, Erik We should be able to automate all the following by referring to the latest release variable, yes? Nashorn build targets version 9 source https://bugs.openjdk.java.net/browse/JDK-8188012 http://hg.openjdk.java.net/jdk10/master/rev/0e67ab18b511 symbolgenerator targets jdk 9 source https://bugs.openjdk.java.net/browse/JDK-8188013 http://hg.openjdk.java.net/jdk10/master/rev/b4c8426fe105 Update link to license in Docs.gmk https://bugs.openjdk.java.net/browse/JDK-818999 http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12 Paul. > On 15 Dec 2017, at 08:43, Iris Clark wrote: > > Hi. > > Another build target we need to update is LICENSE_URL in make/Docs.gmk. Here's the equivalent bug for 10: > > https://bugs.openjdk.java.net/browse/JDK-8189919 > > I've requested this link: > > > http://www.oracle.com/technetwork/java/javase/terms/license/java11spec > license.html > > Thanks, > iris > > -----Original Message----- > From: Erik Joelsson > Sent: Friday, December 15, 2017 4:41 AM > To: joe darcy ; compiler-dev at openjdk.java.net; > build-dev ; STUART.MARKS > > Cc: David Holmes > Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and > -target 11 to javac - Java Bug System & JDK-8193291: Add > SourceVersion.RELEASE_11 > > Looking at JDK-8188015, I was just reminded of JDK-8188012 and > JDK-8188013 which indicates that we have more than one place where 10 > needs to be bumped to 11 > > make/BuildNashorn.gmk > make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDepen > dencies.java > > /Erik > > On 2017-12-12 16:36, Erik Joelsson wrote: >> Build change looks good. >> >> /Erik >> >> >> On 2017-12-12 08:04, joe darcy wrote: >>> Hello, >>> >>> With the JDK 11 line of development opening up in a few days, a few >>> changes are needed to prepared to turn a JDK 10 code base into a JDK >>> 11 one including: >>> >>> JDK-8173382: Add -source 11 and -target 11 to javac >>> JDK-8193291: Add SourceVersion.RELEASE_11 >>> >>> Webev: >>> http://cr.openjdk.java.net/~darcy/8173382.1/ >>> CSRs: >>> JDK-8193350: Add -source 11 and -target 11 to javac >>> JDK-8193351: Add SourceVersion.RELEASE_11 >>> >>> Please review the preliminary webrev and CSRs. >>> >>> Note that breaking with previous contentions, the current iteration >>> of the change does *not* add -source/-target "1.11" as an alias for >>> "11". Only "11" is recognized. >>> >>> I didn't see how to add support for an "11" value for "--release" so >>> I problem listed two tests until that is sorted out. >>> >>> The build is simultaneously updated to user -source/-target 11, >>> hence the inclusion of build-dev. >>> >>> Various langtools tests and test infrastructure is updated too. >>> >>> Thanks, >>> >>> -Joe >>> >> > From paul.sandoz at oracle.com Fri Dec 15 22:23:41 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 15 Dec 2017 14:23:41 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> Message-ID: Here are two webrevs (in order that can be merged with the other): the class file version changes; and the build changes related to that. http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ Testing of all three patches (jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2,hs-tier3,hs-tier4,hs-tier5) produced no related test failures. Paul. > On 11 Dec 2017, at 23:04, joe darcy wrote: > > Hello, > > With the JDK 11 line of development opening up in a few days, a few changes are needed to prepared to turn a JDK 10 code base into a JDK 11 one including: > > JDK-8173382: Add -source 11 and -target 11 to javac > JDK-8193291: Add SourceVersion.RELEASE_11 > > Webev: > http://cr.openjdk.java.net/~darcy/8173382.1/ > CSRs: > JDK-8193350: Add -source 11 and -target 11 to javac > JDK-8193351: Add SourceVersion.RELEASE_11 > > Please review the preliminary webrev and CSRs. > > Note that breaking with previous contentions, the current iteration of the change does *not* add -source/-target "1.11" as an alias for "11". Only "11" is recognized. > > I didn't see how to add support for an "11" value for "--release" so I problem listed two tests until that is sorted out. > > The build is simultaneously updated to user -source/-target 11, hence the inclusion of build-dev. > > Various langtools tests and test infrastructure is updated too. > > Thanks, > > -Joe > From erik.joelsson at oracle.com Sat Dec 16 07:19:30 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Sat, 16 Dec 2017 08:19:30 +0100 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com> <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com> <7f251611-e355-4c72-80e3-faca842f84be@default> <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com> Message-ID: That sounds good to me. /Erik On 2017-12-15 19:40, Paul Sandoz wrote: > Hi Iris, Erik > > We should be able to automate all the following by referring to the latest release variable, yes? > > Nashorn build targets version 9 source > https://bugs.openjdk.java.net/browse/JDK-8188012 > http://hg.openjdk.java.net/jdk10/master/rev/0e67ab18b511 > > symbolgenerator targets jdk 9 source > https://bugs.openjdk.java.net/browse/JDK-8188013 > http://hg.openjdk.java.net/jdk10/master/rev/b4c8426fe105 > > Update link to license in Docs.gmk > https://bugs.openjdk.java.net/browse/JDK-818999 > http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12 > > Paul. > > >> On 15 Dec 2017, at 08:43, Iris Clark wrote: >> >> Hi. >> >> Another build target we need to update is LICENSE_URL in make/Docs.gmk. Here's the equivalent bug for 10: >> >> https://bugs.openjdk.java.net/browse/JDK-8189919 >> >> I've requested this link: >> >> http://www.oracle.com/technetwork/java/javase/terms/license/java11speclicense.html >> >> Thanks, >> iris >> >> -----Original Message----- >> From: Erik Joelsson >> Sent: Friday, December 15, 2017 4:41 AM >> To: joe darcy ; compiler-dev at openjdk.java.net; build-dev ; STUART.MARKS >> Cc: David Holmes >> Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 >> >> Looking at JDK-8188015, I was just reminded of JDK-8188012 and >> JDK-8188013 which indicates that we have more than one place where 10 needs to be bumped to 11 >> >> make/BuildNashorn.gmk >> make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java >> >> /Erik >> >> On 2017-12-12 16:36, Erik Joelsson wrote: >>> Build change looks good. >>> >>> /Erik >>> >>> >>> On 2017-12-12 08:04, joe darcy wrote: >>>> Hello, >>>> >>>> With the JDK 11 line of development opening up in a few days, a few >>>> changes are needed to prepared to turn a JDK 10 code base into a JDK >>>> 11 one including: >>>> >>>> JDK-8173382: Add -source 11 and -target 11 to javac >>>> JDK-8193291: Add SourceVersion.RELEASE_11 >>>> >>>> Webev: >>>> http://cr.openjdk.java.net/~darcy/8173382.1/ >>>> CSRs: >>>> JDK-8193350: Add -source 11 and -target 11 to javac >>>> JDK-8193351: Add SourceVersion.RELEASE_11 >>>> >>>> Please review the preliminary webrev and CSRs. >>>> >>>> Note that breaking with previous contentions, the current iteration >>>> of the change does *not* add -source/-target "1.11" as an alias for >>>> "11". Only "11" is recognized. >>>> >>>> I didn't see how to add support for an "11" value for "--release" so >>>> I problem listed two tests until that is sorted out. >>>> >>>> The build is simultaneously updated to user -source/-target 11, hence >>>> the inclusion of build-dev. >>>> >>>> Various langtools tests and test infrastructure is updated too. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> From magnus.ihse.bursie at oracle.com Sun Dec 17 21:11:41 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 17 Dec 2017 22:11:41 +0100 Subject: RFR: 8193620: Update path to autogen.sh in log message In-Reply-To: References: Message-ID: <5d41688c-9c0e-60be-c56d-9b851c81023c@oracle.com> Looks good to me. /Magnus On 2017-12-15 14:23, Erik Helin wrote: > Hi all, > > while working a bit on the configure code I noticed that the error > message when autoconf is missing prints the wrong path to autogen.sh. > This tiny patch updates the error message: > > diff -r 589a6f1d86e9 -r 3ba5af45725a make/autoconf/configure > --- a/make/autoconf/configure?? Sat Dec 09 07:50:50 2017 -0800 > +++ b/make/autoconf/configure?? Fri Dec 15 13:55:46 2017 +0100 > @@ -60,7 +60,7 @@ > ?run_autogen_or_fail() { > ?? if test "x`which autoconf 2> /dev/null | grep -v '^no autoconf > in'`" = x; then > ???? echo "Cannot locate autoconf, unable to correct situation." > -??? echo "Please install autoconf and run 'bash autogen.sh' to update > the generated files." > +??? echo "Please install autoconf and run 'bash > $conf_script_dir/autogen.sh' to update the generated files." > ???? echo "Error: Cannot continue" 1>&2 > ???? exit 1 > ?? else > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8193620 > > Testing: > - Tested locally by uninstalling autconf, updating a configure file > and verifying that error message is correct > > Thanks, > Erik From erik.helin at oracle.com Mon Dec 18 09:09:10 2017 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 18 Dec 2017 10:09:10 +0100 Subject: RFR: 8193686: Allow --with-jtreg to accept a zip compressed jtreg image Message-ID: <1cbaf086-fd2f-a397-9d3e-7209052d5993@oracle.com> Hi all, here is small patch that allows the configure option --with-jtreg to accept a zip compressed jtreg image (the option currently accepts a jtreg image directory). The jtreg image will be unpacked into $CONFIGURE_SUPPORT/jtreg. Patch: http://cr.openjdk.java.net/~ehelin/8193686/00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8193686 Testing: - Tested locally on Linux x86-64 that configuring, building and running a jtreg test (via run-test) works with both - a jtreg image directory - a zip compressed jtreg image as values to the --with-jtreg configure option Thanks, Erik From erik.joelsson at oracle.com Mon Dec 18 17:23:23 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 18 Dec 2017 18:23:23 +0100 Subject: RFR: 8192837 Need new test for release file info In-Reply-To: <5A37F318.5020207@Oracle.com> References: <5A37F318.5020207@Oracle.com> Message-ID: Redirecting to correct list. The test seems to do what it set out to do. /Erik On 2017-12-18 17:55, Randy Crihfield wrote: > I have created an OpenJDK negative test that confirms the closed > source files are not included in the SOURCE. > > Version of the actual test for review: > > http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ > > Any comments/suggestions are welcome, also I will need a sponsor for > it at the end? > > Randy > From mark.reinhold at oracle.com Mon Dec 18 22:41:33 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 18 Dec 2017 14:41:33 -0800 Subject: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build Message-ID: <20171218144133.20080145@eggemoggin.niobe.net> Bug: https://bugs.openjdk.java.net/browse/JDK-8193764 Webrev: http://cr.openjdk.java.net/~mr/rev/8193764/ You can set COMPANY_NAME in make/autoconf/version-numbers, but you can't set it when configuring a build, so it's impossible to change the value of IMPLEMENTOR in the $JAVA_HOME/release file without patching the source code. This patch simply adds the obvious --with-vendor-name option to the configure script. (Motivation: I'm trying to arrange for IMPLEMENTOR to be "Oracle Corporation" in builds produced by Oracle, but this option may prove useful to other implementors.) - Mark From martinrb at google.com Mon Dec 18 23:36:03 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Dec 2017 15:36:03 -0800 Subject: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build In-Reply-To: <20171218144133.20080145@eggemoggin.niobe.net> References: <20171218144133.20080145@eggemoggin.niobe.net> Message-ID: Mark, thanks for implementing my little feature request. Looks good to me. Aside: we only support running configure under bash, but as a result the configure script is now a strange mixture of bashisms and 1980-isms. On Mon, Dec 18, 2017 at 2:41 PM, wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193764 > Webrev: http://cr.openjdk.java.net/~mr/rev/8193764/ > > You can set COMPANY_NAME in make/autoconf/version-numbers, but you can't > set it when configuring a build, so it's impossible to change the value > of IMPLEMENTOR in the $JAVA_HOME/release file without patching the > source code. > > This patch simply adds the obvious --with-vendor-name option to the > configure script. > > (Motivation: I'm trying to arrange for IMPLEMENTOR to be "Oracle > Corporation" in builds produced by Oracle, but this option may prove > useful to other implementors.) > > - Mark > From tim.bell at oracle.com Tue Dec 19 00:15:08 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 18 Dec 2017 16:15:08 -0800 Subject: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build In-Reply-To: <20171218144133.20080145@eggemoggin.niobe.net> References: <20171218144133.20080145@eggemoggin.niobe.net> Message-ID: <5A385A0C.5080003@oracle.com> Mark: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193764 > Webrev: http://cr.openjdk.java.net/~mr/rev/8193764/ Looks good. Tim From joe.darcy at oracle.com Tue Dec 19 01:33:26 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 18 Dec 2017 17:33:26 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com> Message-ID: <5A386C66.6090505@oracle.com> Hello, A follow-up on defining a final field RELEASE_CURRENT as an alias for the latest SourceVersion constant to allow easier updating of annotations using SourceVersion constants. Somewht surprisingly, this is not legal Java code; an annotation must use an enum constant directly and not a constant expression which evaluates to an enum constant. This rules is given in JLS 9.7.1 Normal Annotations: > T [ the element type] is not an array type, and the type of V [the > element value] is assignment compatible (?5.2) with T, and: > > If T is a primitive type or String, then V is a constant > expression (?15.28). > If T is Class or an invocation of Class (?4.5), then V is a class > literal (?15.8.2). > If T is an enum type (?8.9), then V is an enum constant (?8.9.1). > V is not null. https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1 The wording goes back to JLS 3rd edition which introduced enums and annotations. Formally, the constant expression concept in JLS 15.28 only applies to primitive types and Strings. Presumably, it would not be too difficult to expand this concept to include class literals and enum constants. In any case, in the mean time the suggested idiom will not work and the changes of RELEASE_9 => RELEASE_10 will need to stay. Updated webrev with a minor merge: http://cr.openjdk.java.net/~darcy/8173382.3/ Cheers, -Joe From paul.sandoz at oracle.com Tue Dec 19 01:42:49 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 18 Dec 2017 17:42:49 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <5A386C66.6090505@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com> <5A386C66.6090505@oracle.com> Message-ID: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com> Looks good to me. I am including HS dev for the class file version changes: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ We can push the above patches under the following issue rather that merge into Joe's patch: https://bugs.openjdk.java.net/browse/JDK-8191913 Hopefully by the next release we can merge together and with less changes required. Paul. > On 18 Dec 2017, at 17:33, Joseph D. Darcy wrote: > > Hello, > > A follow-up on defining a final field RELEASE_CURRENT as an alias for the latest SourceVersion constant to allow easier updating of annotations using SourceVersion constants. Somewht surprisingly, this is not legal Java code; an annotation must use an enum constant directly and not a constant expression which evaluates to an enum constant. > > This rules is given in JLS 9.7.1 Normal Annotations: > >> T [ the element type] is not an array type, and the type of V [the element value] is assignment compatible (?5.2) with T, and: >> >> If T is a primitive type or String, then V is a constant expression (?15.28). >> If T is Class or an invocation of Class (?4.5), then V is a class literal (?15.8.2). >> If T is an enum type (?8.9), then V is an enum constant (?8.9.1). >> V is not null. > https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1 > > The wording goes back to JLS 3rd edition which introduced enums and annotations. > > Formally, the constant expression concept in JLS 15.28 only applies to primitive types and Strings. Presumably, it would not be too difficult to expand this concept to include class literals and enum constants. > > In any case, in the mean time the suggested idiom will not work and the changes of RELEASE_9 => RELEASE_10 will need to stay. > > Updated webrev with a minor merge: > > http://cr.openjdk.java.net/~darcy/8173382.3/ > > Cheers, > > -Joe > From joe.darcy at oracle.com Tue Dec 19 01:49:42 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 18 Dec 2017 17:49:42 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com> <5A386C66.6090505@oracle.com> <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com> Message-ID: <5A387036.2080008@oracle.com> Thanks Paul. I'm doing final checks and preparations of fixes to JDK-8173382: Add -source 11 and -target 11 to javac JDK-8193291: Add SourceVersion.RELEASE_11 and expect to push shortly. Cheers, -Joe On 12/18/2017 5:42 PM, Paul Sandoz wrote: > Looks good to me. > > I am including HS dev for the class file version changes: > > http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ > > http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ > > > We can push the above patches under the following issue rather that > merge into Joe's patch: > > https://bugs.openjdk.java.net/browse/JDK-8191913 > > Hopefully by the next release we can merge together and with less > changes required. > > Paul. > >> On 18 Dec 2017, at 17:33, Joseph D. Darcy > > wrote: >> >> Hello, >> >> A follow-up on defining a final field RELEASE_CURRENT as an alias >> for the latest SourceVersion constant to allow easier updating of >> annotations using SourceVersion constants. Somewht surprisingly, this >> is not legal Java code; an annotation must use an enum constant >> directly and not a constant expression which evaluates to an enum >> constant. >> >> This rules is given in JLS 9.7.1 Normal Annotations: >> >>> T [ the element type] is not an array type, and the type of V [the >>> element value] is assignment compatible (?5.2) with T, and: >>> >>> If T is a primitive type or String, then V is a constant >>> expression (?15.28). >>> If T is Class or an invocation of Class (?4.5), then V is a class >>> literal (?15.8.2). >>> If T is an enum type (?8.9), then V is an enum constant (?8.9.1). >>> V is not null. >> https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1 >> >> The wording goes back to JLS 3rd edition which introduced enums and >> annotations. >> >> Formally, the constant expression concept in JLS 15.28 only applies >> to primitive types and Strings. Presumably, it would not be too >> difficult to expand this concept to include class literals and enum >> constants. >> >> In any case, in the mean time the suggested idiom will not work and >> the changes of RELEASE_9 => RELEASE_10 will need to stay. >> >> Updated webrev with a minor merge: >> >> http://cr.openjdk.java.net/~darcy/8173382.3/ >> >> Cheers, >> >> -Joe >> > From david.holmes at oracle.com Tue Dec 19 01:52:01 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Dec 2017 11:52:01 +1000 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com> <5A386C66.6090505@oracle.com> <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com> Message-ID: <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com> On 19/12/2017 11:42 AM, Paul Sandoz wrote: > Looks good to me. > > I am including HS dev for the class file version changes: > > http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ > > We can push the above patches under the following issue rather that > merge into Joe's patch: > > https://bugs.openjdk.java.net/browse/JDK-8191913 > > Hopefully by the next release we can merge together and with less > changes required. Changes seem okay, but I'm still a little concerned about using classfile version 55 before we actually bump the JDK version to 11. And it still isn't clear to me who will be doing the actual version update and when? Thanks, David > Paul. > >> On 18 Dec 2017, at 17:33, Joseph D. Darcy > > wrote: >> >> Hello, >> >> A follow-up on defining a final field RELEASE_CURRENT ?as an alias for >> the latest SourceVersion constant to allow easier updating of >> annotations using SourceVersion constants. Somewht surprisingly, this >> is not legal Java code; an annotation must use an enum constant >> directly and not a constant expression which evaluates to an enum >> constant. >> >> This rules is given in JLS 9.7.1 Normal Annotations: >> >>> T [ the element type] is not an array type, and the type of V [the >>> element value] is assignment compatible (?5.2) with T, and: >>> >>> ???If T is a primitive type or String, then V is a constant >>> expression (?15.28). >>> ???If T is Class or an invocation of Class (?4.5), then V is a class >>> literal (?15.8.2). >>> ???If T is an enum type (?8.9), then V is an enum constant (?8.9.1). >>> ???V is not null. >> https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1 >> >> The wording goes back to JLS 3rd edition which introduced enums and >> annotations. >> >> Formally, the constant expression concept in JLS 15.28 only applies to >> primitive types and Strings. Presumably, it would not be too difficult >> to expand this concept to include class literals and enum constants. >> >> In any case, in the mean time the suggested idiom will not work and >> the changes of RELEASE_9 => RELEASE_10 will need to stay. >> >> Updated webrev with a minor merge: >> >> ???http://cr.openjdk.java.net/~darcy/8173382.3/ >> >> Cheers, >> >> -Joe >> > From david.holmes at oracle.com Tue Dec 19 02:32:32 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Dec 2017 12:32:32 +1000 Subject: RFR: 8192837 Need new test for release file info In-Reply-To: References: <5A37F318.5020207@Oracle.com> Message-ID: Hi Randy, jdk/sanity/Test8192837.java We don't name tests with bug numbers any more - the file/class should be renamed to something appropriate to its actual function. 64 // grab the line 65 if (readIn.startsWith("SOURCE=")) 66 fishForSOURCE = readIn; Do you expect to find more than one SOURCE line? If not this should "break". If so, then you're only going to check the last one found. 98 if (runtime.contains("OpenJDK")) 99 new Test8192837(jdkPath + "/release"); 100 else 101 System.out.println("Not an OpenJDK."); It would be preferable if this can be done via some @requires tag rather than within the test. But otherwise it would be better to print "Test skipped: not an OpenJDK build". Thanks, David On 19/12/2017 3:23 AM, Erik Joelsson wrote: > Redirecting to correct list. > > The test seems to do what it set out to do. > > /Erik > > > On 2017-12-18 17:55, Randy Crihfield wrote: >> I have created an OpenJDK negative test that confirms the closed >> source files are not included in the SOURCE. >> >> Version of the actual test for review: >> >> http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ >> >> Any comments/suggestions are welcome, also I will need a sponsor for >> it at the end? >> >> Randy >> > From paul.sandoz at oracle.com Tue Dec 19 02:34:01 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 18 Dec 2017 18:34:01 -0800 Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11 In-Reply-To: <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com> References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com> <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com> <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com> <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com> <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com> <33cac77e-a465-92c0-464e-9e086699786b@oracle.com> <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com> <20171213131843.760702080@eggemoggin.niobe.net> <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com> <5A386C66.6090505@oracle.com> <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com> <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com> Message-ID: > On 18 Dec 2017, at 17:52, David Holmes wrote: > > On 19/12/2017 11:42 AM, Paul Sandoz wrote: >> Looks good to me. >> I am including HS dev for the class file version changes: >> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ >> We can push the above patches under the following issue rather that merge into Joe's patch: >> https://bugs.openjdk.java.net/browse/JDK-8191913 >> Hopefully by the next release we can merge together and with less changes required. > > Changes seem okay, but I'm still a little concerned about using classfile version 55 before we actually bump the JDK version to 11. > Thanks, jdk and hs 1 to 4 tier testing showed no issues. > And it still isn't clear to me who will be doing the actual version update and when? > Unsure, we are still working out the steps, hopefully it would follow on fairly quickly. Plus there are quite a few follow on actions we can do to make this simpler for next time (especially for hardcoded values in build scripts and tests). Paul. From mark.reinhold at oracle.com Mon Dec 18 23:50:46 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 18 Dec 2017 15:50:46 -0800 Subject: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build In-Reply-To: References: <20171218144133.20080145@eggemoggin.niobe.net> Message-ID: <20171218155046.84949801@eggemoggin.niobe.net> 2017/12/18 15:36:03 -0800, Martin Buchholz : > Mark, thanks for implementing my little feature request. Looks good to me. I didn't know you'd requested this -- is there an existing issue? - Mark From martinrb at google.com Tue Dec 19 04:40:19 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Dec 2017 20:40:19 -0800 Subject: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build In-Reply-To: <20171218155046.84949801@eggemoggin.niobe.net> References: <20171218144133.20080145@eggemoggin.niobe.net> <20171218155046.84949801@eggemoggin.niobe.net> Message-ID: On Mon, Dec 18, 2017 at 3:50 PM, wrote: > 2017/12/18 15:36:03 -0800, Martin Buchholz : > > Mark, thanks for implementing my little feature request. Looks good to > me. > > I didn't know you'd requested this -- is there an existing issue? > https://bugs.openjdk.java.net/browse/JDK-8189761 From erik.joelsson at oracle.com Tue Dec 19 07:49:50 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Dec 2017 08:49:50 +0100 Subject: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build In-Reply-To: <20171218144133.20080145@eggemoggin.niobe.net> References: <20171218144133.20080145@eggemoggin.niobe.net> Message-ID: Looks good. /Erik On 2017-12-18 23:41, mark.reinhold at oracle.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193764 > Webrev: http://cr.openjdk.java.net/~mr/rev/8193764/ > > You can set COMPANY_NAME in make/autoconf/version-numbers, but you can't > set it when configuring a build, so it's impossible to change the value > of IMPLEMENTOR in the $JAVA_HOME/release file without patching the > source code. > > This patch simply adds the obvious --with-vendor-name option to the > configure script. > > (Motivation: I'm trying to arrange for IMPLEMENTOR to be "Oracle > Corporation" in builds produced by Oracle, but this option may prove > useful to other implementors.) > > - Mark From Randy.Crihfield at Oracle.com Tue Dec 19 16:41:32 2017 From: Randy.Crihfield at Oracle.com (Randy Crihfield) Date: Tue, 19 Dec 2017 11:41:32 -0500 Subject: RFR: 8192837 Need new test for release file info In-Reply-To: <5A393CF1.7080906@Oracle.com> References: <5A37F318.5020207@Oracle.com> <5A393CF1.7080906@Oracle.com> Message-ID: <5A39413C.1050004@Oracle.com> > > This ought to be what you were asking for. > > http://cr.openjdk.java.net/~shurailine/8192837/webrev.03/ > > > Thanks for the help > > Randy > > On 12/18/17 09:32 PM, David Holmes wrote: >> Hi Randy, >> >> jdk/sanity/Test8192837.java >> >> We don't name tests with bug numbers any more - the file/class should >> be renamed to something appropriate to its actual function. >> >> 64 // grab the line >> 65 if (readIn.startsWith("SOURCE=")) >> 66 fishForSOURCE = readIn; >> >> Do you expect to find more than one SOURCE line? If not this should >> "break". If so, then you're only going to check the last one found. >> >> 98 if (runtime.contains("OpenJDK")) >> 99 new Test8192837(jdkPath + "/release"); >> 100 else >> 101 System.out.println("Not an OpenJDK."); >> >> It would be preferable if this can be done via some @requires tag >> rather than within the test. But otherwise it would be better to >> print "Test skipped: not an OpenJDK build". >> >> Thanks, >> David >> >> On 19/12/2017 3:23 AM, Erik Joelsson wrote: >>> Redirecting to correct list. >>> >>> The test seems to do what it set out to do. >>> >>> /Erik >>> >>> >>> On 2017-12-18 17:55, Randy Crihfield wrote: >>>> I have created an OpenJDK negative test that confirms the closed >>>> source files are not included in the SOURCE. >>>> >>>> Version of the actual test for review: >>>> >>>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ >>>> >>>> Any comments/suggestions are welcome, also I will need a sponsor >>>> for it at the end? >>>> >>>> Randy >>>> >>> > From mark.reinhold at oracle.com Tue Dec 19 17:21:26 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 19 Dec 2017 09:21:26 -0800 Subject: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build In-Reply-To: References: <20171218144133.20080145@eggemoggin.niobe.net> <20171218155046.84949801@eggemoggin.niobe.net> Message-ID: <20171219092126.540035252@eggemoggin.niobe.net> 2017/12/18 20:40:19 -0800, Martin Buchholz : > On Mon, Dec 18, 2017 at 3:50 PM, mark.reinhold at oracle.com wrote: >> I didn't know you'd requested this -- is there an existing issue? > > https://bugs.openjdk.java.net/browse/JDK-8189761 Thanks. I cross-linked that with 8193764, which addresses part of your request, and added a comment to summarize what remains to be done. - Mark From jonathan.gibbons at oracle.com Tue Dec 19 21:52:16 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 19 Dec 2017 13:52:16 -0800 Subject: RFR: JDK-8193512: remove remnants of javah from jdk/jdk10 repo Message-ID: <5A398A10.3020203@oracle.com> Please review these changes to remove the remnants of javah (and in a couple of tests, some remnants of apt and an earlier version of javap) from the repo, now that the tool itself has been removed. JBS: https://bugs.openjdk.java.net/browse/JDK-8193512 Webrev: http://cr.openjdk.java.net/~jjg/8193512/webrev.00/ -- Jon From joe.darcy at oracle.com Tue Dec 19 22:10:10 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 19 Dec 2017 14:10:10 -0800 Subject: RFR: JDK-8193512: remove remnants of javah from jdk/jdk10 repo In-Reply-To: <5A398A10.3020203@oracle.com> References: <5A398A10.3020203@oracle.com> Message-ID: <5A398E42.3060006@oracle.com> Looks fine. -Joe On 12/19/2017 1:52 PM, Jonathan Gibbons wrote: > Please review these changes to remove the remnants of javah (and in a > couple of tests, some remnants of apt and an earlier version of javap) > from the repo, now that the tool itself has been removed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8193512 > Webrev: http://cr.openjdk.java.net/~jjg/8193512/webrev.00/ > > -- Jon From ted at tedneward.com Tue Dec 19 22:13:19 2017 From: ted at tedneward.com (Ted Neward) Date: Tue, 19 Dec 2017 14:13:19 -0800 Subject: Building hsdis? Message-ID: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> Hey, all. Been trying for a day and a half now to build the hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first off of the JDK8u source, then tried again with the JDK source, no love either way.) Is there a definitive page (wiki, blog, etc) that describes how to build hsdis on different platforms? I?m trying right now in an Ubuntu 16 VM, but would also want to build on Windows and/or macOS. All the Web is showing me is posts from a few years ago that don?t seem to address some of the issues I?m running into. I can copy build output if it?ll help, but wanted to go do my homework before doing that. :-) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 From tim.bell at oracle.com Wed Dec 20 01:09:09 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 19 Dec 2017 17:09:09 -0800 Subject: RFR: JDK-8193512: remove remnants of javah from jdk/jdk10 repo In-Reply-To: <5A398A10.3020203@oracle.com> References: <5A398A10.3020203@oracle.com> Message-ID: <5A39B835.5030008@oracle.com> Jon: > Please review these changes to remove the remnants of javah (and in a > couple of tests, some remnants of apt and an earlier version of javap) > from the repo, now that the tool itself has been removed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8193512 > Webrev: http://cr.openjdk.java.net/~jjg/8193512/webrev.00/ Looks good. Tim From erik.joelsson at oracle.com Wed Dec 20 07:58:11 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Dec 2017 08:58:11 +0100 Subject: RFR: JDK-8193512: remove remnants of javah from jdk/jdk10 repo In-Reply-To: <5A398A10.3020203@oracle.com> References: <5A398A10.3020203@oracle.com> Message-ID: Looks good, but please use an actual autoconf 2.69 to generate the configure scripts (see private email). /Erik On 2017-12-19 22:52, Jonathan Gibbons wrote: > Please review these changes to remove the remnants of javah (and in a > couple of tests, some remnants of apt and an earlier version of javap) > from the repo, now that the tool itself has been removed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8193512 > Webrev: http://cr.openjdk.java.net/~jjg/8193512/webrev.00/ > > -- Jon From david.buck at oracle.com Wed Dec 20 08:13:04 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 20 Dec 2017 17:13:04 +0900 Subject: Building hsdis? In-Reply-To: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> Message-ID: Hi Ted! No blog to point you to, but building on non-Windows platforms should be pretty painless these days. > then tried again with the JDK source Yes, that is the one to use. The makefile had a number of issues that I fixed recently but have not (yet) backported to 8u-dev. I was able to build on an Ubuntu 16.4 (AMD64) using the following commands (output omitted): === hg clone http://hg.openjdk.java.net/jdk/hs wget http://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.gz tar xf binutils-2.28.1.tar.gz cd hs/src/utils/hsdis/ make all64 BINUTILS=../../../../binutils-2.28.1 === The above steps resulted in the plugin being generated here: hs/src/utils/hsdis/build/linux-amd64/hsdis-amd64.so Note the version of binutils I used, there is some issue with 2.29 and later versions that prevents the build from succeeding. I hope to investigate if I get some extra bandwidth next year. Also, avoiding "cross compiling" is probably a good idea. If you want to build a 32-bit plugin, it is probably simpler to just build it in a 32-bit environment. Let us know once you get this working. macOS is pretty similar. Then we can take a crack at a Windows build if you are up for it. Cheers, -Buck On 2017/12/20 7:13, Ted Neward wrote: > Hey, all. Been trying for a day and a half now to build the hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first off of the JDK8u source, then tried again with the JDK source, no love either way.) > > > > Is there a definitive page (wiki, blog, etc) that describes how to build hsdis on different platforms? I?m trying right now in an Ubuntu 16 VM, but would also want to build on Windows and/or macOS. All the Web is showing me is posts from a few years ago that don?t seem to address some of the issues I?m running into. > > > > I can copy build output if it?ll help, but wanted to go do my homework before doing that. :-) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From Alan.Bateman at oracle.com Wed Dec 20 08:31:34 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Dec 2017 08:31:34 +0000 Subject: RFR: JDK-8193512: remove remnants of javah from jdk/jdk10 repo In-Reply-To: <5A398A10.3020203@oracle.com> References: <5A398A10.3020203@oracle.com> Message-ID: On 19/12/2017 21:52, Jonathan Gibbons wrote: > Please review these changes to remove the remnants of javah (and in a > couple of tests, some remnants of apt and an earlier version of javap) > from the repo, now that the tool itself has been removed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8193512 > Webrev: http://cr.openjdk.java.net/~jjg/8193512/webrev.00/ Looks good (and amusing to see file paths to long-removed `apt` going away). -Alan From ted at tedneward.com Wed Dec 20 08:31:15 2017 From: ted at tedneward.com (Ted Neward) Date: Wed, 20 Dec 2017 00:31:15 -0800 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> Message-ID: <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> I will give this a shot tomorrow; I can see two things already that I did that was different, the version of binutils (I was using 2.32) and the make command (I was doing make BINUTILS= ARCH=amd64 from the hsdis directory itself inside the jdk source. Do I need to clone the hs repo on its own? Or can I use the bits buried inside of jdk/src/... (sorry I can't remember the full path off the top of my head)? Once we confirm that this works, I'll work with you on Windows--fortunately I know Windows better than Ubuntu, so hopefully that helps. :-) (And let's be really clear, I *really* don't know what's going on with the texinfo and all that stuff.) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 ?On 12/20/17, 12:13 AM, "David Buck" wrote: Hi Ted! No blog to point you to, but building on non-Windows platforms should be pretty painless these days. > then tried again with the JDK source Yes, that is the one to use. The makefile had a number of issues that I fixed recently but have not (yet) backported to 8u-dev. I was able to build on an Ubuntu 16.4 (AMD64) using the following commands (output omitted): === hg clone http://hg.openjdk.java.net/jdk/hs wget http://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.gz tar xf binutils-2.28.1.tar.gz cd hs/src/utils/hsdis/ make all64 BINUTILS=../../../../binutils-2.28.1 === The above steps resulted in the plugin being generated here: hs/src/utils/hsdis/build/linux-amd64/hsdis-amd64.so Note the version of binutils I used, there is some issue with 2.29 and later versions that prevents the build from succeeding. I hope to investigate if I get some extra bandwidth next year. Also, avoiding "cross compiling" is probably a good idea. If you want to build a 32-bit plugin, it is probably simpler to just build it in a 32-bit environment. Let us know once you get this working. macOS is pretty similar. Then we can take a crack at a Windows build if you are up for it. Cheers, -Buck On 2017/12/20 7:13, Ted Neward wrote: > Hey, all. Been trying for a day and a half now to build the hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first off of the JDK8u source, then tried again with the JDK source, no love either way.) > > > > Is there a definitive page (wiki, blog, etc) that describes how to build hsdis on different platforms? I?m trying right now in an Ubuntu 16 VM, but would also want to build on Windows and/or macOS. All the Web is showing me is posts from a few years ago that don?t seem to address some of the issues I?m running into. > > > > I can copy build output if it?ll help, but wanted to go do my homework before doing that. :-) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From david.buck at oracle.com Wed Dec 20 08:54:43 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 20 Dec 2017 17:54:43 +0900 Subject: Building hsdis? In-Reply-To: <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> Message-ID: <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> Hi Ted! > the version of binutils (I was using 2.32) Not sure what that is. Latest binutils is 2.29.1. > I was doing make BINUTILS= ARCH=amd64 That should also work, but I'd still keep things simple and just specify the "all64" make target. As always, whatever is documented in the README file should probably be your default choice. > Do I need to clone the hs repo on its own? Or can I use the bits > buried inside of jdk/src/... No need to clone jdk/hs. I was just cloning it out of habit. All you need is the contents of the hsdir directory (from either repository). There is not much active work done on hsdis, so in practice you are unlikely to notice a difference between the jdk and hs repositories. Cheers, -Buck On 2017/12/20 17:31, Ted Neward wrote: > I will give this a shot tomorrow; I can see two things already that I did that was different, the version of binutils (I was using 2.32) and the make command (I was doing make BINUTILS= ARCH=amd64 from the hsdis directory itself inside the jdk source. Do I need to clone the hs repo on its own? Or can I use the bits buried inside of jdk/src/... (sorry I can't remember the full path off the top of my head)? > > Once we confirm that this works, I'll work with you on Windows--fortunately I know Windows better than Ubuntu, so hopefully that helps. :-) (And let's be really clear, I *really* don't know what's going on with the texinfo and all that stuff.) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > ?On 12/20/17, 12:13 AM, "David Buck" wrote: > > Hi Ted! > > No blog to point you to, but building on non-Windows platforms should be > pretty painless these days. > > > then tried again with the JDK source > > Yes, that is the one to use. The makefile had a number of issues that I > fixed recently but have not (yet) backported to 8u-dev. > > I was able to build on an Ubuntu 16.4 (AMD64) using the following > commands (output omitted): > > === > hg clone http://hg.openjdk.java.net/jdk/hs > wget http://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.gz > tar xf binutils-2.28.1.tar.gz > cd hs/src/utils/hsdis/ > make all64 BINUTILS=../../../../binutils-2.28.1 > === > > The above steps resulted in the plugin being generated here: > > hs/src/utils/hsdis/build/linux-amd64/hsdis-amd64.so > > Note the version of binutils I used, there is some issue with 2.29 and > later versions that prevents the build from succeeding. I hope to > investigate if I get some extra bandwidth next year. Also, avoiding > "cross compiling" is probably a good idea. If you want to build a 32-bit > plugin, it is probably simpler to just build it in a 32-bit environment. > > Let us know once you get this working. macOS is pretty similar. Then we > can take a crack at a Windows build if you are up for it. > > Cheers, > -Buck > > On 2017/12/20 7:13, Ted Neward wrote: > > Hey, all. Been trying for a day and a half now to build the hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first off of the JDK8u source, then tried again with the JDK source, no love either way.) > > > > > > > > Is there a definitive page (wiki, blog, etc) that describes how to build hsdis on different platforms? I?m trying right now in an Ubuntu 16 VM, but would also want to build on Windows and/or macOS. All the Web is showing me is posts from a few years ago that don?t seem to address some of the issues I?m running into. > > > > > > > > I can copy build output if it?ll help, but wanted to go do my homework before doing that. :-) > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > From volker.simonis at gmail.com Wed Dec 20 09:32:45 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Dec 2017 10:32:45 +0100 Subject: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad In-Reply-To: <6838c67f5a7f44c0a48a79e8ac47e889@sap.com> References: <6838c67f5a7f44c0a48a79e8ac47e889@sap.com> Message-ID: Hi Matthias, the change looks good! I can sponsor it once we get the approval. Also forwarded to buil-dev for the minimal build change. Thank you and best regards, Volker On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias wrote: > Hello , Mark reported this issue on AIX with OpenJDK8 : > >> >>I'm getting an unsatisfied link error when using logstash on AIX but I suspect the issue is with AIX or the JRE, the exception is: >> >> java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()D >> getProcessCpuLoad at sun/management/OperatingSystemImpl.java:-2 >> at org/logstash/instrument/monitors/ProcessMonitor.java:40 >> detect at org/logstash/instrument/monitors/ProcessMonitor.java:79 >> generate at org/logstash/instrument/reports/ProcessReport.java:15 >> >> this is the line in logstash: >> >> this.cpuProcessPercent = scaleLoadToPercent(unixOsBean.getProcessCpuLoad()); >> >> https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java/org/logstash/instrument/monitors/ProcessMonitor.java >> >> >> Could anybody help steer me in the right direction? >> > > This fix addresses the missing getSystemCpuLoad and getProcessCpuLoad on AIX . > JDK8 is only affected , JDK9 and higher is not affected . > > Could I get a review for this change ? > > > Change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8193807/ > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8193807 > > > Thanks, Matthias From ted at tedneward.com Wed Dec 20 09:35:04 2017 From: ted at tedneward.com (Ted Neward) Date: Wed, 20 Dec 2017 01:35:04 -0800 Subject: Building hsdis? In-Reply-To: <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> Message-ID: Sorry--I was cribbing from here (https://www.chrisnewland.com/building-hsdis-on-linux-amd64-on-debian-369) and it references using 2.23, which memory transposed to 2.32, I think. I'm not sure what was going wrong (well, I can tell you what the errors were, but I dunno what was causing them), but I want to work from something we know works (a la your instructions) and hopefully that'll catch any environmental differences that might be causing any problems. :-) The README was a little confusing when I was going through it; I'll try to go back over it tomorrow and try to identify which parts left me confused, in case it's something that needs correcting. (I hold the possibility that I'm just an idiot as a very strong possibility.) BTW, I'm sure there's a good reason for this, but why doesn't OpenJDK/Oracle offer pre-built versions of hsdis for a variety of common platforms? Is there a licensing issue? I'll give this a spin tomorrow and fire back with any issues/questions. Thanks! Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 ?On 12/20/17, 12:54 AM, "David Buck" wrote: Hi Ted! > the version of binutils (I was using 2.32) Not sure what that is. Latest binutils is 2.29.1. > I was doing make BINUTILS= ARCH=amd64 That should also work, but I'd still keep things simple and just specify the "all64" make target. As always, whatever is documented in the README file should probably be your default choice. > Do I need to clone the hs repo on its own? Or can I use the bits > buried inside of jdk/src/... No need to clone jdk/hs. I was just cloning it out of habit. All you need is the contents of the hsdir directory (from either repository). There is not much active work done on hsdis, so in practice you are unlikely to notice a difference between the jdk and hs repositories. Cheers, -Buck On 2017/12/20 17:31, Ted Neward wrote: > I will give this a shot tomorrow; I can see two things already that I did that was different, the version of binutils (I was using 2.32) and the make command (I was doing make BINUTILS= ARCH=amd64 from the hsdis directory itself inside the jdk source. Do I need to clone the hs repo on its own? Or can I use the bits buried inside of jdk/src/... (sorry I can't remember the full path off the top of my head)? > > Once we confirm that this works, I'll work with you on Windows--fortunately I know Windows better than Ubuntu, so hopefully that helps. :-) (And let's be really clear, I *really* don't know what's going on with the texinfo and all that stuff.) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > ?On 12/20/17, 12:13 AM, "David Buck" wrote: > > Hi Ted! > > No blog to point you to, but building on non-Windows platforms should be > pretty painless these days. > > > then tried again with the JDK source > > Yes, that is the one to use. The makefile had a number of issues that I > fixed recently but have not (yet) backported to 8u-dev. > > I was able to build on an Ubuntu 16.4 (AMD64) using the following > commands (output omitted): > > === > hg clone http://hg.openjdk.java.net/jdk/hs > wget http://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.gz > tar xf binutils-2.28.1.tar.gz > cd hs/src/utils/hsdis/ > make all64 BINUTILS=../../../../binutils-2.28.1 > === > > The above steps resulted in the plugin being generated here: > > hs/src/utils/hsdis/build/linux-amd64/hsdis-amd64.so > > Note the version of binutils I used, there is some issue with 2.29 and > later versions that prevents the build from succeeding. I hope to > investigate if I get some extra bandwidth next year. Also, avoiding > "cross compiling" is probably a good idea. If you want to build a 32-bit > plugin, it is probably simpler to just build it in a 32-bit environment. > > Let us know once you get this working. macOS is pretty similar. Then we > can take a crack at a Windows build if you are up for it. > > Cheers, > -Buck > > On 2017/12/20 7:13, Ted Neward wrote: > > Hey, all. Been trying for a day and a half now to build the hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first off of the JDK8u source, then tried again with the JDK source, no love either way.) > > > > > > > > Is there a definitive page (wiki, blog, etc) that describes how to build hsdis on different platforms? I?m trying right now in an Ubuntu 16 VM, but would also want to build on Windows and/or macOS. All the Web is showing me is posts from a few years ago that don?t seem to address some of the issues I?m running into. > > > > > > > > I can copy build output if it?ll help, but wanted to go do my homework before doing that. :-) > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > From david.buck at oracle.com Wed Dec 20 09:40:04 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 20 Dec 2017 18:40:04 +0900 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> Message-ID: <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> Hi Ted! > BTW, I'm sure there's a good reason for this, but why doesn't OpenJDK/Oracle offer pre-built versions of hsdis for a variety of common platforms? Is there a licensing issue? Yes, binutils is GPL 3, and OpenJDK is under GPL 2. We are very aware of this as a pain point and are looking to improve things in the future. It is simply a matter of bandwidth at the moment. Cheers, -Buck On 2017/12/20 18:35, Ted Neward wrote: > Sorry--I was cribbing from here (https://www.chrisnewland.com/building-hsdis-on-linux-amd64-on-debian-369) and it references using 2.23, which memory transposed to 2.32, I think. > > I'm not sure what was going wrong (well, I can tell you what the errors were, but I dunno what was causing them), but I want to work from something we know works (a la your instructions) and hopefully that'll catch any environmental differences that might be causing any problems. :-) > > The README was a little confusing when I was going through it; I'll try to go back over it tomorrow and try to identify which parts left me confused, in case it's something that needs correcting. (I hold the possibility that I'm just an idiot as a very strong possibility.) > > BTW, I'm sure there's a good reason for this, but why doesn't OpenJDK/Oracle offer pre-built versions of hsdis for a variety of common platforms? Is there a licensing issue? > > I'll give this a spin tomorrow and fire back with any issues/questions. Thanks! > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > ?On 12/20/17, 12:54 AM, "David Buck" wrote: > > Hi Ted! > > > the version of binutils (I was using 2.32) > > Not sure what that is. Latest binutils is 2.29.1. > > > I was doing make BINUTILS= ARCH=amd64 > > That should also work, but I'd still keep things simple and just specify > the "all64" make target. As always, whatever is documented in the README > file should probably be your default choice. > > > Do I need to clone the hs repo on its own? Or can I use the bits > > buried inside of jdk/src/... > > No need to clone jdk/hs. I was just cloning it out of habit. All you > need is the contents of the hsdir directory (from either repository). > There is not much active work done on hsdis, so in practice you are > unlikely to notice a difference between the jdk and hs repositories. > > Cheers, > -Buck > > On 2017/12/20 17:31, Ted Neward wrote: > > I will give this a shot tomorrow; I can see two things already that I did that was different, the version of binutils (I was using 2.32) and the make command (I was doing make BINUTILS= ARCH=amd64 from the hsdis directory itself inside the jdk source. Do I need to clone the hs repo on its own? Or can I use the bits buried inside of jdk/src/... (sorry I can't remember the full path off the top of my head)? > > > > Once we confirm that this works, I'll work with you on Windows--fortunately I know Windows better than Ubuntu, so hopefully that helps. :-) (And let's be really clear, I *really* don't know what's going on with the texinfo and all that stuff.) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > ?On 12/20/17, 12:13 AM, "David Buck" wrote: > > > > Hi Ted! > > > > No blog to point you to, but building on non-Windows platforms should be > > pretty painless these days. > > > > > then tried again with the JDK source > > > > Yes, that is the one to use. The makefile had a number of issues that I > > fixed recently but have not (yet) backported to 8u-dev. > > > > I was able to build on an Ubuntu 16.4 (AMD64) using the following > > commands (output omitted): > > > > === > > hg clone http://hg.openjdk.java.net/jdk/hs > > wget http://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.gz > > tar xf binutils-2.28.1.tar.gz > > cd hs/src/utils/hsdis/ > > make all64 BINUTILS=../../../../binutils-2.28.1 > > === > > > > The above steps resulted in the plugin being generated here: > > > > hs/src/utils/hsdis/build/linux-amd64/hsdis-amd64.so > > > > Note the version of binutils I used, there is some issue with 2.29 and > > later versions that prevents the build from succeeding. I hope to > > investigate if I get some extra bandwidth next year. Also, avoiding > > "cross compiling" is probably a good idea. If you want to build a 32-bit > > plugin, it is probably simpler to just build it in a 32-bit environment. > > > > Let us know once you get this working. macOS is pretty similar. Then we > > can take a crack at a Windows build if you are up for it. > > > > Cheers, > > -Buck > > > > On 2017/12/20 7:13, Ted Neward wrote: > > > Hey, all. Been trying for a day and a half now to build the hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first off of the JDK8u source, then tried again with the JDK source, no love either way.) > > > > > > > > > > > > Is there a definitive page (wiki, blog, etc) that describes how to build hsdis on different platforms? I?m trying right now in an Ubuntu 16 VM, but would also want to build on Windows and/or macOS. All the Web is showing me is posts from a few years ago that don?t seem to address some of the issues I?m running into. > > > > > > > > > > > > I can copy build output if it?ll help, but wanted to go do my homework before doing that. :-) > > > > > > > > > > > > Ted Neward > > > > > > Author, Speaker, Mentor > > > > > > http://www.newardassociates.com > > > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > > > > > From david.holmes at oracle.com Wed Dec 20 09:51:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Dec 2017 19:51:20 +1000 Subject: RFR: 8192837 Need new test for release file info In-Reply-To: <5A393CF1.7080906@Oracle.com> References: <5A37F318.5020207@Oracle.com> <5A393CF1.7080906@Oracle.com> Message-ID: On 20/12/2017 2:23 AM, Randy Crihfield wrote: > > This ought to be what you were asking for. > > http://cr.openjdk.java.net/~shurailine/8192837/webrev.03/ Closer :) A few nits: - the test needs a proper @run tag - NegSOURCE is hardly informative - how about CheckReleaseFile? - there are a couple of style nits with indentation of wrapped lines: 71 throw new RuntimeException("File " + fileName + 72 " not found reading data!", fileExcept); 73 } catch (IOException ioExcept) { 74 throw new RuntimeException("Unexpected problem reading data!", 75 ioExcept); should be: 71 throw new RuntimeException("File " + fileName + 72 " not found reading data!", fileExcept); 73 } catch (IOException ioExcept) { 74 throw new RuntimeException("Unexpected problem reading data!", 75 ioExcept); As a general style comment there's no need to use instance methods here, you could just define readFile as static, or even inline it into main directly. Thanks, David > > Thanks for the help > > Randy > > On 12/18/17 09:32 PM, David Holmes wrote: >> Hi Randy, >> >> jdk/sanity/Test8192837.java >> >> We don't name tests with bug numbers any more - the file/class should >> be renamed to something appropriate to its actual function. >> >> ? 64???????????????? // grab the line >> ? 65???????????????? if (readIn.startsWith("SOURCE=")) >> ? 66???????????????????? fishForSOURCE = readIn; >> >> Do you expect to find more than one SOURCE line? If not this should >> "break". If so, then you're only going to check the last one found. >> >> ? 98???????? if (runtime.contains("OpenJDK")) >> ? 99???????????? new Test8192837(jdkPath + "/release"); >> ?100???????? else >> ?101???????????? System.out.println("Not an OpenJDK."); >> >> It would be preferable if this can be done via some @requires tag >> rather than within the test. But otherwise it would be better to print >> "Test skipped: not an OpenJDK build". >> >> Thanks, >> David >> >> On 19/12/2017 3:23 AM, Erik Joelsson wrote: >>> Redirecting to correct list. >>> >>> The test seems to do what it set out to do. >>> >>> /Erik >>> >>> >>> On 2017-12-18 17:55, Randy Crihfield wrote: >>>> I have created an OpenJDK negative test that confirms the closed >>>> source files are not included in the SOURCE. >>>> >>>> Version of the actual test for review: >>>> >>>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ >>>> >>>> Any comments/suggestions are welcome, also I will need a sponsor for >>>> it at the end? >>>> >>>> Randy >>>> >>> > From volker.simonis at gmail.com Wed Dec 20 09:54:21 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Dec 2017 10:54:21 +0100 Subject: Building hsdis? In-Reply-To: <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> Message-ID: On Wed, Dec 20, 2017 at 10:40 AM, David Buck wrote: > Hi Ted! > >> BTW, I'm sure there's a good reason for this, but why doesn't >> OpenJDK/Oracle offer pre-built versions of hsdis for a variety of common >> platforms? Is there a licensing issue? > > Yes, binutils is GPL 3, and OpenJDK is under GPL 2. We are very aware of > this as a pain point and are looking to improve things in the future. It is > simply a matter of bandwidth at the moment. > Yes, that's exactly the issue. And it was communicated to the OpenJDK Governing Board more than two and a half years ago (see my mail "Providing 'hsdis' binaries not possible because of GPLv2/GPLv3 license clash" from May 2015 [1]) and since then reiterated several times. I'll plan to raise this issue again at the public GB meeting at FOSDEM in February next year - however with very little hope that it will be resolved :( Regards, Volker [1] http://mail.openjdk.java.net/pipermail/discuss/2015-May/003754.html > Cheers, > -Buck > > > On 2017/12/20 18:35, Ted Neward wrote: >> >> Sorry--I was cribbing from here >> (https://www.chrisnewland.com/building-hsdis-on-linux-amd64-on-debian-369) >> and it references using 2.23, which memory transposed to 2.32, I think. >> >> I'm not sure what was going wrong (well, I can tell you what the errors >> were, but I dunno what was causing them), but I want to work from something >> we know works (a la your instructions) and hopefully that'll catch any >> environmental differences that might be causing any problems. :-) >> >> The README was a little confusing when I was going through it; I'll try to >> go back over it tomorrow and try to identify which parts left me confused, >> in case it's something that needs correcting. (I hold the possibility that >> I'm just an idiot as a very strong possibility.) >> >> BTW, I'm sure there's a good reason for this, but why doesn't >> OpenJDK/Oracle offer pre-built versions of hsdis for a variety of common >> platforms? Is there a licensing issue? >> >> I'll give this a spin tomorrow and fire back with any issues/questions. >> Thanks! >> >> Ted Neward >> Author, Speaker, Mentor >> http://www.newardassociates.com >> t: @tedneward | m: (425) 647-4526 >> >> ?On 12/20/17, 12:54 AM, "David Buck" wrote: >> >> Hi Ted! >> > the version of binutils (I was using 2.32) >> Not sure what that is. Latest binutils is 2.29.1. >> > I was doing make BINUTILS= ARCH=amd64 >> That should also work, but I'd still keep things simple and just >> specify >> the "all64" make target. As always, whatever is documented in the >> README >> file should probably be your default choice. >> > Do I need to clone the hs repo on its own? Or can I use the >> bits >> > buried inside of jdk/src/... >> No need to clone jdk/hs. I was just cloning it out of habit. All >> you >> need is the contents of the hsdir directory (from either repository). >> There is not much active work done on hsdis, so in practice you are >> unlikely to notice a difference between the jdk and hs repositories. >> Cheers, >> -Buck >> On 2017/12/20 17:31, Ted Neward wrote: >> > I will give this a shot tomorrow; I can see two things already that >> I did that was different, the version of binutils (I was using 2.32) and the >> make command (I was doing make BINUTILS= ARCH=amd64 from the >> hsdis directory itself inside the jdk source. Do I need to clone the hs repo >> on its own? Or can I use the bits buried inside of jdk/src/... (sorry I >> can't remember the full path off the top of my head)? >> > >> > Once we confirm that this works, I'll work with you on >> Windows--fortunately I know Windows better than Ubuntu, so hopefully that >> helps. :-) (And let's be really clear, I *really* don't know what's going on >> with the texinfo and all that stuff.) >> > >> > Ted Neward >> > Author, Speaker, Mentor >> > http://www.newardassociates.com >> > t: @tedneward | m: (425) 647-4526 >> > >> > ?On 12/20/17, 12:13 AM, "David Buck" wrote: >> > >> > Hi Ted! >> > >> > No blog to point you to, but building on non-Windows platforms >> should be >> > pretty painless these days. >> > >> > > then tried again with the JDK source >> > >> > Yes, that is the one to use. The makefile had a number of >> issues that I >> > fixed recently but have not (yet) backported to 8u-dev. >> > >> > I was able to build on an Ubuntu 16.4 (AMD64) using the >> following >> > commands (output omitted): >> > >> > === >> > hg clone http://hg.openjdk.java.net/jdk/hs >> > wget http://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.gz >> > tar xf binutils-2.28.1.tar.gz >> > cd hs/src/utils/hsdis/ >> > make all64 BINUTILS=../../../../binutils-2.28.1 >> > === >> > >> > The above steps resulted in the plugin being generated here: >> > >> > hs/src/utils/hsdis/build/linux-amd64/hsdis-amd64.so >> > >> > Note the version of binutils I used, there is some issue with >> 2.29 and >> > later versions that prevents the build from succeeding. I hope >> to >> > investigate if I get some extra bandwidth next year. Also, >> avoiding >> > "cross compiling" is probably a good idea. If you want to >> build a 32-bit >> > plugin, it is probably simpler to just build it in a 32-bit >> environment. >> > >> > Let us know once you get this working. macOS is pretty >> similar. Then we >> > can take a crack at a Windows build if you are up for it. >> > >> > Cheers, >> > -Buck >> > >> > On 2017/12/20 7:13, Ted Neward wrote: >> > > Hey, all. Been trying for a day and a half now to build the >> hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first >> off of the JDK8u source, then tried again with the JDK source, no love >> either way.) >> > > >> > > >> > > >> > > Is there a definitive page (wiki, blog, etc) that describes >> how to build hsdis on different platforms? I?m trying right now in an Ubuntu >> 16 VM, but would also want to build on Windows and/or macOS. All the Web is >> showing me is posts from a few years ago that don?t seem to address some of >> the issues I?m running into. >> > > >> > > >> > > >> > > I can copy build output if it?ll help, but wanted to go do >> my homework before doing that. :-) >> > > >> > > >> > > >> > > Ted Neward >> > > >> > > Author, Speaker, Mentor >> > > >> > > http://www.newardassociates.com >> > > >> > > t: @tedneward | m: (425) 647-4526 >> > > >> > >> > >> > >> >> > From erik.joelsson at oracle.com Wed Dec 20 10:25:36 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Dec 2017 11:25:36 +0100 Subject: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad In-Reply-To: References: <6838c67f5a7f44c0a48a79e8ac47e889@sap.com> Message-ID: Looks ok to me. /Erik On 2017-12-20 10:32, Volker Simonis wrote: > Hi Matthias, > > the change looks good! > I can sponsor it once we get the approval. > > Also forwarded to buil-dev for the minimal build change. > > Thank you and best regards, > Volker > > > On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias > wrote: >> Hello , Mark reported this issue on AIX with OpenJDK8 : >> >>> I'm getting an unsatisfied link error when using logstash on AIX but I suspect the issue is with AIX or the JRE, the exception is: >>> >>> java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()D >>> getProcessCpuLoad at sun/management/OperatingSystemImpl.java:-2 >>> at org/logstash/instrument/monitors/ProcessMonitor.java:40 >>> detect at org/logstash/instrument/monitors/ProcessMonitor.java:79 >>> generate at org/logstash/instrument/reports/ProcessReport.java:15 >>> >>> this is the line in logstash: >>> >>> this.cpuProcessPercent = scaleLoadToPercent(unixOsBean.getProcessCpuLoad()); >>> >>> https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java/org/logstash/instrument/monitors/ProcessMonitor.java >>> >>> >>> Could anybody help steer me in the right direction? >>> >> This fix addresses the missing getSystemCpuLoad and getProcessCpuLoad on AIX . >> JDK8 is only affected , JDK9 and higher is not affected . >> >> Could I get a review for this change ? >> >> >> Change : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8193807/ >> >> Bug : >> >> https://bugs.openjdk.java.net/browse/JDK-8193807 >> >> >> Thanks, Matthias From Randy.Crihfield at Oracle.com Wed Dec 20 16:51:58 2017 From: Randy.Crihfield at Oracle.com (Randy Crihfield) Date: Wed, 20 Dec 2017 11:51:58 -0500 Subject: RFR: 8192837 Need new test for release file info In-Reply-To: References: <5A37F318.5020207@Oracle.com> <5A393CF1.7080906@Oracle.com> Message-ID: <5A3A952E.1090602@Oracle.com> Could this be it? http://cr.openjdk.java.net/~shurailine/8192837/webrev.04/ Thanks! Randy On 12/20/17 04:51 AM, David Holmes wrote: > On 20/12/2017 2:23 AM, Randy Crihfield wrote: >> >> This ought to be what you were asking for. >> >> http://cr.openjdk.java.net/~shurailine/8192837/webrev.03/ > > Closer :) A few nits: > > - the test needs a proper @run tag > - NegSOURCE is hardly informative - how about CheckReleaseFile? > - there are a couple of style nits with indentation of wrapped lines: > > 71 throw new RuntimeException("File " + fileName + > 72 " not found reading data!", fileExcept); > 73 } catch (IOException ioExcept) { > 74 throw new RuntimeException("Unexpected problem > reading data!", > 75 ioExcept); > > should be: > > 71 throw new RuntimeException("File " + fileName + > 72 " not found reading > data!", fileExcept); > 73 } catch (IOException ioExcept) { > 74 throw new RuntimeException("Unexpected problem > reading data!", > 75 ioExcept); > > As a general style comment there's no need to use instance methods > here, you could just define readFile as static, or even inline it into > main directly. > > Thanks, > David > >> >> Thanks for the help >> >> Randy >> >> On 12/18/17 09:32 PM, David Holmes wrote: >>> Hi Randy, >>> >>> jdk/sanity/Test8192837.java >>> >>> We don't name tests with bug numbers any more - the file/class >>> should be renamed to something appropriate to its actual function. >>> >>> 64 // grab the line >>> 65 if (readIn.startsWith("SOURCE=")) >>> 66 fishForSOURCE = readIn; >>> >>> Do you expect to find more than one SOURCE line? If not this should >>> "break". If so, then you're only going to check the last one found. >>> >>> 98 if (runtime.contains("OpenJDK")) >>> 99 new Test8192837(jdkPath + "/release"); >>> 100 else >>> 101 System.out.println("Not an OpenJDK."); >>> >>> It would be preferable if this can be done via some @requires tag >>> rather than within the test. But otherwise it would be better to >>> print "Test skipped: not an OpenJDK build". >>> >>> Thanks, >>> David >>> >>> On 19/12/2017 3:23 AM, Erik Joelsson wrote: >>>> Redirecting to correct list. >>>> >>>> The test seems to do what it set out to do. >>>> >>>> /Erik >>>> >>>> >>>> On 2017-12-18 17:55, Randy Crihfield wrote: >>>>> I have created an OpenJDK negative test that confirms the closed >>>>> source files are not included in the SOURCE. >>>>> >>>>> Version of the actual test for review: >>>>> >>>>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ >>>>> >>>>> Any comments/suggestions are welcome, also I will need a sponsor >>>>> for it at the end? >>>>> >>>>> Randy >>>>> >>>> >> From david.holmes at oracle.com Thu Dec 21 01:30:29 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Dec 2017 11:30:29 +1000 Subject: RFR: 8192837 Need new test for release file info In-Reply-To: <5A3A952E.1090602@Oracle.com> References: <5A37F318.5020207@Oracle.com> <5A393CF1.7080906@Oracle.com> <5A3A952E.1090602@Oracle.com> Message-ID: On 21/12/2017 2:51 AM, Randy Crihfield wrote: > > Could this be it? > > http://cr.openjdk.java.net/~shurailine/8192837/webrev.04/ 29 * @run testing NegReleaseSOURCE If you are going to write a jtreg test you have to actually run it under jtreg! That @run line is invalid - "testing" is not an @run action (did you perchance try to copy a testng @run entry?). A minimal @run for this test would be: @run main NegReleaseSOURCE As for the name ... sorry I don't know what NegReleaseSOURCE is supposed to mean. There's no reason to be cryptic (that's why we stopped using bug numbers to name tests). You could even add a subdirectory for release file related tests: sanity/releaseFile/CheckSOURCE.java Thanks, David > Thanks! > > Randy > > On 12/20/17 04:51 AM, David Holmes wrote: >> On 20/12/2017 2:23 AM, Randy Crihfield wrote: >>> >>> This ought to be what you were asking for. >>> >>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.03/ >> >> Closer :) A few nits: >> >> - the test needs a proper @run tag >> - NegSOURCE is hardly informative - how about CheckReleaseFile? >> - there are a couple of style nits with indentation of wrapped lines: >> >> ? 71???????????? throw new RuntimeException("File " + fileName + >> ? 72???????????????? " not found reading data!", fileExcept); >> ? 73???????? } catch (IOException ioExcept) { >> ? 74???????????? throw new RuntimeException("Unexpected problem >> reading data!", >> ? 75???????????? ioExcept); >> >> should be: >> >> ? 71???????????? throw new RuntimeException("File " + fileName + >> ? 72??????????????????????????????????????? " not found reading >> data!", fileExcept); >> ? 73???????? } catch (IOException ioExcept) { >> ? 74???????????? throw new RuntimeException("Unexpected problem >> reading data!", >> ? 75???????????????????????????????????????? ioExcept); >> >> As a general style comment there's no need to use instance methods >> here, you could just define readFile as static, or even inline it into >> main directly. >> >> Thanks, >> David >> >>> >>> Thanks for the help >>> >>> Randy >>> >>> On 12/18/17 09:32 PM, David Holmes wrote: >>>> Hi Randy, >>>> >>>> jdk/sanity/Test8192837.java >>>> >>>> We don't name tests with bug numbers any more - the file/class >>>> should be renamed to something appropriate to its actual function. >>>> >>>> ? 64???????????????? // grab the line >>>> ? 65???????????????? if (readIn.startsWith("SOURCE=")) >>>> ? 66???????????????????? fishForSOURCE = readIn; >>>> >>>> Do you expect to find more than one SOURCE line? If not this should >>>> "break". If so, then you're only going to check the last one found. >>>> >>>> ? 98???????? if (runtime.contains("OpenJDK")) >>>> ? 99???????????? new Test8192837(jdkPath + "/release"); >>>> ?100???????? else >>>> ?101???????????? System.out.println("Not an OpenJDK."); >>>> >>>> It would be preferable if this can be done via some @requires tag >>>> rather than within the test. But otherwise it would be better to >>>> print "Test skipped: not an OpenJDK build". >>>> >>>> Thanks, >>>> David >>>> >>>> On 19/12/2017 3:23 AM, Erik Joelsson wrote: >>>>> Redirecting to correct list. >>>>> >>>>> The test seems to do what it set out to do. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-12-18 17:55, Randy Crihfield wrote: >>>>>> I have created an OpenJDK negative test that confirms the closed >>>>>> source files are not included in the SOURCE. >>>>>> >>>>>> Version of the actual test for review: >>>>>> >>>>>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ >>>>>> >>>>>> Any comments/suggestions are welcome, also I will need a sponsor >>>>>> for it at the end? >>>>>> >>>>>> Randy >>>>>> >>>>> >>> > From ted at tedneward.com Thu Dec 21 02:27:59 2017 From: ted at tedneward.com (Ted Neward) Date: Wed, 20 Dec 2017 18:27:59 -0800 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> Message-ID: OK, built flawlessly. Couple of notes: (*) When I tried to do "make both", as mentioned in the README, it failed in the configure step: "C compiler cannot create executables". This was after "make all64" worked flawlessly. (Both have the BINUTILS variable set via the command-line; I'm eliding it for brevity.) (*) The Windows part of the build instructions in the README was I think what was confusing, but as an editor, I would probably suggest a bit of reordering/rewording to the parts before that to make it a little easier to grok. Happy to make some suggestions there if desired, but not critical. (*) Now, how should we proceed trying to build a Windows version of this? The README mentions both Cygwin and Ming, so I'm not sure what setup you're expecting the Windows developer to have on their machine. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 ?On 12/20/17, 12:13 AM, "David Buck" wrote: Hi Ted! No blog to point you to, but building on non-Windows platforms should be pretty painless these days. > then tried again with the JDK source Yes, that is the one to use. The makefile had a number of issues that I fixed recently but have not (yet) backported to 8u-dev. I was able to build on an Ubuntu 16.4 (AMD64) using the following commands (output omitted): === hg clone http://hg.openjdk.java.net/jdk/hs wget http://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.gz tar xf binutils-2.28.1.tar.gz cd hs/src/utils/hsdis/ make all64 BINUTILS=../../../../binutils-2.28.1 === The above steps resulted in the plugin being generated here: hs/src/utils/hsdis/build/linux-amd64/hsdis-amd64.so Note the version of binutils I used, there is some issue with 2.29 and later versions that prevents the build from succeeding. I hope to investigate if I get some extra bandwidth next year. Also, avoiding "cross compiling" is probably a good idea. If you want to build a 32-bit plugin, it is probably simpler to just build it in a 32-bit environment. Let us know once you get this working. macOS is pretty similar. Then we can take a crack at a Windows build if you are up for it. Cheers, -Buck On 2017/12/20 7:13, Ted Neward wrote: > Hey, all. Been trying for a day and a half now to build the hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first off of the JDK8u source, then tried again with the JDK source, no love either way.) > > > > Is there a definitive page (wiki, blog, etc) that describes how to build hsdis on different platforms? I?m trying right now in an Ubuntu 16 VM, but would also want to build on Windows and/or macOS. All the Web is showing me is posts from a few years ago that don?t seem to address some of the issues I?m running into. > > > > I can copy build output if it?ll help, but wanted to go do my homework before doing that. :-) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From david.buck at oracle.com Thu Dec 21 02:44:25 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 21 Dec 2017 11:44:25 +0900 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> Message-ID: <7236414a-e6e2-053c-07f1-22887ef3089f@oracle.com> Hi Ted! For Windows, I have found the instructions listed here to be the most helpful: https://dropzone.nfshost.com/hsdis.htm I recommend building on Cygwin as described above. You will need the MinGW packages installed in your Cygwin environment (also described in the above post). We realize the README could use some love. It is on my radar, but again, bandwidth is a constraint at the moment Cheers, -Buck On 2017/12/21 11:27, Ted Neward wrote: > OK, built flawlessly. > > Couple of notes: > > (*) When I tried to do "make both", as mentioned in the README, it failed in the configure step: "C compiler cannot create executables". This was after "make all64" worked flawlessly. (Both have the BINUTILS variable set via the command-line; I'm eliding it for brevity.) > > (*) The Windows part of the build instructions in the README was I think what was confusing, but as an editor, I would probably suggest a bit of reordering/rewording to the parts before that to make it a little easier to grok. Happy to make some suggestions there if desired, but not critical. > > (*) Now, how should we proceed trying to build a Windows version of this? The README mentions both Cygwin and Ming, so I'm not sure what setup you're expecting the Windows developer to have on their machine. > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > ?On 12/20/17, 12:13 AM, "David Buck" wrote: > > Hi Ted! > > No blog to point you to, but building on non-Windows platforms should be > pretty painless these days. > > > then tried again with the JDK source > > Yes, that is the one to use. The makefile had a number of issues that I > fixed recently but have not (yet) backported to 8u-dev. > > I was able to build on an Ubuntu 16.4 (AMD64) using the following > commands (output omitted): > > === > hg clone http://hg.openjdk.java.net/jdk/hs > wget http://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.gz > tar xf binutils-2.28.1.tar.gz > cd hs/src/utils/hsdis/ > make all64 BINUTILS=../../../../binutils-2.28.1 > === > > The above steps resulted in the plugin being generated here: > > hs/src/utils/hsdis/build/linux-amd64/hsdis-amd64.so > > Note the version of binutils I used, there is some issue with 2.29 and > later versions that prevents the build from succeeding. I hope to > investigate if I get some extra bandwidth next year. Also, avoiding > "cross compiling" is probably a good idea. If you want to build a 32-bit > plugin, it is probably simpler to just build it in a 32-bit environment. > > Let us know once you get this working. macOS is pretty similar. Then we > can take a crack at a Windows build if you are up for it. > > Cheers, > -Buck > > On 2017/12/20 7:13, Ted Neward wrote: > > Hey, all. Been trying for a day and a half now to build the hsdis disassembly plugin in jdk/src/utils/hsdis, with no luck. (Tried first off of the JDK8u source, then tried again with the JDK source, no love either way.) > > > > > > > > Is there a definitive page (wiki, blog, etc) that describes how to build hsdis on different platforms? I?m trying right now in an Ubuntu 16 VM, but would also want to build on Windows and/or macOS. All the Web is showing me is posts from a few years ago that don?t seem to address some of the issues I?m running into. > > > > > > > > I can copy build output if it?ll help, but wanted to go do my homework before doing that. :-) > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > From ted at tedneward.com Thu Dec 21 09:43:58 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 21 Dec 2017 01:43:58 -0800 Subject: Another question, if I may? Message-ID: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> What?s the steps necessary to add a new -XX flag? I?d assumed (naively) that all that was required was to add it to the list of macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets kicked back out with the ?Unrecognized flag; did you mean??? error. Is there something I?m missing? Does the flag need to be registered someplace else as well? Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 From erik.joelsson at oracle.com Thu Dec 21 10:15:11 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Dec 2017 11:15:11 +0100 Subject: Another question, if I may? In-Reply-To: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> Message-ID: Adding hotspot-dev. /Erik On 2017-12-21 10:43, Ted Neward wrote: > What?s the steps necessary to add a new -XX flag? I?d assumed (naively) that all that was required was to add it to the list of macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets kicked back out with the ?Unrecognized flag; did you mean??? error. > > > > Is there something I?m missing? Does the flag need to be registered someplace else as well? > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > From david.holmes at oracle.com Thu Dec 21 12:20:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Dec 2017 22:20:47 +1000 Subject: Another question, if I may? In-Reply-To: References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> Message-ID: <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com> On 21/12/2017 8:15 PM, Erik Joelsson wrote: > Adding hotspot-dev. > > /Erik > > > On 2017-12-21 10:43, Ted Neward wrote: >> What?s the steps necessary to add a new -XX flag? I?d assumed >> (naively) that all that was required was to add it to the list of >> macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag Yes that should suffice. >> (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets >> kicked back out with the ?Unrecognized flag; did you mean??? error. Why would "make hotspot" be using your new flag? Are you trying to apply your flag to the newly built VM during the build process? I'm not even sure if "make hotspot" would use the new VM. I always do a full build: make images David >> >> >> Is there something I?m missing? Does the flag need to be registered >> someplace else as well? >> >> >> Ted Neward >> >> Author, Speaker, Mentor >> >> http://www.newardassociates.com >> >> t: @tedneward | m: (425) 647-4526 >> > From Randy.Crihfield at Oracle.com Thu Dec 21 16:41:10 2017 From: Randy.Crihfield at Oracle.com (Randy Crihfield) Date: Thu, 21 Dec 2017 11:41:10 -0500 Subject: RFR: 8192837 Need new test for release file info In-Reply-To: References: <5A37F318.5020207@Oracle.com> <5A393CF1.7080906@Oracle.com> <5A3A952E.1090602@Oracle.com> Message-ID: <5A3BE426.4000307@Oracle.com> I think I have it now. http://cr.openjdk.java.net/~shurailine/8192837/webrev.05/ Thanks for the help again! Randy On 12/20/17 08:30 PM, David Holmes wrote: > On 21/12/2017 2:51 AM, Randy Crihfield wrote: >> >> Could this be it? >> >> http://cr.openjdk.java.net/~shurailine/8192837/webrev.04/ > > 29 * @run testing NegReleaseSOURCE > > If you are going to write a jtreg test you have to actually run it > under jtreg! That @run line is invalid - "testing" is not an @run > action (did you perchance try to copy a testng @run entry?). A minimal > @run for this test would be: > > @run main NegReleaseSOURCE > > As for the name ... sorry I don't know what NegReleaseSOURCE is > supposed to mean. There's no reason to be cryptic (that's why we > stopped using bug numbers to name tests). You could even add a > subdirectory for release file related tests: > > sanity/releaseFile/CheckSOURCE.java > > Thanks, > David > >> Thanks! >> >> Randy >> >> On 12/20/17 04:51 AM, David Holmes wrote: >>> On 20/12/2017 2:23 AM, Randy Crihfield wrote: >>>> >>>> This ought to be what you were asking for. >>>> >>>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.03/ >>> >>> Closer :) A few nits: >>> >>> - the test needs a proper @run tag >>> - NegSOURCE is hardly informative - how about CheckReleaseFile? >>> - there are a couple of style nits with indentation of wrapped lines: >>> >>> 71 throw new RuntimeException("File " + fileName + >>> 72 " not found reading data!", fileExcept); >>> 73 } catch (IOException ioExcept) { >>> 74 throw new RuntimeException("Unexpected problem >>> reading data!", >>> 75 ioExcept); >>> >>> should be: >>> >>> 71 throw new RuntimeException("File " + fileName + >>> 72 " not found reading >>> data!", fileExcept); >>> 73 } catch (IOException ioExcept) { >>> 74 throw new RuntimeException("Unexpected problem >>> reading data!", >>> 75 ioExcept); >>> >>> As a general style comment there's no need to use instance methods >>> here, you could just define readFile as static, or even inline it >>> into main directly. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks for the help >>>> >>>> Randy >>>> >>>> On 12/18/17 09:32 PM, David Holmes wrote: >>>>> Hi Randy, >>>>> >>>>> jdk/sanity/Test8192837.java >>>>> >>>>> We don't name tests with bug numbers any more - the file/class >>>>> should be renamed to something appropriate to its actual function. >>>>> >>>>> 64 // grab the line >>>>> 65 if (readIn.startsWith("SOURCE=")) >>>>> 66 fishForSOURCE = readIn; >>>>> >>>>> Do you expect to find more than one SOURCE line? If not this >>>>> should "break". If so, then you're only going to check the last >>>>> one found. >>>>> >>>>> 98 if (runtime.contains("OpenJDK")) >>>>> 99 new Test8192837(jdkPath + "/release"); >>>>> 100 else >>>>> 101 System.out.println("Not an OpenJDK."); >>>>> >>>>> It would be preferable if this can be done via some @requires tag >>>>> rather than within the test. But otherwise it would be better to >>>>> print "Test skipped: not an OpenJDK build". >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 19/12/2017 3:23 AM, Erik Joelsson wrote: >>>>>> Redirecting to correct list. >>>>>> >>>>>> The test seems to do what it set out to do. >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2017-12-18 17:55, Randy Crihfield wrote: >>>>>>> I have created an OpenJDK negative test that confirms the closed >>>>>>> source files are not included in the SOURCE. >>>>>>> >>>>>>> Version of the actual test for review: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ >>>>>>> >>>>>>> Any comments/suggestions are welcome, also I will need a sponsor >>>>>>> for it at the end? >>>>>>> >>>>>>> Randy >>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Thu Dec 21 20:47:54 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Dec 2017 06:47:54 +1000 Subject: RFR: 8192837 Need new test for release file info In-Reply-To: <5A3BE426.4000307@Oracle.com> References: <5A37F318.5020207@Oracle.com> <5A393CF1.7080906@Oracle.com> <5A3A952E.1090602@Oracle.com> <5A3BE426.4000307@Oracle.com> Message-ID: <06101198-c243-935e-6164-1cf258783c10@oracle.com> On 22/12/2017 2:41 AM, Randy Crihfield wrote: > I think I have it now. > > http://cr.openjdk.java.net/~shurailine/8192837/webrev.05/ I still find the name NegativeSOURCETest less than informative. I don't know what naming style you are employing here but it is not a style we generally use in OpenJDK (though langtools does have some "neg" tests). You still need a sponsor. David > > Thanks for the help again! > > Randy > > > On 12/20/17 08:30 PM, David Holmes wrote: >> On 21/12/2017 2:51 AM, Randy Crihfield wrote: >>> >>> Could this be it? >>> >>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.04/ >> >> 29? * @run testing NegReleaseSOURCE >> >> If you are going to write a jtreg test you have to actually run it >> under jtreg! That @run line is invalid - "testing" is not an @run >> action (did you perchance try to copy a testng @run entry?). A minimal >> @run for this test would be: >> >> @run main NegReleaseSOURCE >> >> As for the name ... sorry I don't know what NegReleaseSOURCE is >> supposed to mean. There's no reason to be cryptic (that's why we >> stopped using bug numbers to name tests). You could even add a >> subdirectory for release file related tests: >> >> sanity/releaseFile/CheckSOURCE.java >> >> Thanks, >> David >> >>> Thanks! >>> >>> Randy >>> >>> On 12/20/17 04:51 AM, David Holmes wrote: >>>> On 20/12/2017 2:23 AM, Randy Crihfield wrote: >>>>> >>>>> This ought to be what you were asking for. >>>>> >>>>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.03/ >>>> >>>> Closer :) A few nits: >>>> >>>> - the test needs a proper @run tag >>>> - NegSOURCE is hardly informative - how about CheckReleaseFile? >>>> - there are a couple of style nits with indentation of wrapped lines: >>>> >>>> ? 71???????????? throw new RuntimeException("File " + fileName + >>>> ? 72???????????????? " not found reading data!", fileExcept); >>>> ? 73???????? } catch (IOException ioExcept) { >>>> ? 74???????????? throw new RuntimeException("Unexpected problem >>>> reading data!", >>>> ? 75???????????? ioExcept); >>>> >>>> should be: >>>> >>>> ? 71???????????? throw new RuntimeException("File " + fileName + >>>> ? 72??????????????????????????????????????? " not found reading >>>> data!", fileExcept); >>>> ? 73???????? } catch (IOException ioExcept) { >>>> ? 74???????????? throw new RuntimeException("Unexpected problem >>>> reading data!", >>>> ? 75???????????????????????????????????????? ioExcept); >>>> >>>> As a general style comment there's no need to use instance methods >>>> here, you could just define readFile as static, or even inline it >>>> into main directly. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks for the help >>>>> >>>>> Randy >>>>> >>>>> On 12/18/17 09:32 PM, David Holmes wrote: >>>>>> Hi Randy, >>>>>> >>>>>> jdk/sanity/Test8192837.java >>>>>> >>>>>> We don't name tests with bug numbers any more - the file/class >>>>>> should be renamed to something appropriate to its actual function. >>>>>> >>>>>> ? 64???????????????? // grab the line >>>>>> ? 65???????????????? if (readIn.startsWith("SOURCE=")) >>>>>> ? 66???????????????????? fishForSOURCE = readIn; >>>>>> >>>>>> Do you expect to find more than one SOURCE line? If not this >>>>>> should "break". If so, then you're only going to check the last >>>>>> one found. >>>>>> >>>>>> ? 98???????? if (runtime.contains("OpenJDK")) >>>>>> ? 99???????????? new Test8192837(jdkPath + "/release"); >>>>>> ?100???????? else >>>>>> ?101???????????? System.out.println("Not an OpenJDK."); >>>>>> >>>>>> It would be preferable if this can be done via some @requires tag >>>>>> rather than within the test. But otherwise it would be better to >>>>>> print "Test skipped: not an OpenJDK build". >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 19/12/2017 3:23 AM, Erik Joelsson wrote: >>>>>>> Redirecting to correct list. >>>>>>> >>>>>>> The test seems to do what it set out to do. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>> On 2017-12-18 17:55, Randy Crihfield wrote: >>>>>>>> I have created an OpenJDK negative test that confirms the closed >>>>>>>> source files are not included in the SOURCE. >>>>>>>> >>>>>>>> Version of the actual test for review: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ >>>>>>>> >>>>>>>> Any comments/suggestions are welcome, also I will need a sponsor >>>>>>>> for it at the end? >>>>>>>> >>>>>>>> Randy >>>>>>>> >>>>>>> >>>>> >>> > From ted at tedneward.com Thu Dec 21 22:49:06 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 21 Dec 2017 14:49:06 -0800 Subject: Another question, if I may? In-Reply-To: <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com> References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com> Message-ID: <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com> What I mean is, I do a "make hotspot", and the resulting change doesn't seem to be recognized when I run the code--doing a "java -XX:+PrintTedMessage -version" yields the "Unrecognized flag" error. (I added a simple fprintf() to part of the JVM startup code to print out the message, just to prove the flag was recognized and parsed.) Does that make more sense? I'm not trying to use the new VM as part of the build process--just add a flag to a VM that I can trigger when I run "java -version". I would've thought that "make hotspot" would compile the flag into the libjvm.so, and then drop the newly-built libjvm into the image directory, so that I wouldn't have to do a full build. Presumably, then, "make images" checks dependencies and doesn't build stuff that isn't affected by the change? (Otherwise, that would seem like a TON of build time for a fairly minimal change.) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 ?On 12/21/17, 4:20 AM, "David Holmes" wrote: On 21/12/2017 8:15 PM, Erik Joelsson wrote: > Adding hotspot-dev. > > /Erik > > > On 2017-12-21 10:43, Ted Neward wrote: >> What?s the steps necessary to add a new -XX flag? I?d assumed >> (naively) that all that was required was to add it to the list of >> macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag Yes that should suffice. >> (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets >> kicked back out with the ?Unrecognized flag; did you mean??? error. Why would "make hotspot" be using your new flag? Are you trying to apply your flag to the newly built VM during the build process? I'm not even sure if "make hotspot" would use the new VM. I always do a full build: make images David >> >> >> Is there something I?m missing? Does the flag need to be registered >> someplace else as well? >> >> >> Ted Neward >> >> Author, Speaker, Mentor >> >> http://www.newardassociates.com >> >> t: @tedneward | m: (425) 647-4526 >> > From david.holmes at oracle.com Fri Dec 22 00:06:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Dec 2017 10:06:34 +1000 Subject: Another question, if I may? In-Reply-To: <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com> References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com> <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com> Message-ID: <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com> On 22/12/2017 8:49 AM, Ted Neward wrote: > What I mean is, I do a "make hotspot", and the resulting change doesn't seem to be recognized when I run the code--doing a "java -XX:+PrintTedMessage -version" yields the "Unrecognized flag" error. (I added a simple fprintf() to part of the JVM startup code to print out the message, just to prove the flag was recognized and parsed.) Does that make more sense? I'm not trying to use the new VM as part of the build process--just add a flag to a VM that I can trigger when I run "java -version". > > I would've thought that "make hotspot" would compile the flag into the libjvm.so, and then drop the newly-built libjvm into the image directory, so that I wouldn't have to do a full build. Presumably, then, "make images" checks dependencies and doesn't build stuff that isn't affected by the change? (Otherwise, that would seem like a TON of build time for a fairly minimal change.) "make hotspot" won't update the image, you need to "make images" for that. Assuming you're building 9+ then when you change libjvm.so the module needs to be rebuilt etc. Or you can work from the exploded build the contents of e.g. build/linux-x64-debug/jdk/ though you still need a full build to prime that. But after that "make hotspot" should suffice. (Erik correct me if I'm wrong here please.) BTW there are three preexisting diagnostic flags that can be used to avoid adding your own: UseNewCode, UseNewCode2, UseNewCode3 HTH, David > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > ?On 12/21/17, 4:20 AM, "David Holmes" wrote: > > On 21/12/2017 8:15 PM, Erik Joelsson wrote: > > Adding hotspot-dev. > > > > /Erik > > > > > > On 2017-12-21 10:43, Ted Neward wrote: > >> What?s the steps necessary to add a new -XX flag? I?d assumed > >> (naively) that all that was required was to add it to the list of > >> macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag > > Yes that should suffice. > > >> (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets > >> kicked back out with the ?Unrecognized flag; did you mean??? error. > > Why would "make hotspot" be using your new flag? Are you trying to apply > your flag to the newly built VM during the build process? I'm not even > sure if "make hotspot" would use the new VM. I always do a full build: > make images > > David > > >> > >> > >> Is there something I?m missing? Does the flag need to be registered > >> someplace else as well? > >> > >> > >> Ted Neward > >> > >> Author, Speaker, Mentor > >> > >> http://www.newardassociates.com > >> > >> t: @tedneward | m: (425) 647-4526 > >> > > > > > From erik.joelsson at oracle.com Fri Dec 22 08:32:03 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Dec 2017 09:32:03 +0100 Subject: Another question, if I may? In-Reply-To: <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com> References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com> <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com> <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com> Message-ID: <385762d8-6714-29d9-0082-0316ddb2f0ff@oracle.com> On 2017-12-22 01:06, David Holmes wrote: > > "make hotspot" won't update the image, you need to "make images" for > that. > > Assuming you're building 9+ then when you change libjvm.so the module > needs to be rebuilt etc. > > Or you can work from the exploded build the contents of e.g. > > ?build/linux-x64-debug/jdk/ > > though you still need a full build to prime that. But after that "make > hotspot" should suffice. (Erik correct me if I'm wrong here please.) This is correct. Using the exploded image as described is the shortcut we have. The actual images are always built using jmod/jlink and yes, that requires quite a bit of extra build time. If you are in JDK 8, you need to run "make jdk" to get the exploded image updated with the new libjvm.so. /Erik From volker.simonis at gmail.com Fri Dec 22 16:24:45 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Dec 2017 17:24:45 +0100 Subject: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad In-Reply-To: References: <6838c67f5a7f44c0a48a79e8ac47e889@sap.com> Message-ID: Hi Martin, I've just pushed the fix to jdk8u/jdk8u-dev [1] so it should be in the next regular 8u update (probably 8u172 ?). You can of course test it any time by building the tip of http://hg.openjdk.java.net/jdk8u/jdk8u-dev yourself :) Merry Christmas and a happy new year, Volker [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/def07b5ce3be On Wed, Dec 20, 2017 at 11:18 AM, Evans, Martin wrote: > Many thanks guys, I look forward to testing. > > Regards, > > Martin > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: 20 December 2017 09:33 > To: Baesken, Matthias > Cc: jdk8u-dev-request at openjdk.java.net; core-libs-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; Evans, Martin ; build-dev > Subject: Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad > > Hi Matthias, > > the change looks good! > I can sponsor it once we get the approval. > > Also forwarded to buil-dev for the minimal build change. > > Thank you and best regards, > Volker > > > On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias wrote: >> Hello , Mark reported this issue on AIX with OpenJDK8 : >> >>> >>>I'm getting an unsatisfied link error when using logstash on AIX but I suspect the issue is with AIX or the JRE, the exception is: >>> >>> java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()D >>> getProcessCpuLoad at sun/management/OperatingSystemImpl.java:-2 >>> at org/logstash/instrument/monitors/ProcessMonitor.java:40 >>> detect at org/logstash/instrument/monitors/ProcessMonitor.java:79 >>> generate at >>> org/logstash/instrument/reports/ProcessReport.java:15 >>> >>> this is the line in logstash: >>> >>> this.cpuProcessPercent = >>> scaleLoadToPercent(unixOsBean.getProcessCpuLoad()); >>> >>> https://github.com/elastic/logstash/blob/master/logstash-core/src/mai >>> n/java/org/logstash/instrument/monitors/ProcessMonitor.java >>> >>> >>> Could anybody help steer me in the right direction? >>> >> >> This fix addresses the missing getSystemCpuLoad and getProcessCpuLoad on AIX . >> JDK8 is only affected , JDK9 and higher is not affected . >> >> Could I get a review for this change ? >> >> >> Change : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8193807/ >> >> Bug : >> >> https://bugs.openjdk.java.net/browse/JDK-8193807 >> >> >> Thanks, Matthias > ------------ Kingfisher plc Registered Office: 3 Sheldon Square, Paddington, London W2 6PX Registered in England, Number 1664812 This e-mail is only intended for the person(s) to whom it is addressed and may contain confidential information. Unless stated to the contrary, any opinions or comments are personal to the writer and do not represent the official view of the company. If you have received this e-mail in error, please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person. Thank you for your co-operation. From aph at redhat.com Sat Dec 23 11:25:17 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 23 Dec 2017 11:25:17 +0000 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> Message-ID: <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> On 20/12/17 09:54, Volker Simonis wrote: > Yes, that's exactly the issue. And it was communicated to the OpenJDK > Governing Board more than two and a half years ago (see my mail > "Providing 'hsdis' binaries not possible because of GPLv2/GPLv3 > license clash" from May 2015 [1]) and since then reiterated several > times. I'll plan to raise this issue again at the public GB meeting at > FOSDEM in February next year - however with very little hope that it > will be resolved :( How can the GB resolve it? I can't think of anything we can do. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Sat Dec 23 17:02:33 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 23 Dec 2017 17:02:33 +0000 Subject: Building hsdis? In-Reply-To: <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> Message-ID: Andrew Haley schrieb am Sa. 23. Dez. 2017 um 12:25: > On 20/12/17 09:54, Volker Simonis wrote: > > Yes, that's exactly the issue. And it was communicated to the OpenJDK > > Governing Board more than two and a half years ago (see my mail > > "Providing 'hsdis' binaries not possible because of GPLv2/GPLv3 > > license clash" from May 2015 [1]) and since then reiterated several > > times. I'll plan to raise this issue again at the public GB meeting at > > FOSDEM in February next year - however with very little hope that it > > will be resolved :( > > How can the GB resolve it? I can't think of anything we can do. > The GB obviously can not solve it directly in the same way it can not solve the (still existing) inability to push HotSpot changes or to finally create a Vulnerability Group. But it can acknowledge the problem and try to put some pressure on Oracle in order to work on and resolve the problem with a higher priority. If a part of the OpenJDK is practically unusable because of licensing issues I consider this inherently unhealthy. From my understanding it is the GB which is responsible to ?oversees the structure, operation, and overall health of the OpenJDK?. Who else if not the GB should be qualified to work on resolving it? [1] http://openjdk.java.net/groups/gb/ > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD > 6035 332F A671 > From aph at redhat.com Sun Dec 24 08:27:44 2017 From: aph at redhat.com (Andrew Haley) Date: Sun, 24 Dec 2017 08:27:44 +0000 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> Message-ID: <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> On 23/12/17 17:02, Volker Simonis wrote: > Andrew Haley schrieb am Sa. 23. Dez. 2017 um 12:25: > >> On 20/12/17 09:54, Volker Simonis wrote: >>> Yes, that's exactly the issue. And it was communicated to the OpenJDK >>> Governing Board more than two and a half years ago (see my mail >>> "Providing 'hsdis' binaries not possible because of GPLv2/GPLv3 >>> license clash" from May 2015 [1]) and since then reiterated several >>> times. I'll plan to raise this issue again at the public GB meeting at >>> FOSDEM in February next year - however with very little hope that it >>> will be resolved :( >> >> How can the GB resolve it? I can't think of anything we can do. > > The GB obviously can not solve it directly in the same way it can not solve > the (still existing) inability to push HotSpot changes or to finally create > a Vulnerability Group. > > But it can acknowledge the problem and try to put some pressure on Oracle > in order to work on and resolve the problem with a higher priority. Such as what, exactly? Please propose something. > If a part of the OpenJDK is practically unusable because of licensing > issues I consider this inherently unhealthy. From my understanding it is > the GB which is responsible to ?oversees the structure, operation, and > overall health of the OpenJDK?. Who else if not the GB should be qualified > to work on resolving it? > > [1] http://openjdk.java.net/groups/gb/ The GB can only solve problems which, in principle, can be solved. I know of no reasonable way to solve this one. There are some extreme solutions, such as re-licensing all of HotSpot, but that seems disproportionate. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ted at tedneward.com Sun Dec 24 11:01:17 2017 From: ted at tedneward.com (Ted Neward) Date: Sun, 24 Dec 2017 03:01:17 -0800 Subject: Another question, if I may? In-Reply-To: <385762d8-6714-29d9-0082-0316ddb2f0ff@oracle.com> References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com> <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com> <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com> <385762d8-6714-29d9-0082-0316ddb2f0ff@oracle.com> Message-ID: <98191FCC-06DC-49F9-8464-78B045A65F85@tedneward.com> So if I do a "make hotspot" it replaces the compiled Hotspot binary in the exploded build image? The reason I ask is that this is what I tried, and it didn?t appear to show up in the list of "PrintFlagsFinal" output. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 ?On 12/22/17, 12:32 AM, "Erik Joelsson" wrote: On 2017-12-22 01:06, David Holmes wrote: > > "make hotspot" won't update the image, you need to "make images" for > that. > > Assuming you're building 9+ then when you change libjvm.so the module > needs to be rebuilt etc. > > Or you can work from the exploded build the contents of e.g. > > build/linux-x64-debug/jdk/ > > though you still need a full build to prime that. But after that "make > hotspot" should suffice. (Erik correct me if I'm wrong here please.) This is correct. Using the exploded image as described is the shortcut we have. The actual images are always built using jmod/jlink and yes, that requires quite a bit of extra build time. If you are in JDK 8, you need to run "make jdk" to get the exploded image updated with the new libjvm.so. /Erik From volker.simonis at gmail.com Sun Dec 24 12:16:47 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 24 Dec 2017 12:16:47 +0000 Subject: Building hsdis? In-Reply-To: <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> Message-ID: Andrew Haley schrieb am So. 24. Dez. 2017 um 09:27: > On 23/12/17 17:02, Volker Simonis wrote: > > Andrew Haley schrieb am Sa. 23. Dez. 2017 um 12:25: > > > >> On 20/12/17 09:54, Volker Simonis wrote: > >>> Yes, that's exactly the issue. And it was communicated to the OpenJDK > >>> Governing Board more than two and a half years ago (see my mail > >>> "Providing 'hsdis' binaries not possible because of GPLv2/GPLv3 > >>> license clash" from May 2015 [1]) and since then reiterated several > >>> times. I'll plan to raise this issue again at the public GB meeting at > >>> FOSDEM in February next year - however with very little hope that it > >>> will be resolved :( > >> > >> How can the GB resolve it? I can't think of anything we can do. > > > > The GB obviously can not solve it directly in the same way it can not > solve > > the (still existing) inability to push HotSpot changes or to finally > create > > a Vulnerability Group. > > > > But it can acknowledge the problem and try to put some pressure on Oracle > > in order to work on and resolve the problem with a higher priority. > > Such as what, exactly? Please propose something. > > > If a part of the OpenJDK is practically unusable because of licensing > > issues I consider this inherently unhealthy. From my understanding it is > > the GB which is responsible to ?oversees the structure, operation, and > > overall health of the OpenJDK?. Who else if not the GB should be > qualified > > to work on resolving it? > > > > [1] http://openjdk.java.net/groups/gb/ > > The GB can only solve problems which, in principle, can be solved. I > know of no reasonable way to solve this one. There are some extreme > solutions, such as re-licensing all of HotSpot, but that seems > disproportionate. There?a no need for any ?extreme? solutions here. We?re speaking about 2 (in words ?two?) files (i.e. src/utils/hsdis/hsdis.{c,h}) which are neither part of the normal build nor part of any OpenJDK distribution. You have to call the Makefile under src/utils/hsdis/ manually in order to build hsdis.so. But this links in a part of the GNU binutils (which has been relicensed to GPLv3) into the generated shared library. So currently, everybody who builds hsdis violates the GNU license because he combines GPLv2 with GPLv3 code. I simply don?t understand what?s so complicated in relicensing these two hsdis.{c,h} files to GPLv3? Just to stress it one more time: they are NOT part of the HotSpot or the JDK. They are just a tool which can be used to anslyze some HotSpot internals. We could of course reimplement the hsdis functionality in an independent project outside of the OpenJDK, but that would be indeed an ?extrem? solution for a trivial problem. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From neugens.limasoftware at gmail.com Sun Dec 24 22:22:23 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 24 Dec 2017 22:22:23 +0000 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> Message-ID: > builds hsdis violates the GNU license because he > combines GPLv2 with GPLv3 code Are those files GPL 2 only or ?at your option any later version? too? Indeed, GPL v2 and v3 are not compatible, but if the upgradability is allowed then the effective version is already 3. The rest of the openjdk code is v2 only afaik though. Cheers, Mario On Sun 24. Dec 2017 at 13:17, Volker Simonis wrote: > Andrew Haley schrieb am So. 24. Dez. 2017 um 09:27: > > > On 23/12/17 17:02, Volker Simonis wrote: > > > Andrew Haley schrieb am Sa. 23. Dez. 2017 um 12:25: > > > > > >> On 20/12/17 09:54, Volker Simonis wrote: > > >>> Yes, that's exactly the issue. And it was communicated to the OpenJDK > > >>> Governing Board more than two and a half years ago (see my mail > > >>> "Providing 'hsdis' binaries not possible because of GPLv2/GPLv3 > > >>> license clash" from May 2015 [1]) and since then reiterated several > > >>> times. I'll plan to raise this issue again at the public GB meeting > at > > >>> FOSDEM in February next year - however with very little hope that it > > >>> will be resolved :( > > >> > > >> How can the GB resolve it? I can't think of anything we can do. > > > > > > The GB obviously can not solve it directly in the same way it can not > > solve > > > the (still existing) inability to push HotSpot changes or to finally > > create > > > a Vulnerability Group. > > > > > > But it can acknowledge the problem and try to put some pressure on > Oracle > > > in order to work on and resolve the problem with a higher priority. > > > > Such as what, exactly? Please propose something. > > > > > If a part of the OpenJDK is practically unusable because of licensing > > > issues I consider this inherently unhealthy. From my understanding it > is > > > the GB which is responsible to ?oversees the structure, operation, and > > > overall health of the OpenJDK?. Who else if not the GB should be > > qualified > > > to work on resolving it? > > > > > > [1] http://openjdk.java.net/groups/gb/ > > > > The GB can only solve problems which, in principle, can be solved. I > > know of no reasonable way to solve this one. There are some extreme > > solutions, such as re-licensing all of HotSpot, but that seems > > disproportionate. > > > There?a no need for any ?extreme? solutions here. We?re speaking about 2 > (in words ?two?) files (i.e. src/utils/hsdis/hsdis.{c,h}) which are neither > part of the normal build nor part of any OpenJDK distribution. You have to > call the Makefile under src/utils/hsdis/ manually in order to build > hsdis.so. But this links in a part of the GNU binutils (which has been > relicensed to GPLv3) into the generated shared library. So currently, > everybody who builds hsdis violates the GNU license because he combines > GPLv2 with GPLv3 code. > > I simply don?t understand what?s so complicated in relicensing these two > hsdis.{c,h} files to GPLv3? Just to stress it one more time: they are NOT > part of the HotSpot or the JDK. They are just a tool which can be used to > anslyze some HotSpot internals. > > We could of course reimplement the hsdis functionality in an independent > project outside of the OpenJDK, but that would be indeed an ?extrem? > solution for a trivial problem. > > > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > From volker.simonis at gmail.com Mon Dec 25 09:38:15 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Dec 2017 10:38:15 +0100 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> Message-ID: On Sun, Dec 24, 2017 at 11:22 PM, Mario Torre wrote: >> builds hsdis violates the GNU license because he >> combines GPLv2 with GPLv3 code > > Are those files GPL 2 only or ?at your option any later version? too? > They are GPLv2 only, otherwise there wouldn't be a problem. > Indeed, GPL v2 and v3 are not compatible, but if the upgradability is > allowed then the effective version is already 3. The rest of the openjdk > code is v2 only afaik though. > > Cheers, > Mario > > On Sun 24. Dec 2017 at 13:17, Volker Simonis > wrote: >> >> Andrew Haley schrieb am So. 24. Dez. 2017 um 09:27: >> >> > On 23/12/17 17:02, Volker Simonis wrote: >> > > Andrew Haley schrieb am Sa. 23. Dez. 2017 um 12:25: >> > > >> > >> On 20/12/17 09:54, Volker Simonis wrote: >> > >>> Yes, that's exactly the issue. And it was communicated to the >> > >>> OpenJDK >> > >>> Governing Board more than two and a half years ago (see my mail >> > >>> "Providing 'hsdis' binaries not possible because of GPLv2/GPLv3 >> > >>> license clash" from May 2015 [1]) and since then reiterated several >> > >>> times. I'll plan to raise this issue again at the public GB meeting >> > >>> at >> > >>> FOSDEM in February next year - however with very little hope that it >> > >>> will be resolved :( >> > >> >> > >> How can the GB resolve it? I can't think of anything we can do. >> > > >> > > The GB obviously can not solve it directly in the same way it can not >> > solve >> > > the (still existing) inability to push HotSpot changes or to finally >> > create >> > > a Vulnerability Group. >> > > >> > > But it can acknowledge the problem and try to put some pressure on >> > > Oracle >> > > in order to work on and resolve the problem with a higher priority. >> > >> > Such as what, exactly? Please propose something. >> > >> > > If a part of the OpenJDK is practically unusable because of licensing >> > > issues I consider this inherently unhealthy. From my understanding it >> > > is >> > > the GB which is responsible to ?oversees the structure, operation, and >> > > overall health of the OpenJDK?. Who else if not the GB should be >> > qualified >> > > to work on resolving it? >> > > >> > > [1] http://openjdk.java.net/groups/gb/ >> > >> > The GB can only solve problems which, in principle, can be solved. I >> > know of no reasonable way to solve this one. There are some extreme >> > solutions, such as re-licensing all of HotSpot, but that seems >> > disproportionate. >> >> >> There?a no need for any ?extreme? solutions here. We?re speaking about 2 >> (in words ?two?) files (i.e. src/utils/hsdis/hsdis.{c,h}) which are >> neither >> part of the normal build nor part of any OpenJDK distribution. You have to >> call the Makefile under src/utils/hsdis/ manually in order to build >> hsdis.so. But this links in a part of the GNU binutils (which has been >> relicensed to GPLv3) into the generated shared library. So currently, >> everybody who builds hsdis violates the GNU license because he combines >> GPLv2 with GPLv3 code. >> >> I simply don?t understand what?s so complicated in relicensing these two >> hsdis.{c,h} files to GPLv3? Just to stress it one more time: they are NOT >> part of the HotSpot or the JDK. They are just a tool which can be used to >> anslyze some HotSpot internals. >> >> We could of course reimplement the hsdis functionality in an independent >> project outside of the OpenJDK, but that would be indeed an ?extrem? >> solution for a trivial problem. >> >> >> > >> > -- >> > Andrew Haley >> > Java Platform Lead Engineer >> > Red Hat UK Ltd. >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> > From aph at redhat.com Mon Dec 25 22:58:44 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Dec 2017 22:58:44 +0000 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> Message-ID: <579a089e-fa6e-0262-0d38-b2f2631507bb@redhat.com> On 24/12/17 12:16, Volker Simonis wrote: > Andrew Haley schrieb am So. 24. Dez. 2017 um 09:27: > >> On 23/12/17 17:02, Volker Simonis wrote: >>> Andrew Haley schrieb am Sa. 23. Dez. 2017 um 12:25: >> >> The GB can only solve problems which, in principle, can be solved. I >> know of no reasonable way to solve this one. There are some extreme >> solutions, such as re-licensing all of HotSpot, but that seems >> disproportionate. > > There?a no need for any ?extreme? solutions here. We?re speaking about 2 > (in words ?two?) files (i.e. src/utils/hsdis/hsdis.{c,h}) which are neither > part of the normal build nor part of any OpenJDK distribution. You have to > call the Makefile under src/utils/hsdis/ manually in order to build > hsdis.so. But this links in a part of the GNU binutils (which has been > relicensed to GPLv3) into the generated shared library. So currently, > everybody who builds hsdis violates the GNU license because he combines > GPLv2 with GPLv3 code. > > I simply don?t understand what?s so complicated in relicensing these two > hsdis.{c,h} files to GPLv3? Just to stress it one more time: they are NOT > part of the HotSpot or the JDK. They are just a tool which can be used to > anslyze some HotSpot internals. IANAL, but AFAIK It would not help. The incompatibility is because you can't link pure GPLv2 code (HotSpot) and pure GPLv3 code (binutils) together, even via dynamic linkage. Changing the licences of hsdis.{c,h}) won't solve that problem. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Tue Dec 26 12:46:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Dec 2017 22:46:45 +1000 Subject: Another question, if I may? In-Reply-To: <98191FCC-06DC-49F9-8464-78B045A65F85@tedneward.com> References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com> <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com> <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com> <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com> <385762d8-6714-29d9-0082-0316ddb2f0ff@oracle.com> <98191FCC-06DC-49F9-8464-78B045A65F85@tedneward.com> Message-ID: <818b0d34-8007-a771-a277-e62fff4f5805@oracle.com> On 24/12/2017 9:01 PM, Ted Neward wrote: > So if I do a "make hotspot" it replaces the compiled Hotspot binary in the exploded build image? I believe so, but simplest thing is to do a find for libjvm.so before and after the "make hotspot" and see which one(s) changed. David > The reason I ask is that this is what I tried, and it didn?t appear to show up in the list of "PrintFlagsFinal" output. > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > ?On 12/22/17, 12:32 AM, "Erik Joelsson" wrote: > > > > On 2017-12-22 01:06, David Holmes wrote: > > > > "make hotspot" won't update the image, you need to "make images" for > > that. > > > > Assuming you're building 9+ then when you change libjvm.so the module > > needs to be rebuilt etc. > > > > Or you can work from the exploded build the contents of e.g. > > > > build/linux-x64-debug/jdk/ > > > > though you still need a full build to prime that. But after that "make > > hotspot" should suffice. (Erik correct me if I'm wrong here please.) > This is correct. Using the exploded image as described is the shortcut > we have. The actual images are always built using jmod/jlink and yes, > that requires quite a bit of extra build time. > > If you are in JDK 8, you need to run "make jdk" to get the exploded > image updated with the new libjvm.so. > > /Erik > > > From volker.simonis at gmail.com Wed Dec 27 11:26:33 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Dec 2017 12:26:33 +0100 Subject: Building hsdis? In-Reply-To: <579a089e-fa6e-0262-0d38-b2f2631507bb@redhat.com> References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> <579a089e-fa6e-0262-0d38-b2f2631507bb@redhat.com> Message-ID: On Mon, Dec 25, 2017 at 11:58 PM, Andrew Haley wrote: > On 24/12/17 12:16, Volker Simonis wrote: >> Andrew Haley schrieb am So. 24. Dez. 2017 um 09:27: >> >>> On 23/12/17 17:02, Volker Simonis wrote: >>>> Andrew Haley schrieb am Sa. 23. Dez. 2017 um 12:25: >>> >>> The GB can only solve problems which, in principle, can be solved. I >>> know of no reasonable way to solve this one. There are some extreme >>> solutions, such as re-licensing all of HotSpot, but that seems >>> disproportionate. >> >> There?a no need for any ?extreme? solutions here. We?re speaking about 2 >> (in words ?two?) files (i.e. src/utils/hsdis/hsdis.{c,h}) which are neither >> part of the normal build nor part of any OpenJDK distribution. You have to >> call the Makefile under src/utils/hsdis/ manually in order to build >> hsdis.so. But this links in a part of the GNU binutils (which has been >> relicensed to GPLv3) into the generated shared library. So currently, >> everybody who builds hsdis violates the GNU license because he combines >> GPLv2 with GPLv3 code. >> >> I simply don?t understand what?s so complicated in relicensing these two >> hsdis.{c,h} files to GPLv3? Just to stress it one more time: they are NOT >> part of the HotSpot or the JDK. They are just a tool which can be used to >> anslyze some HotSpot internals. > > IANAL, but AFAIK It would not help. The incompatibility is because > you can't link pure GPLv2 code (HotSpot) and pure GPLv3 code > (binutils) together, even via dynamic linkage. Changing the licences > of hsdis.{c,h}) won't solve that problem. > There are two different problems here: 1. It is not possible to build and redistribute hsdis.so because of GPLv2 and GPLv3 license incompatibilities. This problem could be easily solved by re-licensing hsdis.{c,h} under GPLv3. That would allow it to others (e.g. the AdoptOpenJD project) to provide pre-built version of hsdis.so for various platforms and versions of OpenJDK. This will be definitely of great benefit for the OpenJDK community, especially taking into account that many popular tools like JITwatch or JMH use or depend on hsdis. 2. The second problem is wether and when a program and its plug-ins are considered a single combined program. This is a long standing problem [1] and without being a lawyer (which is probably an advantage :) I'd consider the usage of hsdis a "borderline case" (because HotSpot and hsdis dont't share any complex, common data structures - they just pass a byte stream forth and back). But that's just my opinion. We can not easily solve or decide problem 2. But we can resolve the first problem and give everybody the freedom to decide question 2 for himself. Without resolving the first problem (i.e. re-licensing hsdis.{c,h} under GPLv3) most people won't even face problem two (if this is a problem at all) because they simply don't have a version of hsdis. Regards, Volker [1] https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Dec 28 10:48:20 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Dec 2017 10:48:20 +0000 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> <579a089e-fa6e-0262-0d38-b2f2631507bb@redhat.com> Message-ID: On 27/12/17 11:26, Volker Simonis wrote: > There are two different problems here: > > 1. It is not possible to build and redistribute hsdis.so because of > GPLv2 and GPLv3 license incompatibilities. > > This problem could be easily solved by re-licensing hsdis.{c,h} under > GPLv3. That would allow it to others (e.g. the AdoptOpenJD project) to > provide pre-built version of hsdis.so for various platforms and > versions of OpenJDK. This will be definitely of great benefit for the > OpenJDK community, especially taking into account that many popular > tools like JITwatch or JMH use or depend on hsdis. > > 2. The second problem is wether and when a program and its plug-ins > are considered a single combined program. > > This is a long standing problem [1] and without being a lawyer (which > is probably an advantage :) I'd consider the usage of hsdis a > "borderline case" (because HotSpot and hsdis dont't share any complex, > common data structures - they just pass a byte stream forth and back). > But that's just my opinion. Right, but there is substantial functionality which depends on binutils. > We can not easily solve or decide problem 2. But we can resolve the > first problem and give everybody the freedom to decide question 2 > for himself. I believe that anybody distributing the resulting hsdis.so would be on shaky legal ground. Maybe it'd work in some countries, not others, I don't know, but we shouldn't be trying to find clever schemes to evade the clear intent of the FSF, the binutils copyright owner. > Without resolving the first problem (i.e. re-licensing hsdis.{c,h} > under GPLv3) most people won't even face problem two (if this is a > problem at all) because they simply don't have a version of hsdis. We need to seek a better way to solve this problem. Neither of us are lawyers, but I don't like it, and I would be very reluctant to be involved with any organization trying to get past the FSF's copyright terms in this way. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Fri Dec 29 16:16:53 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Dec 2017 17:16:53 +0100 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> <579a089e-fa6e-0262-0d38-b2f2631507bb@redhat.com> Message-ID: On Thu, Dec 28, 2017 at 11:48 AM, Andrew Haley wrote: > On 27/12/17 11:26, Volker Simonis wrote: >> There are two different problems here: >> >> 1. It is not possible to build and redistribute hsdis.so because of >> GPLv2 and GPLv3 license incompatibilities. >> >> This problem could be easily solved by re-licensing hsdis.{c,h} under >> GPLv3. That would allow it to others (e.g. the AdoptOpenJD project) to >> provide pre-built version of hsdis.so for various platforms and >> versions of OpenJDK. This will be definitely of great benefit for the >> OpenJDK community, especially taking into account that many popular >> tools like JITwatch or JMH use or depend on hsdis. >> >> 2. The second problem is wether and when a program and its plug-ins >> are considered a single combined program. >> >> This is a long standing problem [1] and without being a lawyer (which >> is probably an advantage :) I'd consider the usage of hsdis a >> "borderline case" (because HotSpot and hsdis dont't share any complex, >> common data structures - they just pass a byte stream forth and back). >> But that's just my opinion. > > Right, but there is substantial functionality which depends on binutils. > >> We can not easily solve or decide problem 2. But we can resolve the >> first problem and give everybody the freedom to decide question 2 >> for himself. > > I believe that anybody distributing the resulting hsdis.so would be on > shaky legal ground. Maybe it'd work in some countries, not others, I > don't know, but we shouldn't be trying to find clever schemes to evade > the clear intent of the FSF, the binutils copyright owner. > >> Without resolving the first problem (i.e. re-licensing hsdis.{c,h} >> under GPLv3) most people won't even face problem two (if this is a >> problem at all) because they simply don't have a version of hsdis. > > We need to seek a better way to solve this problem. > > Neither of us are lawyers, but I don't like it, and I would be very > reluctant to be involved with any organization trying to get past > the FSF's copyright terms in this way. So than why aren't you reluctant about using hsdis itself? Or did you (or your co-workers) never ever used any hsdis version based on binutils > 2.17, released in June 2006 (small hint: aarch64 support was added in binutils 2.23 around 2012 and is entirely GPLv3). > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neugens.limasoftware at gmail.com Fri Dec 29 20:09:02 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 29 Dec 2017 21:09:02 +0100 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> <579a089e-fa6e-0262-0d38-b2f2631507bb@redhat.com> Message-ID: 2017-12-29 17:16 GMT+01:00 Volker Simonis : > So than why aren't you reluctant about using hsdis itself? Or did you > (or your co-workers) never ever used any hsdis version based on > binutils > 2.17, released in June 2006 (small hint: aarch64 support > was added in binutils 2.23 around 2012 and is entirely GPLv3). Personal use is not a problem though, redistribution to public is. That's not to suggest we shouldn't fix this of course. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From aph at redhat.com Sat Dec 30 09:19:37 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 30 Dec 2017 09:19:37 +0000 Subject: Building hsdis? In-Reply-To: References: <56EE18D3-2D9F-46FE-B674-C681D5BB0DA6@tedneward.com> <7D287DA6-CD4F-48F3-9597-2190A3828866@tedneward.com> <765bb1fa-e269-56ee-079c-52c1f51f08ed@oracle.com> <50b3f8d9-81fd-514d-3809-a073f0783c2b@oracle.com> <987ada1a-0809-0b7f-c55b-4e2f3a2825e5@redhat.com> <10f05185-0dc6-2fce-fa4c-d57e199ded5b@redhat.com> <579a089e-fa6e-0262-0d38-b2f2631507bb@redhat.com> Message-ID: <8116446c-e6d9-c1f2-44b1-8bf0bffb74a9@redhat.com> On 29/12/17 20:09, Mario Torre wrote: > 2017-12-29 17:16 GMT+01:00 Volker Simonis : > >> So than why aren't you reluctant about using hsdis itself? Or did you >> (or your co-workers) never ever used any hsdis version based on >> binutils > 2.17, released in June 2006 (small hint: aarch64 support >> was added in binutils 2.23 around 2012 and is entirely GPLv3). > > Personal use is not a problem though, redistribution to public is. > > That's not to suggest we shouldn't fix this of course. Sure, but let's hear some suggestions that don't require the end user to decide whether to use unlicensed software. We could write a disassembler ourselves, I suppose, but that seems a bit crazy. Maybe there is a disassembler out there with a licence that fits. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671