From erik.joelsson at oracle.com Mon Mar 2 08:27:50 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Mar 2015 09:27:50 +0100 Subject: RFR: JDK-8074048 : Upgrading to ccache 1.3.10 disables the use of ccache In-Reply-To: <54F10D3F.7040905@oracle.com> References: <54C7914B.1050408@oracle.com> <54CB5BC7.5020106@oracle.com> <54CB5F0B.3090004@oracle.com> <54CB621D.5090405@oracle.com> <54CB6491.5050001@oracle.com> <54D37EB7.80501@oracle.com> <54EFA379.1040701@oracle.com> <54F03640.9010206@oracle.com> <54F0A311.3090707@oracle.com> <54F0A60C.6070003@oracle.com> <54F10D3F.7040905@oracle.com> Message-ID: <54F41F06.2060700@oracle.com> Looks good to me. Thanks for fixing it! Please remember to run common/bin/autogen.sh and submit both the open and closed generated-configure.sh with this. Same bugid is fine. /Erik On 2015-02-28 01:35, Steven Loomis wrote: > Subject was wrong, this is a RFR on 8074048 > > On 2/27/2015 9:14 AM, Steven Loomis wrote: >> Bug:https://bugs.openjdk.java.net/browse/JDK-8074048 >> webrev: cr.openjdk.java.net has decided it doesn't like me, till it >> is fixed trivial change is below >> >> >> ---------------- >> >> --- old/common/autoconf/build-performance.m4 2015-02-27 >> 09:09:47.974447669 -0800 >> +++ new/common/autoconf/build-performance.m4 2015-02-27 >> 09:09:47.884403256 -0800 >> @@ -215,7 +215,7 @@ >> if test "x$CCACHE" != x; then >> if test "x$USE_PRECOMPILED_HEADER" = "x1"; then >> HAS_BAD_CCACHE=[`$ECHO $CCACHE_VERSION | \ >> - $GREP -e '^1.*' -e '^2.*' -e '^3\.0.*' -e '^3\.1\.[0123]'`] >> + $GREP -e '^1.*' -e '^2.*' -e '^3\.0.*' -e '^3\.1\.[0123]$'`] >> if test "x$HAS_BAD_CCACHE" != "x"; then >> AC_MSG_ERROR([Precompiled headers requires ccache 3.1.4 or >> later, found $CCACHE_VERSION]) >> fi >> --- old/common/autoconf/generated-configure.sh 2015-02-27 >> 09:09:48.373644566 -0800 >> +++ new/common/autoconf/generated-configure.sh 2015-02-27 >> 09:09:48.246581895 -0800 >> @@ -4393,7 +4393,7 @@ >> #CUSTOM_AUTOCONF_INCLUDE >> >> # Do not change or remove the following line, it is needed for >> consistency checks: >> -DATE_WHEN_GENERATED=1424202275 >> +DATE_WHEN_GENERATED=1424990238 >> >> ############################################################################### >> >> # >> @@ -51700,7 +51700,7 @@ >> if test "x$CCACHE" != x; then >> if test "x$USE_PRECOMPILED_HEADER" = "x1"; then >> HAS_BAD_CCACHE=`$ECHO $CCACHE_VERSION | \ >> - $GREP -e '^1.*' -e '^2.*' -e '^3\.0.*' -e '^3\.1\.[0123]'` >> + $GREP -e '^1.*' -e '^2.*' -e '^3\.0.*' -e '^3\.1\.[0123]$'` >> if test "x$HAS_BAD_CCACHE" != "x"; then >> as_fn_error $? "Precompiled headers requires ccache 3.1.4 or >> later, found $CCACHE_VERSION" "$LINENO" 5 >> fi >> --- old/closed/autoconf/generated-configure.sh 2015-02-27 >> 09:09:49.216060073 -0800 >> +++ new/closed/autoconf/generated-configure.sh 2015-02-27 >> 09:09:49.108006777 -0800 >> @@ -4717,7 +4717,7 @@ >> >> >> # Do not change or remove the following line, it is needed for >> consistency checks: >> -DATE_WHEN_GENERATED=1424202275 >> +DATE_WHEN_GENERATED=1424990238 >> >> ############################################################################### >> >> # >> @@ -52342,7 +52342,7 @@ >> if test "x$CCACHE" != x; then >> if test "x$USE_PRECOMPILED_HEADER" = "x1"; then >> HAS_BAD_CCACHE=`$ECHO $CCACHE_VERSION | \ >> - $GREP -e '^1.*' -e '^2.*' -e '^3\.0.*' -e '^3\.1\.[0123]'` >> + $GREP -e '^1.*' -e '^2.*' -e '^3\.0.*' -e '^3\.1\.[0123]$'` >> if test "x$HAS_BAD_CCACHE" != "x"; then >> as_fn_error $? "Precompiled headers requires ccache 3.1.4 or >> later, found $CCACHE_VERSION" "$LINENO" 5 >> fi > From erik.joelsson at oracle.com Mon Mar 2 08:29:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Mar 2015 09:29:57 +0100 Subject: RFR: JDK-8074055 Improvements in compare.sh from build-infra In-Reply-To: <54F0E0D4.8040209@oracle.com> References: <54F0E0D4.8040209@oracle.com> Message-ID: <54F41F85.2010609@oracle.com> Looks good to me. /Erik On 2015-02-27 22:25, Magnus Ihse Bursie wrote: > This is a few improvements of the compare.sh script, originally > targeted for JDK-8069064. It was forced to be left out at the last > moment to avoid costly merge conflicts. :-( > > Since then JDK-8073965 has modified compare.sh in somewhat the same > way, but not as complete. Inspired by the changes in JDK-8073965, I > improved it even further. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074055 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8074055-compare-from-build-infra/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Mar 2 08:34:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Mar 2015 09:34:40 +0100 Subject: RFR 8073596 : Add jdk.management.cmm in boot.modules that needs sun.management.spi be exported to it In-Reply-To: <54F0D9C2.8090306@oracle.com> References: <54F0D9C2.8090306@oracle.com> Message-ID: <54F420A0.4040702@oracle.com> Looks good to me. /Erik On 2015-02-27 21:55, Brent Christian wrote: > Hi, > > Please review a small update to the module config files for a new > jdk.management.cmm module. > > Webrev: http://cr.openjdk.java.net/~bchristi/8073596/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8073596 > > I also found a needed hook missing from Gensrc-java.management.gmk > > FWIW, Erik Joelsson and Magnus Ihse Bursie have already seen and > approved this build change. > > (Note that I am not on either of these aliases, so please include me > directly in any responses. :) > > Thanks, > -Brent From david.holmes at oracle.com Mon Mar 2 08:38:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 18:38:43 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> References: <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> <54EFD092.5090007@oracle.com> <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> Message-ID: <54F42193.3030700@oracle.com> On 28/02/2015 5:06 AM, Andrew Hughes wrote: > ----- Original Message ----- >> On 27/02/2015 11:25 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> >>>> On 26/02/2015 12:31 PM, David Holmes wrote: >>>>> On 26/02/2015 2:57 AM, Andrew Hughes wrote: >>>>>>>>> These are the revised versions of the webrevs: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ >>>>>>>>> >>>>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) >>>>>> >>>>>> Ok if I push the jdk and root parts then? I think someone on the Oracle >>>>>> HS team (David?) needs to push the HotSpot bit. >>>>> >>>>> Best to push it all together I think, which I can do through the hs-rt >>>>> forest. But first I need to see where things settled with all this :) I >>>>> was quite confused by some of the initial suggestions. Will try to get >>>>> to this today. >>> >>> Well, I'd push it all myself if there weren't still restrictions on pushing >>> to HotSpot... >>> >>>> >>>> I'm still very confused by these changes and have trouble tracking the >>>> values of the various "arch" related variables. If I follow this right >>>> presently the only distinction between ppc64 and ppc64le is the value of >>>> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the >>>> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 >>>> is either unused or only used by a hotspot-only build?) >>>> >>>> The desired change is that the top-level architecture (VAR_CPU which >>>> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that >>>> for hotspot the only difference is LIBARCH becomes ppc64le. So to >>>> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the >>>> current ppc; and then hotspot's def.make uses that combined with being >>>> lttle-endian to reset the LIBARCH to ppc64le. >>> >>> From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build >>> will get called with ARCH=ppc64le and fail, because make/defs.make will >>> set SRCARCH to x86 >> >> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from >> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to >> ppc as per current code. Then BUILDARCH will check LP64 and so become >> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le. >> > > Ah, not in 8 where this was tested: > > ARCH=$(OPENJDK_TARGET_CPU_LEGACY) > +# ppc64le uses the HotSpot ppc64 build > +ifeq ($(OPENJDK_TARGET_CPU), ppc64le) > + ARCH=ppc64 > +endif > > OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case. > > 9 changed this with: > > 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH > > So it looks like we're going to end up with three different patches for this issue. That explains all the confusion :) >> Yes but you can do it based on the value of LIBARCH rather than a >> modified ARCH. > > Yes, with 8046471 in place. Hardly a huge difference though. Avoiding the need to mess with what happens at the configure level in hoptspot-spec.gmk.in makes it a lot simpler to follow IMHO. >> I don't know if I already had this conversation but it strikes me as >> really bizarre that the PPC64 port uses two different ARCH values >> depending on whether it is a configure-based build or not! ??? >> > > It's not just that port. Every build either gets ARCH set by > hotspot-spec.gmk (by way of configure) or by uname -m in > make/linux/makefiles/defs.make. This is necessary if you're > going to allow someone to skip configure and just build HotSpot. It's not the two different mechanisms that I was referring to, but the fact that those mechanisms result in two completely different values for ARCH for the same port. This just piles complexity on top of complexity. > If no-one does that any more, then the old stuff that was needed > for 7 builds (no configure) could be culled. Eventually the hotspot build will be all configure based. Even now I'm not sure why people need to do a hotspot-only build this way rather than just running configure and "make hotspot-only". >> That aside if ARCH == ppc64 from uname then: >> - SRCARCH = ARCH/ppc64 = ppc >> - BUILDARCH = ppc64 >> >> and so the same fix as above would work for this case. >> > > It doesn't, as I said. It's ppc64le. So the uname override is necessary. > For consistency, it probably should now be overridden to be ppc, not > ppc64, given the value passed in from configure changed to that in > 8046471. Ok. Thanks, David ----- >>> so our addition to hotspot-spec.gmk is just to do the same as this >>> block for configure builds. >>> >>> It was unneeded before because configure would just set the arch >>> to ppc64 for the entire build, not just HotSpot. >> >> AFAICS it set it to ppc not ppc64. > > I was referring to: > > - VAR_CPU=ppc64 > + VAR_CPU=ppc64le > > and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH. > >> >> David >> ----- >> >> >>>> Thanks, >>>> David >>>> >>>> >>>> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why >>>> bother also doing the switcheroo in >>>> /common/autoconf/hotspot-spec.gmk.in when you could just do >>>> everything in hotspot/make/defs >>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>> >>> >> > From erik.joelsson at oracle.com Mon Mar 2 09:42:49 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Mar 2015 10:42:49 +0100 Subject: (urgent) RFR: JDK-8074072: Race condition in build since JDK-8072842 can cause failed builds on Solaris Message-ID: <54F43099.40605@oracle.com> Hello, A race condition, possibly leading to a failed build on Solaris, was introduced with JDK-8072842. Here is a fix adding the necessary dependencies to solve this for now, until the proper solution in JDK-8064808 can be fixed. The fix in Tools.gmk has long been needed, but happened to work because the first user of these tools used to be java.base-libs and no other native code could be compiled before it. Bug: https://bugs.openjdk.java.net/browse/JDK-8074072 Webrev: http://cr.openjdk.java.net/~erikj/8074072/webrev.01/ /Erik From erik.joelsson at oracle.com Mon Mar 2 11:03:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Mar 2015 12:03:03 +0100 Subject: RFR: JDK-8074091: Remove dead code from merge mistake in JavaCompilation.gmk Message-ID: <54F44367.6010408@oracle.com> Hello, In JavaCompilation.gmk, between the definitions of SetupArchive and add_file_to_copy, there is a partial block of code that looks like it shouldn't be there. It seems to be part of the moved SetupZipArchive and has most likely reappeared in JavaCompilation in a merge. The code snippet is definitely not used and should be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8074091 Patch: diff -r cc1ab909baf7 make/common/JavaCompilation.gmk --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -330,13 +330,7 @@ $1 += $$($1_JAR) endef - $1_SRC_EXCLUDES := $$(foreach i,$$($1_SRC),$$(addprefix $$i/,$$(addsuffix /%,$$($1_EXCLUDES)))) - ifneq ($$($1_EXCLUDE_FILES),) - # Cannot precompute ZIP_EXCLUDE_FILES as it is dependent on which src root is being - # zipped at the moment. - $1_SRC_EXCLUDE_FILES := $$(addprefix %, $$($1_EXCLUDE_FILES)) $$($1_EXCLUDE_FILES) - $1_ALL_SRCS := $$(filter-out $$($1_SRC_EXCLUDE_FILES), $$($1_ALL_SRCS)) - endif + define add_file_to_copy # param 1 = BUILD_MYPACKAGE # parma 2 = The source file to copy. /Erik From magnus.ihse.bursie at oracle.com Mon Mar 2 11:06:33 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 2 Mar 2015 12:06:33 +0100 Subject: RFR: JDK-8074072 Race condition in build since JDK-8072842 can cause failed builds on Solaris Message-ID: <34F7EE15-0F8E-44A9-B79C-D223E69DF6A7@oracle.com> A race condition, possibly leading to a failed build on Solaris, was introduced with JDK-8072842. The two Solaris helper script fix_empty_sec_hdr_flags and add_gnu_debuglink are built several times, in the same location. If we are unlucky then thread A does: A1: compile add_gnu_link.c A2: link add_gnu_link and thread B does: B1: compile add_gnu_link.c after A1 but before A2, so that when linking is about to start, the .o file has been truncated, and then linking will fail. A typical error message looks like this: Main.gmk:264: recipe for target 'build-test-hotspot-jtreg-native' failed ld: fatal: file /opt/jprt/T/P1/002839.magnusi/s/build/solaris-sparcv9-normal-server-release/buildtools/objs/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.o: not an ELF object ld: fatal: file processing errors. No output written to /opt/jprt/T/P1/002839.magnusi/s/build/solaris-sparcv9-normal-server-release/buildtools/bin/fix_empty_sec_hdr_flags gmake[3]: *** [/opt/jprt/T/P1/002839.magnusi/s/build/solaris-sparcv9-normal-server-release/buildtools/bin/fix_empty_sec_hdr_flags] Error 2 The proper long-term solution is to fix JDK-8064808. However, since this issue causes a build break, a quicker and less risky fix is to let build-test-*-jtreg-native depend on buildtools-jdk. It is by definition hard to test that a race condition has been resolved, but I have tried this at least a dozen times with no failures. https://bugs.openjdk.java.net/browse/JDK-8074072 Fix inline: diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -433,6 +433,10 @@ test-make: clean-test-make + build-test-hotspot-jtreg-native: buildtools-jdk + + build-test-jdk-jtreg-native: buildtools-jdk + test-image-hotspot-jtreg-native: build-test-hotspot-jtreg-native test-image-jdk-jtreg-native: build-test-jdk-jtreg-native /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 2 12:49:38 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 02 Mar 2015 13:49:38 +0100 Subject: (urgent) RFR: JDK-8074072: Race condition in build since JDK-8072842 can cause failed builds on Solaris In-Reply-To: <54F43099.40605@oracle.com> References: <54F43099.40605@oracle.com> Message-ID: <54F45C62.2080802@oracle.com> On 2015-03-02 10:42, Erik Joelsson wrote: > Hello, > > A race condition, possibly leading to a failed build on Solaris, was > introduced with JDK-8072842. Here is a fix adding the necessary > dependencies to solve this for now, until the proper solution in > JDK-8064808 can be fixed. > > The fix in Tools.gmk has long been needed, but happened to work > because the first user of these tools used to be java.base-libs and no > other native code could be compiled before it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074072 > Webrev: http://cr.openjdk.java.net/~erikj/8074072/webrev.01/ > > /Erik Looks like we had a race condition in the build team for fixing this as well. ;-) Your fix does indeed seem more complete; I assume I just got lucky perhaps by changing order. /Magnus From sgehwolf at redhat.com Mon Mar 2 16:06:32 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Mar 2015 17:06:32 +0100 Subject: [8u60] Request for approval to backport: 8067330: ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures Message-ID: <1425312392.3461.19.camel@redhat.com> Hi, I've sent this email before[1], but would like for this backport to get into 8u60 before it closes this month[2]. The patch in question only touches Zero make variables and should be fairly safe to backport. The patch is the same (modulo autogen.sh generation timestamp) as for JDK 9. I'd also please need a sponsor who can push this change for me. Thanks in advance! Original 9 bug: https://bugs.openjdk.java.net/browse/JDK-8067330 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.jdk8.01/ JDK 9 review thread: http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013895.html Please let me know if there is anything else I need to do. Cheers, Severin [1] http://mail.openjdk.java.net/pipermail/build-dev/2015-February/014394.html [2] http://openjdk.java.net/projects/jdk8u/releases/8u60.html From sean.coffey at oracle.com Mon Mar 2 16:56:21 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 02 Mar 2015 16:56:21 +0000 Subject: [8u60] Request for approval to backport: 8067330: ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures In-Reply-To: <1425312392.3461.19.camel@redhat.com> References: <1425312392.3461.19.camel@redhat.com> Message-ID: <54F49635.8060101@oracle.com> Hi Severin, I'd missed your previous request. It was marked as a review request! Consider this approved for jdk8u-dev. Can you add a 'noreg-build' label to the bug report ? Erik, would you be willing to push this changeset to the 8u-dev forest ? Looks like there's some closed code that needs updating also. regards, Sean. On 02/03/15 16:06, Severin Gehwolf wrote: > Hi, > > I've sent this email before[1], but would like for this backport to get > into 8u60 before it closes this month[2]. The patch in question only > touches Zero make variables and should be fairly safe to backport. The > patch is the same (modulo autogen.sh generation timestamp) as for JDK 9. > I'd also please need a sponsor who can push this change for me. > > Thanks in advance! > > Original 9 bug: https://bugs.openjdk.java.net/browse/JDK-8067330 > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.jdk8.01/ > > JDK 9 review thread: > http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013895.html > > Please let me know if there is anything else I need to do. > > Cheers, > Severin > > [1] > http://mail.openjdk.java.net/pipermail/build-dev/2015-February/014394.html > [2] http://openjdk.java.net/projects/jdk8u/releases/8u60.html > From sgehwolf at redhat.com Mon Mar 2 17:00:36 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Mar 2015 18:00:36 +0100 Subject: [8u60] Request for approval to backport: 8067330: ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures In-Reply-To: <54F49635.8060101@oracle.com> References: <1425312392.3461.19.camel@redhat.com> <54F49635.8060101@oracle.com> Message-ID: <1425315636.3461.28.camel@redhat.com> Hi, On Mon, 2015-03-02 at 16:56 +0000, Se?n Coffey wrote: > Hi Severin, > > I'd missed your previous request. It was marked as a review request! Sorry, my bad. > Consider this approved for jdk8u-dev. Can you add a 'noreg-build' label > to the bug report ? Done. > Erik, would you be willing to push this changeset to the 8u-dev forest > ? Looks like there's some closed code that needs updating also. Many thanks! Cheers, Severin > regards, > Sean. > > On 02/03/15 16:06, Severin Gehwolf wrote: > > Hi, > > > > I've sent this email before[1], but would like for this backport to get > > into 8u60 before it closes this month[2]. The patch in question only > > touches Zero make variables and should be fairly safe to backport. The > > patch is the same (modulo autogen.sh generation timestamp) as for JDK 9. > > I'd also please need a sponsor who can push this change for me. > > > > Thanks in advance! > > > > Original 9 bug: https://bugs.openjdk.java.net/browse/JDK-8067330 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.jdk8.01/ > > > > JDK 9 review thread: > > http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013895.html > > > > Please let me know if there is anything else I need to do. > > > > Cheers, > > Severin > > > > [1] > > http://mail.openjdk.java.net/pipermail/build-dev/2015-February/014394.html > > [2] http://openjdk.java.net/projects/jdk8u/releases/8u60.html > > > From steven.loomis at oracle.com Mon Mar 2 17:12:05 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Mon, 02 Mar 2015 09:12:05 -0800 Subject: RFR: JDK-8074048 : Upgrading to ccache 1.3.10 disables the use of ccache In-Reply-To: <54F10D3F.7040905@oracle.com> References: <54C7914B.1050408@oracle.com> <54CB5BC7.5020106@oracle.com> <54CB5F0B.3090004@oracle.com> <54CB621D.5090405@oracle.com> <54CB6491.5050001@oracle.com> <54D37EB7.80501@oracle.com> <54EFA379.1040701@oracle.com> <54F03640.9010206@oracle.com> <54F0A311.3090707@oracle.com> <54F0A60C.6070003@oracle.com> <54F10D3F.7040905@oracle.com> Message-ID: <54F499E5.5070807@oracle.com> updated webrev (on cr) Bug: https://bugs.openjdk.java.net/browse/JDK-8074048 webrev: http://cr.openjdk.java.net/~srl/8074048/webrev.01/ From brent.christian at oracle.com Mon Mar 2 20:24:29 2015 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 02 Mar 2015 12:24:29 -0800 Subject: RFR 8073596 : Add jdk.management.cmm in boot.modules that needs sun.management.spi be exported to it In-Reply-To: <54F187E9.5070500@oracle.com> References: <54F0D9C2.8090306@oracle.com> <54F187E9.5070500@oracle.com> Message-ID: <54F4C6FD.9000506@oracle.com> On 2/28/15 1:18 AM, Alan Bateman wrote: > Just a minor comment, we've been keeping the *.modules files in sorted > order. Not a big deal but would be good to continue that if you can. Will do. Thanks, Alan -Brent From erik.joelsson at oracle.com Tue Mar 3 09:12:31 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Mar 2015 10:12:31 +0100 Subject: [8u60] Request for approval to backport: 8067330: ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures In-Reply-To: <54F49635.8060101@oracle.com> References: <1425312392.3461.19.camel@redhat.com> <54F49635.8060101@oracle.com> Message-ID: <54F57AFF.70508@oracle.com> Sure, I can do it. /Erik On 2015-03-02 17:56, Se?n Coffey wrote: > Hi Severin, > > I'd missed your previous request. It was marked as a review request! > Consider this approved for jdk8u-dev. Can you add a 'noreg-build' > label to the bug report ? > > Erik, would you be willing to push this changeset to the 8u-dev > forest ? Looks like there's some closed code that needs updating also. > > regards, > Sean. > > On 02/03/15 16:06, Severin Gehwolf wrote: >> Hi, >> >> I've sent this email before[1], but would like for this backport to get >> into 8u60 before it closes this month[2]. The patch in question only >> touches Zero make variables and should be fairly safe to backport. The >> patch is the same (modulo autogen.sh generation timestamp) as for JDK 9. >> I'd also please need a sponsor who can push this change for me. >> >> Thanks in advance! >> >> Original 9 bug: https://bugs.openjdk.java.net/browse/JDK-8067330 >> webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.jdk8.01/ >> >> JDK 9 review thread: >> http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013895.html >> >> >> Please let me know if there is anything else I need to do. >> >> Cheers, >> Severin >> >> [1] >> http://mail.openjdk.java.net/pipermail/build-dev/2015-February/014394.html >> >> [2] http://openjdk.java.net/projects/jdk8u/releases/8u60.html >> > From erik.joelsson at oracle.com Tue Mar 3 09:14:01 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Mar 2015 10:14:01 +0100 Subject: RFR: JDK-8074048 : Upgrading to ccache 1.3.10 disables the use of ccache In-Reply-To: <54F499E5.5070807@oracle.com> References: <54C7914B.1050408@oracle.com> <54CB5BC7.5020106@oracle.com> <54CB5F0B.3090004@oracle.com> <54CB621D.5090405@oracle.com> <54CB6491.5050001@oracle.com> <54D37EB7.80501@oracle.com> <54EFA379.1040701@oracle.com> <54F03640.9010206@oracle.com> <54F0A311.3090707@oracle.com> <54F0A60C.6070003@oracle.com> <54F10D3F.7040905@oracle.com> <54F499E5.5070807@oracle.com> Message-ID: <54F57B59.60807@oracle.com> Still looks good. (We usually skip the generated-configure in the review since it's generated and quite large, at least if we remember to) /Erik On 2015-03-02 18:12, Steven Loomis wrote: > updated webrev (on cr) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074048 > webrev: http://cr.openjdk.java.net/~srl/8074048/webrev.01/ > From erik.joelsson at oracle.com Tue Mar 3 11:17:12 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Mar 2015 12:17:12 +0100 Subject: RFR: 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <20150302123112.GB11414@e6430> References: <20141127012617.GA17122@e6430> <20141204155932.GC28610@e6430> <20141211104528.GA18525@e6430> <20141215224906.GB6858@e6430> <20150212215046.GA6527@e6430> <20150301111554.GC3466@e6430> <54F42292.8080708@oracle.com> <20150302123112.GB11414@e6430> Message-ID: <54F59838.1040405@oracle.com> Hello, Here is my suggestion for makefile changes to go with the sjavac changes. Adding build-dev to get review for my part. Webrev: http://cr.openjdk.java.net/~erikj/8054717/webrev.root.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8054717 /Erik On 2015-03-02 13:31, Andreas Lundblad wrote: > On Mon, Mar 02, 2015 at 09:42:58AM +0100, Erik Joelsson wrote: >> Sounds good to me. So you think I should do the makefile changes to >> adapt the JDK build to this patch in a separate bug? > I'm not sure what's best, but I don't think we need a separate bug-entry. > > If you give me a pointer (or patch) on how to create/clean up a dummy empty bootclasspath directory, I can do the push. > > -- Andreas From erik.joelsson at oracle.com Tue Mar 3 11:53:33 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Mar 2015 12:53:33 +0100 Subject: RFR: 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <54F59838.1040405@oracle.com> References: <20141127012617.GA17122@e6430> <20141204155932.GC28610@e6430> <20141211104528.GA18525@e6430> <20141215224906.GB6858@e6430> <20150212215046.GA6527@e6430> <20150301111554.GC3466@e6430> <54F42292.8080708@oracle.com> <20150302123112.GB11414@e6430> <54F59838.1040405@oracle.com> Message-ID: <54F5A0BD.6060506@oracle.com> That combination didn't actually build for me. When compiling jdk.jconsole, the following happened: java.lang.RuntimeException: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for java.awt.datatransfer.UnsupportedFlavorException not found at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:143) at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:92) at com.sun.tools.sjavac.comp.SjavacImpl.compile(SjavacImpl.java:129) at com.sun.tools.sjavac.comp.PooledSjavac.lambda$compile$65(PooledSjavac.java:80) at com.sun.tools.sjavac.comp.PooledSjavac$$Lambda$4/703614162.call(Unknown Source) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for java.awt.datatransfer.UnsupportedFlavorException not found From what I can tell, jdk.jconsole uses java.desktop, which uses java.datatransfer (and re-exports it), where the missing class is. My best guess is that something in sjavac (API checking?) needs to traverse down into the transitive dependencies. This might be wrong, but as a workaround, it's easiest to fix in the makefiles so that we can have a working sjavac enabled jdk build. Here is an updated webrev which adds 3 levels (should cover everything I think) of transitive dependencies on the classpath when compiling modules: http://cr.openjdk.java.net/~erikj/8054717/webrev.root.02/ /Erik On 2015-03-03 12:17, Erik Joelsson wrote: > Hello, > > Here is my suggestion for makefile changes to go with the sjavac > changes. Adding build-dev to get review for my part. > > Webrev: http://cr.openjdk.java.net/~erikj/8054717/webrev.root.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8054717 > > /Erik > > On 2015-03-02 13:31, Andreas Lundblad wrote: >> On Mon, Mar 02, 2015 at 09:42:58AM +0100, Erik Joelsson wrote: >>> Sounds good to me. So you think I should do the makefile changes to >>> adapt the JDK build to this patch in a separate bug? >> I'm not sure what's best, but I don't think we need a separate >> bug-entry. >> >> If you give me a pointer (or patch) on how to create/clean up a dummy >> empty bootclasspath directory, I can do the push. >> >> -- Andreas > From magnus.ihse.bursie at oracle.com Tue Mar 3 12:01:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 03 Mar 2015 13:01:55 +0100 Subject: RFR: JDK-8074099 Even with toolchain type clang, OBJC is set to gcc Message-ID: <54F5A2B3.3090206@oracle.com> In configure, we use the "magic" AC_PROG_OBJC function to locate the compiler for Objective-C files. On the systems I tested, this returns gcc, even if we want to use clang (by setting --with-toolchain-type=clang). The following patch just sets OBJC to CC (that is, clang), if clang is selected as toolchain. Open question: Should we do the same for toolchain-type=gcc? I'm not quite sure what we're getting from calling the AC_PROG_OBJC macro, except perhaps a loss of transparency on how our tools are picked up. :-/ In fact, maybe we should just skip the OBJC variable completely. In fact, for Objective-C++ (.mm) files, we just use the normal C++ compiler. Bug: https://bugs.openjdk.java.net/browse/JDK-8074099 Patch inlined: diff --git a/common/autoconf/toolchain.m4 b/common/autoconf/toolchain.m4 --- a/common/autoconf/toolchain.m4 +++ b/common/autoconf/toolchain.m4 @@ -541,7 +541,13 @@ AC_DEFUN_ONCE([TOOLCHAIN_DETECT_TOOLCHAIN_EXTRA], [ if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then - AC_PROG_OBJC + if test "x$TOOLCHAIN_TYPE" = "xclang"; then + # Use clang for compiling Objective-C + OBJC="$CC" + AC_SUBST(OBJC) + else + AC_PROG_OBJC + fi BASIC_FIXUP_EXECUTABLE(OBJC) BASIC_PATH_PROGS(LIPO, lipo) BASIC_FIXUP_EXECUTABLE(LIPO) /Magnus From alexandr.scherbatiy at oracle.com Tue Mar 3 12:04:42 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 03 Mar 2015 15:04:42 +0300 Subject: Can't build demos on Windows 8.1 Message-ID: <54F5A35A.609@oracle.com> Hello, I installed Windows 8.1 and built JDK 9. When I call > make demos the whole JDK is rebuilt and demos are not created. The same is for > make java.desktop I do not see this problem on my Windows 7. Should I send any additional info or log files? I do not have idea what can be helpful in this case. Thanks, Alexandr. From magnus.ihse.bursie at oracle.com Tue Mar 3 12:46:56 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 03 Mar 2015 13:46:56 +0100 Subject: Can't build demos on Windows 8.1 In-Reply-To: <54F5A35A.609@oracle.com> References: <54F5A35A.609@oracle.com> Message-ID: <54F5AD40.2010805@oracle.com> On 2015-03-03 13:04, Alexander Scherbatiy wrote: > Hello, > > I installed Windows 8.1 and built JDK 9. > When I call > > make demos > the whole JDK is rebuilt and demos are not created. > > The same is for > > make java.desktop > > I do not see this problem on my Windows 7. > > Should I send any additional info or log files? I do not have idea > what can be helpful in this case. What happens then when you type "make java.desktop"? Is java.desktop not built? Are you using an updated version of cygwin? Is "make" your cygwin make? Without any logs (from e.g. configure and make) or more information, there's not much we can do to help. /Magnus From magnus.ihse.bursie at oracle.com Tue Mar 3 12:53:02 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 03 Mar 2015 13:53:02 +0100 Subject: RFR: 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <54F5A0BD.6060506@oracle.com> References: <20141127012617.GA17122@e6430> <20141204155932.GC28610@e6430> <20141211104528.GA18525@e6430> <20141215224906.GB6858@e6430> <20150212215046.GA6527@e6430> <20150301111554.GC3466@e6430> <54F42292.8080708@oracle.com> <20150302123112.GB11414@e6430> <54F59838.1040405@oracle.com> <54F5A0BD.6060506@oracle.com> Message-ID: <54F5AEAE.9070001@oracle.com> On 2015-03-03 12:53, Erik Joelsson wrote: > That combination didn't actually build for me. When compiling > jdk.jconsole, the following happened: > > java.lang.RuntimeException: > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for > java.awt.datatransfer.UnsupportedFlavorException not found > at > com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:143) > at > com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:92) > at com.sun.tools.sjavac.comp.SjavacImpl.compile(SjavacImpl.java:129) > at > com.sun.tools.sjavac.comp.PooledSjavac.lambda$compile$65(PooledSjavac.java:80) > at > com.sun.tools.sjavac.comp.PooledSjavac$$Lambda$4/703614162.call(Unknown Source) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class > file for java.awt.datatransfer.UnsupportedFlavorException not found > > From what I can tell, jdk.jconsole uses java.desktop, which uses > java.datatransfer (and re-exports it), where the missing class is. My > best guess is that something in sjavac (API checking?) needs to > traverse down into the transitive dependencies. This might be wrong, > but as a workaround, it's easiest to fix in the makefiles so that we > can have a working sjavac enabled jdk build. > > Here is an updated webrev which adds 3 levels (should cover everything > I think) of transitive dependencies on the classpath when compiling > modules: > > http://cr.openjdk.java.net/~erikj/8054717/webrev.root.02/ I'm not quite following this. This change affects the dependency calculation even when not using sjavac, right? Will that not cause any issues? What is the reasoning with the 3 levels? Is that the maximum depth currently in the JDK? Also, a minor nit, I thought we'd agreed to get rid of the $BUILD/tmp directory, and store intermediate build stuff in support or make-support. /Magnus From alexandr.scherbatiy at oracle.com Tue Mar 3 13:35:14 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 03 Mar 2015 16:35:14 +0300 Subject: Can't build demos on Windows 8.1 In-Reply-To: <54F5AD40.2010805@oracle.com> References: <54F5A35A.609@oracle.com> <54F5AD40.2010805@oracle.com> Message-ID: <54F5B892.4030708@oracle.com> On 3/3/2015 3:46 PM, Magnus Ihse Bursie wrote: > On 2015-03-03 13:04, Alexander Scherbatiy wrote: >> Hello, >> >> I installed Windows 8.1 and built JDK 9. >> When I call >> > make demos >> the whole JDK is rebuilt and demos are not created. >> >> The same is for >> > make java.desktop >> >> I do not see this problem on my Windows 7. >> >> Should I send any additional info or log files? I do not have idea >> what can be helpful in this case. Here is the log of the make demos command: http://cr.openjdk.java.net/~alexsch/logs/build/win8_1/make_java_demos.txt The demos are not built in my case. > > What happens then when you type "make java.desktop"? Is java.desktop > not built? It is built but longer than I expect. I tried to edit a cpp file only. Build process takes about 34 seconds on Windows 7 and about 2 minutes on Windows 8.1. make java.desktop log file on Windows 7: http://cr.openjdk.java.net/~alexsch/logs/build/win7/make_java_desktop.txt make java.desktop log file on Windows 8.1: http://cr.openjdk.java.net/~alexsch/logs/build/win8_1/make_java_desktop.txt > > Are you using an updated version of cygwin? I just installed the cygwin a week ago. I assume that it is the last version of the cygwin. > Is "make" your cygwin make? Yes. $ make --version GNU Make 4.1 Built for x86_64-unknown-cygwin Copyright (C) 1988-2014 Free Software Foundation, Inc. Thanks, Alexandr. > > Without any logs (from e.g. configure and make) or more information, > there's not much we can do to help. > > /Magnus From magnus.ihse.bursie at oracle.com Tue Mar 3 13:45:15 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 03 Mar 2015 14:45:15 +0100 Subject: RFR: JDK-8074099 Even with toolchain type clang, OBJC is set to gcc In-Reply-To: <54F5A2B3.3090206@oracle.com> References: <54F5A2B3.3090206@oracle.com> Message-ID: <54F5BAEB.70803@oracle.com> On 2015-03-03 13:01, Magnus Ihse Bursie wrote: > Open question: Should we do the same for toolchain-type=gcc? I'm not > quite sure what we're getting from calling the AC_PROG_OBJC macro, > except perhaps a loss of transparency on how our tools are picked up. > :-/ In fact, maybe we should just skip the OBJC variable completely. > In fact, for Objective-C++ (.mm) files, we just use the normal C++ > compiler. The more I think of it, the more I like this idea. Here's a new patch that does exactly this. WebRev: http://cr.openjdk.java.net/~ihse/JDK-8074099-remove-objc/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Mar 3 13:53:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 03 Mar 2015 14:53:05 +0100 Subject: Can't build demos on Windows 8.1 In-Reply-To: <54F5B892.4030708@oracle.com> References: <54F5A35A.609@oracle.com> <54F5AD40.2010805@oracle.com> <54F5B892.4030708@oracle.com> Message-ID: <54F5BCC1.4040103@oracle.com> On 2015-03-03 14:35, Alexander Scherbatiy wrote: > On 3/3/2015 3:46 PM, Magnus Ihse Bursie wrote: >> On 2015-03-03 13:04, Alexander Scherbatiy wrote: >>> Hello, >>> >>> I installed Windows 8.1 and built JDK 9. >>> When I call >>> > make demos >>> the whole JDK is rebuilt and demos are not created. >>> >>> The same is for >>> > make java.desktop >>> >>> I do not see this problem on my Windows 7. >>> >>> Should I send any additional info or log files? I do not have idea >>> what can be helpful in this case. > > Here is the log of the make demos command: > http://cr.openjdk.java.net/~alexsch/logs/build/win8_1/make_java_demos.txt > The demos are not built in my case. As a work-around, does "make demos-only" work OK? >> >> What happens then when you type "make java.desktop"? Is java.desktop >> not built? > It is built but longer than I expect. I tried to edit a cpp file > only. Build process takes about 34 seconds on Windows 7 and about 2 > minutes on Windows 8.1. > make java.desktop log file on Windows 7: > http://cr.openjdk.java.net/~alexsch/logs/build/win7/make_java_desktop.txt > make java.desktop log file on Windows 8.1: > http://cr.openjdk.java.net/~alexsch/logs/build/win8_1/make_java_desktop.txt It seems that on your Windows 8.1 machine the Java code is rebuilt as well, on top of the native code. I can't say for certain what causes this. Once again, as a work-around, try "make java.desktop-libs" or "make java.desktop-libs-only", to only recomplie the native parts of java.desktop. If you edit nothing, and run "make java.desktop" again on the win8.1 machine, do you get a rebuild of the java code again? (i.e. Do you see the line "Compiling 2525 files for java.desktop"?) Could you possibly have time skew issues? If the source code is timestamped in the future, then no rebuilds will ever make the resulting file look newer. /Magnus From erik.joelsson at oracle.com Tue Mar 3 13:52:50 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Mar 2015 14:52:50 +0100 Subject: Can't build demos on Windows 8.1 In-Reply-To: <54F5B892.4030708@oracle.com> References: <54F5A35A.609@oracle.com> <54F5AD40.2010805@oracle.com> <54F5B892.4030708@oracle.com> Message-ID: <54F5BCB2.5080702@oracle.com> On 2015-03-03 14:35, Alexander Scherbatiy wrote: > On 3/3/2015 3:46 PM, Magnus Ihse Bursie wrote: >> On 2015-03-03 13:04, Alexander Scherbatiy wrote: >>> Hello, >>> >>> I installed Windows 8.1 and built JDK 9. >>> When I call >>> > make demos >>> the whole JDK is rebuilt and demos are not created. >>> >>> The same is for >>> > make java.desktop >>> >>> I do not see this problem on my Windows 7. >>> >>> Should I send any additional info or log files? I do not have idea >>> what can be helpful in this case. > > Here is the log of the make demos command: > http://cr.openjdk.java.net/~alexsch/logs/build/win8_1/make_java_demos.txt > The demos are not built in my case. >> >> What happens then when you type "make java.desktop"? Is java.desktop >> not built? > It is built but longer than I expect. I tried to edit a cpp file > only. Build process takes about 34 seconds on Windows 7 and about 2 > minutes on Windows 8.1. > make java.desktop log file on Windows 7: > http://cr.openjdk.java.net/~alexsch/logs/build/win7/make_java_desktop.txt > make java.desktop log file on Windows 8.1: > http://cr.openjdk.java.net/~alexsch/logs/build/win8_1/make_java_desktop.txt It seems like the charset generation in gensrc gets rebuilt every time in your Windows 8.1 configuration. We had a bug causing that for a while last week. What are you synced against? /Erik >> >> Are you using an updated version of cygwin? > I just installed the cygwin a week ago. I assume that it is the > last version of the cygwin. >> Is "make" your cygwin make? > Yes. > $ make --version > GNU Make 4.1 > Built for x86_64-unknown-cygwin > Copyright (C) 1988-2014 Free Software Foundation, Inc. > > Thanks, > Alexandr. > >> >> Without any logs (from e.g. configure and make) or more information, >> there's not much we can do to help. >> >> /Magnus > From erik.joelsson at oracle.com Tue Mar 3 14:03:24 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Mar 2015 15:03:24 +0100 Subject: RFR: 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <54F5AEAE.9070001@oracle.com> References: <20141127012617.GA17122@e6430> <20141204155932.GC28610@e6430> <20141211104528.GA18525@e6430> <20141215224906.GB6858@e6430> <20150212215046.GA6527@e6430> <20150301111554.GC3466@e6430> <54F42292.8080708@oracle.com> <20150302123112.GB11414@e6430> <54F59838.1040405@oracle.com> <54F5A0BD.6060506@oracle.com> <54F5AEAE.9070001@oracle.com> Message-ID: <54F5BF2C.9000407@oracle.com> On 2015-03-03 13:53, Magnus Ihse Bursie wrote: > On 2015-03-03 12:53, Erik Joelsson wrote: >> That combination didn't actually build for me. When compiling >> jdk.jconsole, the following happened: >> >> java.lang.RuntimeException: >> com.sun.tools.javac.code.Symbol$CompletionFailure: class file for >> java.awt.datatransfer.UnsupportedFlavorException not found >> at >> com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:143) >> at >> com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:92) >> at com.sun.tools.sjavac.comp.SjavacImpl.compile(SjavacImpl.java:129) >> at >> com.sun.tools.sjavac.comp.PooledSjavac.lambda$compile$65(PooledSjavac.java:80) >> at >> com.sun.tools.sjavac.comp.PooledSjavac$$Lambda$4/703614162.call(Unknown >> Source) >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class >> file for java.awt.datatransfer.UnsupportedFlavorException not found >> >> From what I can tell, jdk.jconsole uses java.desktop, which uses >> java.datatransfer (and re-exports it), where the missing class is. My >> best guess is that something in sjavac (API checking?) needs to >> traverse down into the transitive dependencies. This might be wrong, >> but as a workaround, it's easiest to fix in the makefiles so that we >> can have a working sjavac enabled jdk build. >> >> Here is an updated webrev which adds 3 levels (should cover >> everything I think) of transitive dependencies on the classpath when >> compiling modules: >> >> http://cr.openjdk.java.net/~erikj/8054717/webrev.root.02/ > > I'm not quite following this. This change affects the dependency > calculation even when not using sjavac, right? Will that not cause any > issues? What is the reasoning with the 3 levels? Is that the maximum > depth currently in the JDK? > I changed this to only affect SJAVAC_ENABLED builds. The implementation of FindTransitiveDependenciesForModule was taken from another branch where I had already needed it for a different reason. There, 3 levels happened to be enough and applying this patch solved the problem with sjavac, so I took it as it was for now. > Also, a minor nit, I thought we'd agreed to get rid of the $BUILD/tmp > directory, and store intermediate build stuff in support or make-support. > Right, I moved it to support. New webrev: http://cr.openjdk.java.net/~erikj/8054717/webrev.root.03/ /Erik From magnus.ihse.bursie at oracle.com Tue Mar 3 14:07:53 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 03 Mar 2015 15:07:53 +0100 Subject: RFR: 8054717: SJavac should track changes in the public apis of classpath classes! In-Reply-To: <54F5BF2C.9000407@oracle.com> References: <20141127012617.GA17122@e6430> <20141204155932.GC28610@e6430> <20141211104528.GA18525@e6430> <20141215224906.GB6858@e6430> <20150212215046.GA6527@e6430> <20150301111554.GC3466@e6430> <54F42292.8080708@oracle.com> <20150302123112.GB11414@e6430> <54F59838.1040405@oracle.com> <54F5A0BD.6060506@oracle.com> <54F5AEAE.9070001@oracle.com> <54F5BF2C.9000407@oracle.com> Message-ID: <54F5C039.6010801@oracle.com> On 2015-03-03 15:03, Erik Joelsson wrote: > > On 2015-03-03 13:53, Magnus Ihse Bursie wrote: >> On 2015-03-03 12:53, Erik Joelsson wrote: >>> That combination didn't actually build for me. When compiling >>> jdk.jconsole, the following happened: >>> >>> java.lang.RuntimeException: >>> com.sun.tools.javac.code.Symbol$CompletionFailure: class file for >>> java.awt.datatransfer.UnsupportedFlavorException not found >>> at >>> com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:143) >>> at >>> com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:92) >>> at >>> com.sun.tools.sjavac.comp.SjavacImpl.compile(SjavacImpl.java:129) >>> at >>> com.sun.tools.sjavac.comp.PooledSjavac.lambda$compile$65(PooledSjavac.java:80) >>> at >>> com.sun.tools.sjavac.comp.PooledSjavac$$Lambda$4/703614162.call(Unknown >>> Source) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class >>> file for java.awt.datatransfer.UnsupportedFlavorException not found >>> >>> From what I can tell, jdk.jconsole uses java.desktop, which uses >>> java.datatransfer (and re-exports it), where the missing class is. >>> My best guess is that something in sjavac (API checking?) needs to >>> traverse down into the transitive dependencies. This might be wrong, >>> but as a workaround, it's easiest to fix in the makefiles so that we >>> can have a working sjavac enabled jdk build. >>> >>> Here is an updated webrev which adds 3 levels (should cover >>> everything I think) of transitive dependencies on the classpath when >>> compiling modules: >>> >>> http://cr.openjdk.java.net/~erikj/8054717/webrev.root.02/ >> >> I'm not quite following this. This change affects the dependency >> calculation even when not using sjavac, right? Will that not cause >> any issues? What is the reasoning with the 3 levels? Is that the >> maximum depth currently in the JDK? >> > I changed this to only affect SJAVAC_ENABLED builds. The > implementation of FindTransitiveDependenciesForModule was taken from > another branch where I had already needed it for a different reason. > There, 3 levels happened to be enough and applying this patch solved > the problem with sjavac, so I took it as it was for now. >> Also, a minor nit, I thought we'd agreed to get rid of the $BUILD/tmp >> directory, and store intermediate build stuff in support or >> make-support. >> > Right, I moved it to support. > > New webrev: http://cr.openjdk.java.net/~erikj/8054717/webrev.root.03/ Thanks. I'm happy now! :-) /Magnus From david.dehaven at oracle.com Tue Mar 3 17:46:13 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 3 Mar 2015 09:46:13 -0800 Subject: RFR: JDK-8074099 Even with toolchain type clang, OBJC is set to gcc In-Reply-To: <54F5BAEB.70803@oracle.com> References: <54F5A2B3.3090206@oracle.com> <54F5BAEB.70803@oracle.com> Message-ID: <501309FB-48F2-42BE-8A39-9F639EE66103@oracle.com> >> Open question: Should we do the same for toolchain-type=gcc? I'm not quite sure what we're getting from calling the AC_PROG_OBJC macro, except perhaps a loss of transparency on how our tools are picked up. :-/ In fact, maybe we should just skip the OBJC variable completely. In fact, for Objective-C++ (.mm) files, we just use the normal C++ compiler. > > The more I think of it, the more I like this idea. Here's a new patch that does exactly this. > > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8074099-remove-objc/webrev.01 That looks good to me. -DrD- From steven.loomis at oracle.com Tue Mar 3 18:28:09 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Tue, 03 Mar 2015 10:28:09 -0800 Subject: RFR: JDK-8074048 : Upgrading to ccache 1.3.10 disables the use of ccache In-Reply-To: <54F57B59.60807@oracle.com> References: <54C7914B.1050408@oracle.com> <54CB5BC7.5020106@oracle.com> <54CB5F0B.3090004@oracle.com> <54CB621D.5090405@oracle.com> <54CB6491.5050001@oracle.com> <54D37EB7.80501@oracle.com> <54EFA379.1040701@oracle.com> <54F03640.9010206@oracle.com> <54F0A311.3090707@oracle.com> <54F0A60C.6070003@oracle.com> <54F10D3F.7040905@oracle.com> <54F499E5.5070807@oracle.com> <54F57B59.60807@oracle.com> Message-ID: <54F5FD39.5030301@oracle.com> OK, thanks. Do I need a second or ready to commit? On 3/3/2015 1:14 AM, Erik Joelsson wrote: > Still looks good. > > (We usually skip the generated-configure in the review since it's > generated and quite large, at least if we remember to) > > /Erik > > On 2015-03-02 18:12, Steven Loomis wrote: >> updated webrev (on cr) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074048 >> webrev: http://cr.openjdk.java.net/~srl/8074048/webrev.01/ >> > From david.holmes at oracle.com Wed Mar 4 00:12:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Mar 2015 10:12:11 +1000 Subject: Use of /usr/ccs/bin on Solaris Message-ID: <54F64DDB.3010605@oracle.com> toolchain.m4 prepends /usr/ccs/bin to the PATH on Solaris, which is a bad thing if you already have your path set up to the correct toolchain! I expect there is some history here, but it seems wrong to me. Thanks, David From erik.joelsson at oracle.com Wed Mar 4 08:17:01 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Mar 2015 09:17:01 +0100 Subject: RFR: JDK-8074099 Even with toolchain type clang, OBJC is set to gcc In-Reply-To: <54F5BAEB.70803@oracle.com> References: <54F5A2B3.3090206@oracle.com> <54F5BAEB.70803@oracle.com> Message-ID: <54F6BF7D.3090502@oracle.com> Looks good to me. /Erik On 2015-03-03 14:45, Magnus Ihse Bursie wrote: > On 2015-03-03 13:01, Magnus Ihse Bursie wrote: >> Open question: Should we do the same for toolchain-type=gcc? I'm not >> quite sure what we're getting from calling the AC_PROG_OBJC macro, >> except perhaps a loss of transparency on how our tools are picked up. >> :-/ In fact, maybe we should just skip the OBJC variable completely. >> In fact, for Objective-C++ (.mm) files, we just use the normal C++ >> compiler. > > The more I think of it, the more I like this idea. Here's a new patch > that does exactly this. > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8074099-remove-objc/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Wed Mar 4 08:17:32 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Mar 2015 09:17:32 +0100 Subject: RFR: JDK-8074048 : Upgrading to ccache 1.3.10 disables the use of ccache In-Reply-To: <54F5FD39.5030301@oracle.com> References: <54C7914B.1050408@oracle.com> <54CB5BC7.5020106@oracle.com> <54CB5F0B.3090004@oracle.com> <54CB621D.5090405@oracle.com> <54CB6491.5050001@oracle.com> <54D37EB7.80501@oracle.com> <54EFA379.1040701@oracle.com> <54F03640.9010206@oracle.com> <54F0A311.3090707@oracle.com> <54F0A60C.6070003@oracle.com> <54F10D3F.7040905@oracle.com> <54F499E5.5070807@oracle.com> <54F57B59.60807@oracle.com> <54F5FD39.5030301@oracle.com> Message-ID: <54F6BF9C.5030805@oracle.com> You are good to go. /Erik On 2015-03-03 19:28, Steven Loomis wrote: > OK, thanks. > > Do I need a second or ready to commit? > > On 3/3/2015 1:14 AM, Erik Joelsson wrote: >> Still looks good. >> >> (We usually skip the generated-configure in the review since it's >> generated and quite large, at least if we remember to) >> >> /Erik >> >> On 2015-03-02 18:12, Steven Loomis wrote: >>> updated webrev (on cr) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074048 >>> webrev: http://cr.openjdk.java.net/~srl/8074048/webrev.01/ >>> >> > From erik.joelsson at oracle.com Wed Mar 4 08:24:17 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Mar 2015 09:24:17 +0100 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54F64DDB.3010605@oracle.com> References: <54F64DDB.3010605@oracle.com> Message-ID: <54F6C131.6020303@oracle.com> At least when we were building on Solaris 10 I think we needed to add that to be sure to get the right tools. It might not be needed on Solaris 11. /Erik On 2015-03-04 01:12, David Holmes wrote: > toolchain.m4 prepends /usr/ccs/bin to the PATH on Solaris, which is a > bad thing if you already have your path set up to the correct > toolchain! I expect there is some history here, but it seems wrong to me. > > Thanks, > David From david.holmes at oracle.com Wed Mar 4 08:31:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Mar 2015 18:31:34 +1000 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54F6C131.6020303@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> Message-ID: <54F6C2E6.5040601@oracle.com> On 4/03/2015 6:24 PM, Erik Joelsson wrote: > At least when we were building on Solaris 10 I think we needed to add > that to be sure to get the right tools. It might not be needed on > Solaris 11. It's not needed on Solaris 10 if you already have the right tools in your path. :( Comment suggests it was needed because the wrong tools were being found in someone's path. Augmenting the path should be the last resort though, not the first. Cheers, David > /Erik > > On 2015-03-04 01:12, David Holmes wrote: >> toolchain.m4 prepends /usr/ccs/bin to the PATH on Solaris, which is a >> bad thing if you already have your path set up to the correct >> toolchain! I expect there is some history here, but it seems wrong to me. >> >> Thanks, >> David > From magnus.ihse.bursie at oracle.com Wed Mar 4 09:42:09 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 04 Mar 2015 10:42:09 +0100 Subject: RFR: JDK-8074091: Remove dead code from merge mistake in JavaCompilation.gmk In-Reply-To: <54F44367.6010408@oracle.com> References: <54F44367.6010408@oracle.com> Message-ID: <54F6D371.9080805@oracle.com> On 2015-03-02 12:03, Erik Joelsson wrote: > Hello, > > In JavaCompilation.gmk, between the definitions of SetupArchive and > add_file_to_copy, there is a partial block of code that looks like it > shouldn't be there. It seems to be part of the moved SetupZipArchive > and has most likely reappeared in JavaCompilation in a merge. The code > snippet is definitely not used and should be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074091 > Patch: > diff -r cc1ab909baf7 make/common/JavaCompilation.gmk > --- a/make/common/JavaCompilation.gmk > +++ b/make/common/JavaCompilation.gmk > @@ -330,13 +330,7 @@ > $1 += $$($1_JAR) > endef > > - $1_SRC_EXCLUDES := $$(foreach i,$$($1_SRC),$$(addprefix > $$i/,$$(addsuffix /%,$$($1_EXCLUDES)))) > - ifneq ($$($1_EXCLUDE_FILES),) > - # Cannot precompute ZIP_EXCLUDE_FILES as it is dependent on which > src root is being > - # zipped at the moment. > - $1_SRC_EXCLUDE_FILES := $$(addprefix %, $$($1_EXCLUDE_FILES)) > $$($1_EXCLUDE_FILES) > - $1_ALL_SRCS := $$(filter-out $$($1_SRC_EXCLUDE_FILES), > $$($1_ALL_SRCS)) > - endif > + > define add_file_to_copy > # param 1 = BUILD_MYPACKAGE > # parma 2 = The source file to copy. Looks good to me! /Magnus From volker.simonis at gmail.com Wed Mar 4 10:21:50 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Mar 2015 11:21:50 +0100 Subject: What's the "real" official build platform for MacOS X? Message-ID: Hi, recently a changed [1] was pushed to jdk9/hs-gc/hotspot which does not compile neither with clang 5.1 nor with clang 4.0. The OpenJDK Wiki [2] lists XCode / clang5.1.1 as the official compiler tool chain for MacOS X so I wonder how this change could slip trough JPRT without noticing the problem. The only explanation I have so far is that JPRT still uses gcc to compile on MacOS X. Can somebody confirm this? Thanks, Volker PS: meanwhile the problem has been fixed [3] [1] http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1573e72240b9 [2] https://wiki.openjdk.java.net/display/Build/Supported+build+platforms [3] https://bugs.openjdk.java.net/browse/JDK-8074319 From erik.joelsson at oracle.com Wed Mar 4 10:37:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Mar 2015 11:37:53 +0100 Subject: What's the "real" official build platform for MacOS X? In-Reply-To: References: Message-ID: <54F6E081.8070706@oracle.com> Hello Volker, We intended to switch to 5.1.1 and clang a long while back, but it never went through. I don't know why the OpenJDK Wiki thinks it did. I'm currently working on getting it done. /Erik On 2015-03-04 11:21, Volker Simonis wrote: > Hi, > > recently a changed [1] was pushed to jdk9/hs-gc/hotspot which does not > compile neither with clang 5.1 nor with clang 4.0. > > The OpenJDK Wiki [2] lists XCode / clang5.1.1 as the official compiler > tool chain for MacOS X so I wonder how this change could slip trough > JPRT without noticing the problem. The only explanation I have so far > is that JPRT still uses gcc to compile on MacOS X. Can somebody > confirm this? > > Thanks, > Volker > > PS: meanwhile the problem has been fixed [3] > > [1] http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1573e72240b9 > [2] https://wiki.openjdk.java.net/display/Build/Supported+build+platforms > [3] https://bugs.openjdk.java.net/browse/JDK-8074319 From magnus.ihse.bursie at oracle.com Wed Mar 4 13:17:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 04 Mar 2015 14:17:20 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis Message-ID: <54F705E0.2030102@oracle.com> When building the native code in the jdk repo, a lot of warnings are generated. So many that it's hard to spot any new issues. While the ultimate goal must be to address and fix these warnings individually, this bug is about disabling these warnings where they occur, so that it is easier to spot new warnings, and that the existing warnings can be addressed one at a time. Disabling warnings instead of fixing them can be problematic. If you are too broad with disabling warnings, you might hide future problems. On the other hand, there have been a lot of warnings that indicate serious problems that has been "hidden in plain sight" for a very long time in the code base anyway. I have opted to disable warnings at the library level. Disabling warnings globally would be too broad. Disabling per file would have been too tedious. Many warnings also tend to repeat across multiple files in the same library, due to e.g. less well-suited programming style or design choice. A library also seems like a suitable chunk of work to address later on, in trying to get rid of the source of the warnings. This fix will not get rid of all warnings, but the bulk of them. It will make the remaining warnings stick out more. The few warnings that remain are either: * Not possible to disable. * Not resulting from native compilation (but from linking, or javadoc, etc). * Not possible to disable with this framework (this goes for builds on pre-4.4 gcc, which Oracle currently does as default on macosx), and libfontmanager on Solaris, which mixes C and C++ code. (While the solstudio C compiler does not fail on requests to disable C++ warnings, the converse is unfortunately not true). It did not seem worth the trouble to build a more extensible framework to handle this, compared to actually fixing these warnings. Note that the current JPRT build environment in Oracle uses a pre-4.4 gcc for macosx by default, so the default macosx build will still contain warnings. When building with --with-toolchain-type=clang, the clang warning disabling kicks in. (This will be the default in JPRT later on this year.) I intend to file individual bugs to handle these remaining warnings, so the net result will be a completely warning free build. I also intend to file individual bugs on all the libraries that has had warnings disabled. I expect the outcome of these bugs to be either: A) The code modified so it does not trigger warnings, and the warnings re-enabled, or B) The warnings (or a subset of them) kept disabled, but a comment added to the makefile describing why this is the proper course of action. Not all bugs might be worth fixing. For instance, the GCC warnings type-limits, sign-compare, pointer-to-int-cast, conversion-null, deprecated-declarations, clobbered, int-to-pointer-cast and type-limits are all more or less benign, and is possibly the result of a false positive. On the other hands, warnings such as format-nonliteral, unused-result, maybe-uninitialized, format, format-security, int-to-pointer-cast, reorder and delete-non-virtual-dtor are more likely to actually point to real issues. I recommend anyone finding these warnings on a library they care about to try and fix them as soon as possible. Here is a summary of the libraries and binaries that have gotten warnings disabled. I'm not sure about what group owns all these libraries; if I missed sending this mail to the correct list, please help me and forward it. * libunpack * libfdlibm * libverify * libjava * libzip * libjli/libjli_static * libj2gss * libsunec * libj2pkcs11 * libnet * libnio * libosxkrb5 * libosxapp * libosx * libapplescriptengine * libjsound * libjsoundalsa * libmlib_image * libawt * libawt_xawt * libawt_lwawt * liblcms * libjavajpeg * libawt_headless * libfontmanager * libsplashscreen * unpack200 * The JVMTI demos compiledMethodLoad and waiters Bug: https://bugs.openjdk.java.net/browse/JDK-8074096 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Mar 4 13:31:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Mar 2015 14:31:53 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F705E0.2030102@oracle.com> References: <54F705E0.2030102@oracle.com> Message-ID: <54F70949.4040900@oracle.com> Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line options to grep so that the command line could be copied to the shell for debugging in the future? Also, how hard would it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead test for capability? /Erik On 2015-03-04 14:17, Magnus Ihse Bursie wrote: > When building the native code in the jdk repo, a lot of warnings are > generated. So many that it's hard to spot any new issues. > > While the ultimate goal must be to address and fix these warnings > individually, this bug is about disabling these warnings where they > occur, so that it is easier to spot new warnings, and that the > existing warnings can be addressed one at a time. > > Disabling warnings instead of fixing them can be problematic. If you > are too broad with disabling warnings, you might hide future problems. > On the other hand, there have been a lot of warnings that indicate > serious problems that has been "hidden in plain sight" for a very long > time in the code base anyway. > > I have opted to disable warnings at the library level. Disabling > warnings globally would be too broad. Disabling per file would have > been too tedious. Many warnings also tend to repeat across multiple > files in the same library, due to e.g. less well-suited programming > style or design choice. A library also seems like a suitable chunk of > work to address later on, in trying to get rid of the source of the > warnings. > > This fix will not get rid of all warnings, but the bulk of them. It > will make the remaining warnings stick out more. The few warnings that > remain are either: > * Not possible to disable. > * Not resulting from native compilation (but from linking, or javadoc, > etc). > * Not possible to disable with this framework (this goes for builds on > pre-4.4 gcc, which Oracle currently does as default on macosx), and > libfontmanager on Solaris, which mixes C and C++ code. (While the > solstudio C compiler does not fail on requests to disable C++ > warnings, the converse is unfortunately not true). It did not seem > worth the trouble to build a more extensible framework to handle this, > compared to actually fixing these warnings. > > Note that the current JPRT build environment in Oracle uses a pre-4.4 > gcc for macosx by default, so the default macosx build will still > contain warnings. When building with --with-toolchain-type=clang, the > clang warning disabling kicks in. (This will be the default in JPRT > later on this year.) > > I intend to file individual bugs to handle these remaining warnings, > so the net result will be a completely warning free build. > > I also intend to file individual bugs on all the libraries that has > had warnings disabled. I expect the outcome of these bugs to be either: > > A) The code modified so it does not trigger warnings, and the warnings > re-enabled, or > > B) The warnings (or a subset of them) kept disabled, but a comment > added to the makefile describing why this is the proper course of action. > > Not all bugs might be worth fixing. For instance, the GCC warnings > type-limits, sign-compare, pointer-to-int-cast, conversion-null, > deprecated-declarations, clobbered, int-to-pointer-cast and > type-limits are all more or less benign, and is possibly the result of > a false positive. > > On the other hands, warnings such as format-nonliteral, unused-result, > maybe-uninitialized, format, format-security, int-to-pointer-cast, > reorder and delete-non-virtual-dtor are more likely to actually point > to real issues. I recommend anyone finding these warnings on a library > they care about to try and fix them as soon as possible. > > Here is a summary of the libraries and binaries that have gotten > warnings disabled. I'm not sure about what group owns all these > libraries; if I missed sending this mail to the correct list, please > help me and forward it. > > * libunpack > * libfdlibm > * libverify > * libjava > * libzip > * libjli/libjli_static > * libj2gss > * libsunec > * libj2pkcs11 > * libnet > * libnio > * libosxkrb5 > * libosxapp > * libosx > * libapplescriptengine > * libjsound > * libjsoundalsa > * libmlib_image > * libawt > * libawt_xawt > * libawt_lwawt > * liblcms > * libjavajpeg > * libawt_headless > * libfontmanager > * libsplashscreen > * unpack200 > * The JVMTI demos compiledMethodLoad and waiters > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074096 > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01 > > /Magnus > From volker.simonis at gmail.com Wed Mar 4 13:35:35 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Mar 2015 14:35:35 +0100 Subject: What's the "real" official build platform for MacOS X? In-Reply-To: <54F6E081.8070706@oracle.com> References: <54F6E081.8070706@oracle.com> Message-ID: Hi Erik, thanks for the info and good to see that there's at least one build platform where we're ahead of the pack :) Regards, Volker On Wed, Mar 4, 2015 at 11:37 AM, Erik Joelsson wrote: > Hello Volker, > > We intended to switch to 5.1.1 and clang a long while back, but it never > went through. I don't know why the OpenJDK Wiki thinks it did. I'm currently > working on getting it done. > > /Erik > > > On 2015-03-04 11:21, Volker Simonis wrote: >> >> Hi, >> >> recently a changed [1] was pushed to jdk9/hs-gc/hotspot which does not >> compile neither with clang 5.1 nor with clang 4.0. >> >> The OpenJDK Wiki [2] lists XCode / clang5.1.1 as the official compiler >> tool chain for MacOS X so I wonder how this change could slip trough >> JPRT without noticing the problem. The only explanation I have so far >> is that JPRT still uses gcc to compile on MacOS X. Can somebody >> confirm this? >> >> Thanks, >> Volker >> >> PS: meanwhile the problem has been fixed [3] >> >> [1] http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1573e72240b9 >> [2] https://wiki.openjdk.java.net/display/Build/Supported+build+platforms >> [3] https://bugs.openjdk.java.net/browse/JDK-8074319 > > From Alan.Bateman at oracle.com Wed Mar 4 13:48:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Mar 2015 13:48:50 +0000 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F705E0.2030102@oracle.com> References: <54F705E0.2030102@oracle.com> Message-ID: <54F70D42.3010905@oracle.com> On 04/03/2015 13:17, Magnus Ihse Bursie wrote: > : > > I intend to file individual bugs to handle these remaining warnings, > so the net result will be a completely warning free build. > > I also intend to file individual bugs on all the libraries that has > had warnings disabled. I expect the outcome of these bugs to be either: > > A) The code modified so it does not trigger warnings, and the warnings > re-enabled, or > > B) The warnings (or a subset of them) kept disabled, but a comment > added to the makefile describing why this is the proper course of action. > > Not all bugs might be worth fixing. For instance, the GCC warnings > type-limits, sign-compare, pointer-to-int-cast, conversion-null, > deprecated-declarations, clobbered, int-to-pointer-cast and > type-limits are all more or less benign, and is possibly the result of > a false positive. Right, although for some of these it is important to double check. Do you plan to paste in the warnings into the bugs that you will create? That wold be useful as warnings are a moving target. -Alan From magnus.ihse.bursie at oracle.com Wed Mar 4 15:03:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 04 Mar 2015 16:03:20 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F70D42.3010905@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com> Message-ID: <54F71EB8.3030109@oracle.com> On 2015-03-04 14:48, Alan Bateman wrote: > On 04/03/2015 13:17, Magnus Ihse Bursie wrote: >> : >> >> I intend to file individual bugs to handle these remaining warnings, >> so the net result will be a completely warning free build. >> >> I also intend to file individual bugs on all the libraries that has >> had warnings disabled. I expect the outcome of these bugs to be either: >> >> A) The code modified so it does not trigger warnings, and the >> warnings re-enabled, or >> >> B) The warnings (or a subset of them) kept disabled, but a comment >> added to the makefile describing why this is the proper course of >> action. >> >> Not all bugs might be worth fixing. For instance, the GCC warnings >> type-limits, sign-compare, pointer-to-int-cast, conversion-null, >> deprecated-declarations, clobbered, int-to-pointer-cast and >> type-limits are all more or less benign, and is possibly the result >> of a false positive. > Right, although for some of these it is important to double check. I believe all warnings are important to check! Unfortunately, this has not been done for a lot of warnings for a lot of time. :( With this framework, it is simple to enable a single warning, recompile and see the effect. Hopefully this lowers the threshold far enough so that all warnings are given proper attention. The incremental build functionality will come in very handy. Just by simply removing a warning from the DISABLED_WARNINGS_ on a library and running "make" again, only the files affected will be recompiled. > > Do you plan to paste in the warnings into the bugs that you will > create? That wold be useful as warnings are a moving target. I can easily paste in what warning categories are disabled for a specific library, yes. However, if you are asking me to build each library, individually, with warnings re-enabled, and pasting the output, I'd rather not. That would be a lot of work, to detangle the output of each individual library. /Magnus From tim.bell at oracle.com Wed Mar 4 16:19:32 2015 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 04 Mar 2015 08:19:32 -0800 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F70949.4040900@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com> Message-ID: <54F73094.8020108@oracle.com> Magnus: Looks good to me as well. Tim On 03/04/15 05:31, Erik Joelsson wrote: > Hello, > > Really nice to finally see this patch getting done! > > Only one comment: > > flags.m4: > In the grep expression, could you move the extra [] outside of the > actual command line options to grep so that the command line could be > copied to the shell for debugging in the future? Also, how hard would > it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead > test for capability? > > /Erik > > On 2015-03-04 14:17, Magnus Ihse Bursie wrote: >> When building the native code in the jdk repo, a lot of warnings are >> generated. So many that it's hard to spot any new issues. >> >> While the ultimate goal must be to address and fix these warnings >> individually, this bug is about disabling these warnings where they >> occur, so that it is easier to spot new warnings, and that the >> existing warnings can be addressed one at a time. >> >> Disabling warnings instead of fixing them can be problematic. If you >> are too broad with disabling warnings, you might hide future >> problems. On the other hand, there have been a lot of warnings that >> indicate serious problems that has been "hidden in plain sight" for a >> very long time in the code base anyway. >> >> I have opted to disable warnings at the library level. Disabling >> warnings globally would be too broad. Disabling per file would have >> been too tedious. Many warnings also tend to repeat across multiple >> files in the same library, due to e.g. less well-suited programming >> style or design choice. A library also seems like a suitable chunk of >> work to address later on, in trying to get rid of the source of the >> warnings. >> >> This fix will not get rid of all warnings, but the bulk of them. It >> will make the remaining warnings stick out more. The few warnings >> that remain are either: >> * Not possible to disable. >> * Not resulting from native compilation (but from linking, or >> javadoc, etc). >> * Not possible to disable with this framework (this goes for builds >> on pre-4.4 gcc, which Oracle currently does as default on macosx), >> and libfontmanager on Solaris, which mixes C and C++ code. (While the >> solstudio C compiler does not fail on requests to disable C++ >> warnings, the converse is unfortunately not true). It did not seem >> worth the trouble to build a more extensible framework to handle >> this, compared to actually fixing these warnings. >> >> Note that the current JPRT build environment in Oracle uses a pre-4.4 >> gcc for macosx by default, so the default macosx build will still >> contain warnings. When building with --with-toolchain-type=clang, the >> clang warning disabling kicks in. (This will be the default in JPRT >> later on this year.) >> >> I intend to file individual bugs to handle these remaining warnings, >> so the net result will be a completely warning free build. >> >> I also intend to file individual bugs on all the libraries that has >> had warnings disabled. I expect the outcome of these bugs to be either: >> >> A) The code modified so it does not trigger warnings, and the >> warnings re-enabled, or >> >> B) The warnings (or a subset of them) kept disabled, but a comment >> added to the makefile describing why this is the proper course of >> action. >> >> Not all bugs might be worth fixing. For instance, the GCC warnings >> type-limits, sign-compare, pointer-to-int-cast, conversion-null, >> deprecated-declarations, clobbered, int-to-pointer-cast and >> type-limits are all more or less benign, and is possibly the result >> of a false positive. >> >> On the other hands, warnings such as format-nonliteral, >> unused-result, maybe-uninitialized, format, format-security, >> int-to-pointer-cast, reorder and delete-non-virtual-dtor are more >> likely to actually point to real issues. I recommend anyone finding >> these warnings on a library they care about to try and fix them as >> soon as possible. >> >> Here is a summary of the libraries and binaries that have gotten >> warnings disabled. I'm not sure about what group owns all these >> libraries; if I missed sending this mail to the correct list, please >> help me and forward it. >> >> * libunpack >> * libfdlibm >> * libverify >> * libjava >> * libzip >> * libjli/libjli_static >> * libj2gss >> * libsunec >> * libj2pkcs11 >> * libnet >> * libnio >> * libosxkrb5 >> * libosxapp >> * libosx >> * libapplescriptengine >> * libjsound >> * libjsoundalsa >> * libmlib_image >> * libawt >> * libawt_xawt >> * libawt_lwawt >> * liblcms >> * libjavajpeg >> * libawt_headless >> * libfontmanager >> * libsplashscreen >> * unpack200 >> * The JVMTI demos compiledMethodLoad and waiters >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074096 >> >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01 >> >> /Magnus >> > From jan.lahoda at oracle.com Wed Mar 4 16:02:52 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 04 Mar 2015 17:02:52 +0100 Subject: History data for "JDK-8058150: Compile for Specific Platform Version" In-Reply-To: <54F0A14E.7080401@oracle.com> References: <54F02B54.3030700@oracle.com> <54F07590.90509@oracle.com> <54F0940F.7060007@oracle.com> <54F09CBE.200@oracle.com> <54F0A14E.7080401@oracle.com> Message-ID: <54F72CAC.5060001@oracle.com> Magnus, Jon, As per your suggestions, I've split the ct.sym.txt into several files approximately per (current) module. I've changed to format to a baseline+change files as well. The biggest file is java.desktop baseline (OpenJDK 7 content) which is <5MB, followed by java.base baseline whose size is ~4.5MB. The total size of all these files inside the .hg folder is still ~1.7MB. The files can be seen here: http://hg.openjdk.java.net/jdk9/sandbox/file/7f017edb8377/make/data/symbols An example of the change file: http://hg.openjdk.java.net/jdk9/sandbox/file/7f017edb8377/make/data/symbols/jdk.dev-8.sym.txt Does this look reasonable? Thanks for your help! Jan On 27.2.2015 17:54, Jonathan Gibbons wrote: > On 02/27/2015 08:35 AM, Magnus Ihse Bursie wrote: >> On 2015-02-27 16:58, Jan Lahoda wrote: >>> On 27.2.2015 14:48, Magnus Ihse Bursie wrote: >>>> Hi Jan, >>>> >>>> On 2015-02-27 09:31, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I have a question on JDK-8058150: "Compile for Specific Platform >>>>> Version". To support compilation for older versions of the platform, >>>>> javac will need some description of the APIs as they existed in the >>>>> target platforms. >>>>> >>>>> For this, the current proposal is to use lib/ct.sym file (similar, but >>>>> different, to the JDK 8 lib/ct.sym), containing classfiles of the >>>>> older APIs. This file would be constructed at build time from a >>>>> textual representation of the APIs stored in an OpenJDK repository >>>>> (currently called ct.sym.txt). >>>>> >>>>> The current ct.sym.txt is a single file that contains APIs for all >>>>> supported versions, reusing entries for multiple versions when needed. >>>>> An alternative would be to use ct7.sym.txt for JDK 7 APIs, ct8.sym.txt >>>>> for JDK 8 APIs, etc. Using a single file leads to a smaller total size >>>>> (as it reuses entries where it can), but needs to be considerably >>>>> changed when a new version is added or an obsolete version is removed. >>>>> >>>>> The size of the file is considerable: for the "ct.sym.txt" that >>>>> represents APIs from OpenJDK 7 and 8, the size of the checked-out file >>>>> in the working copy is (currently[2]) ~23MB, and inside the .hg >>>>> directory, the file has ~1.7MB (Mercurial is apparently able to >>>>> compress the ct.sym.txt file very well - but as all history is kept >>>>> inside .hg directory, the size of the file inside the .hg directory >>>>> increases when the ct.sym.txt is updated). >>>> >>>> In my opinion, the only size that matters here is in the .hg directory. >>>> If the workspace takes 23 MB more or less is a non-issue when a full >>>> forest clone is in the gigabyte range. But I don't think 1.7 MB extra >>>> for the top-level repo is much of a problem either. Since the top-level >>>> repo currently is so tiny, it will grow noticably in percentage. But >>>> compare this with hotspot/.hg on 67 MB or jdk/.hg on 351 MB. >>> >>> Thanks. I also think the size inside the .hg folder is more important. >>> >>>> >>>> If you have a proper text format so future edits can be made as trivial >>>> diffs, then the mercurial storage will not grow noticable in the future >>>> either. >>> >>> The file currently contains version numbers on most lines, so adding >>> or removing a support for a platform version means a significant >>> update to the file. I am thinking of some ways to limit that, though. >> >> I peaked at your current solution. Is it possible to store the file as >> a baseline version (JDK 7, or however far back you want to go) and a >> set of deltas? Instead of like: >> header extends java/lang/Object flags 31 classAnnotations >> @Ljdk/Profile+Annotation;(value=I4) versions 78 >> method name descriptor ()V flags 8 versions 78 >> method name descriptor ()V flags 1 versions 8 >> method name getHostId descriptor ()Ljava/lang/String; flags 1 versions 7 >> >> Store it like: >> baseline-jdk7.sym.txt >> header extends java/lang/Object flags 31 classAnnotations >> @Ljdk/Profile+Annotation;(value=I4) >> method name descriptor ()V flags 8 >> >> jdk8.sym.txt >> +method name descriptor ()V flags 1 >> -method name getHostId descriptor ()Ljava/lang/String; flags 1 >> >> ? >> >> In fact, if it is not too expensive to generate this kind of file from >> the build, you could perhaps do it the other way round, and create a >> "baseline" for the current JDK just built, and just store the diffs to >> previous versions. (Although that might be a maintainence burden to >> make sure that these reverse diffs are up to date). >> >> >>> >>>> >>>>> Another alternative would be to partition the file into several >>>>> smaller files - would be easier to grasp, but if the files would be >>>>> too small, the compression would be worse (leading to bigger >>>>> repositories). >>>> What is the actual difference? Having too large files can be burdensome >>>> on other tools as well, eg. if you open it (mistakenly or not) in a >>>> text >>>> editor. I would tend to prefer several smaller files than one huge. >>> >>> That depends on how is the file split up. Originally, I was thinking >>> of having a file per package, but that produces (too) many small >>> files - 797 files, the biggest one having ~650kB (in the working >>> copy), consumes ~5.9MB total inside .hg. >> Can you match it to modules? I realize older JDKs has no module >> concept, but that sounds like it could be a reasonable number of >> reasonable sized chunks. >> >> /Magnus >> >>> >>> There was a proposal to have a single ct.sym file per each jar file >>> on the bootclasspath (in the target platform), but this produces >>> ~20MB (in the working copy) file for ct.sym, while the next biggest >>> file is for nashorn.jar: ~1MB (in the working copy). This consumes >>> ~1.7MB inside the .hg directory. >>> >>> I tried to split the big ct.sym.txt artificially at approximately >>> 1MB, this leads to 23 files, and still consumes ~1.7MB inside the .hg >>> directory. >>> >>>>> Currently, the proposal is to place the ct.sym.txt file into the >>>>> top-level repository. A prototype of this feature is currently in the >>>>> jdk9/sandbox forest, on branch JDK-8058150-branch. The current >>>>> ct.sym.txt file is >>>>> /make/data/symbols/ct.sym.txt. >>>> Sounds like a good place to put such a file. I assume it will be >>>> processed during building? >>> >>> Yes, the file is processed during build and the ct.sym file in >>> produced into the "lib" directory. In my current prototype, I've >>> tweaked the make/Images.gmk to do that: >>> http://hg.openjdk.java.net/jdk9/sandbox/file/087692cc2663/make/Images.gmk >>> >>> (in the "ct.sym" section). >>> >>> Thanks for the comments, >>> Jan >>> >>>> >>>> /Magnus >> > > > Magnus, > > The simplified generalization of your suggestion would be to simply use > patch/diff files. > > We could have a baseline of (say) > > jdk7.sym.txt > > then have a patch file > > jdk8.sym.patch > > which can be applied (in the build) to jdk7.sym.txt to get jdk8.sym.txt > > Since the .txt and .patch files reflect existing releases, they would > almost never change, so the .hg files would be constant. > > Maybe once in a while, we would prune the history, remove older version > info, and add a new baseline. > > -- Jon From Alan.Bateman at oracle.com Wed Mar 4 16:30:47 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Mar 2015 16:30:47 +0000 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F71EB8.3030109@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com> <54F71EB8.3030109@oracle.com> Message-ID: <54F73337.3090309@oracle.com> On 04/03/2015 15:03, Magnus Ihse Bursie wrote: > I believe all warnings are important to check! Unfortunately, this has > not been done for a lot of warnings for a lot of time. :( Right, although in the past we had some areas close to be cleared of warnings, it's just that we didn't keep up the effort and of course the compilers get more pedantic with each version. > > With this framework, it is simple to enable a single warning, > recompile and see the effect. Hopefully this lowers the threshold far > enough so that all warnings are given proper attention. The > incremental build functionality will come in very handy. Just by > simply removing a warning from the DISABLED_WARNINGS_ on a > library and running "make" again, only the files affected will be > recompiled. Yes, it looks easy to maintain. > > I can easily paste in what warning categories are disabled for a > specific library, yes. > > However, if you are asking me to build each library, individually, > with warnings re-enabled, and pasting the output, I'd rather not. That > would be a lot of work, to detangle the output of each individual > library. I'm not asking that, it would be too much work. Maybe it's worth saving the logs somewhere so that you can point the bugs at it. It would also be useful for the bugs to point to your change sets (when they are pushed) so that it's obvious which make files were changed to silence the warnings. -Alan From erik.joelsson at oracle.com Wed Mar 4 16:36:33 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Mar 2015 17:36:33 +0100 Subject: RFR: JDK-8074395: Random build failures in javadoc on Solaris Message-ID: <54F73491.9090303@oracle.com> Hello, JPRT builds on Solaris randomly fails. The failures look like the typical problem of over allocating resources on Solaris. This time it seems like it's too many instances of javadoc that overloads the machine. My suggested fix is to use the JAVA_SMALL flags for all javadoc invocations except the main one for the core apis. The main invocation is big and needs a big jvm configuration. All the rest are comparably very small and should be fine with a small configuration. Preliminary testing on my local linux machine shows no performance regression from this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8074395 Webrev: http://cr.openjdk.java.net/~erikj/8074395/webrev.root.01/ /Erik From tim.bell at oracle.com Wed Mar 4 17:03:56 2015 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 04 Mar 2015 09:03:56 -0800 Subject: RFR: JDK-8074395: Random build failures in javadoc on Solaris In-Reply-To: <54F73491.9090303@oracle.com> References: <54F73491.9090303@oracle.com> Message-ID: <54F73AFC.8060909@oracle.com> Hello Erik: > JPRT builds on Solaris randomly fails. The failures look like the > typical problem of over allocating resources on Solaris. This time it > seems like it's too many instances of javadoc that overloads the machine. > > My suggested fix is to use the JAVA_SMALL flags for all javadoc > invocations except the main one for the core apis. The main invocation > is big and needs a big jvm configuration. All the rest are comparably > very small and should be fine with a small configuration. Preliminary > testing on my local linux machine shows no performance regression from > this change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074395 > Webrev: http://cr.openjdk.java.net/~erikj/8074395/webrev.root.01 Looks good to me. Tim From staffan.larsen at oracle.com Wed Mar 4 19:21:10 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Mar 2015 20:21:10 +0100 Subject: RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole. Message-ID: The problem is that the makefiles do "cleanup" of the resource files, accidentally deleting half of some strings. In this case GC_INFO=Name = ''{0}'', Collections = {1,choice,-1#Unavailable|0#{1,number,integer}}, Total time spent = {2} becomes GC_INFO=Name \= ''{0}'', Collections \= {1,choice,-1# The below diff fixes the problem. I added an extra ^ before the # so that only # at the beginning of the line are treated as comments. I don?t know if this has other implications, though? Should # anywhere on the line be treated as the beginning of a comment? In that case we need to handle the jconsole resource file specially. Thanks, /Staffan diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -393,7 +393,7 @@ $(MKDIR) -p $$(@D) export LC_ALL=C ; ( $(CAT) $$< && $(ECHO) "" ) \ | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ - -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ + -e 's/\([^\\]\)!/\1\\!/g' -e 's/^#.*/#/g' \ | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ | $(SED) -e '/^#/d' -e '/^$$$$/d' \ -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ From martinrb at google.com Wed Mar 4 21:03:53 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Mar 2015 13:03:53 -0800 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54F6C2E6.5040601@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> Message-ID: I agree that configure should not mess with user's PATH and should "auto-find" programs in /usr/ccs/bin only as a last resort. It would be reasonable, when configure fails on Solaris, to notice that the user does not have /usr/ccs/bin on PATH and suggest appending. On Wed, Mar 4, 2015 at 12:31 AM, David Holmes wrote: > On 4/03/2015 6:24 PM, Erik Joelsson wrote: > >> At least when we were building on Solaris 10 I think we needed to add >> that to be sure to get the right tools. It might not be needed on >> Solaris 11. >> > > It's not needed on Solaris 10 if you already have the right tools in your > path. :( Comment suggests it was needed because the wrong tools were being > found in someone's path. Augmenting the path should be the last resort > though, not the first. > > Cheers, > David > > > /Erik >> >> On 2015-03-04 01:12, David Holmes wrote: >> >>> toolchain.m4 prepends /usr/ccs/bin to the PATH on Solaris, which is a >>> bad thing if you already have your path set up to the correct >>> toolchain! I expect there is some history here, but it seems wrong to me. >>> >>> Thanks, >>> David >>> >> >> From philip.race at oracle.com Wed Mar 4 21:31:34 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 04 Mar 2015 13:31:34 -0800 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F73337.3090309@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com> <54F71EB8.3030109@oracle.com> <54F73337.3090309@oracle.com> Message-ID: <54F779B6.1000503@oracle.com> I like the overall approach. We can then attack the warnings lib by lib and/or platform by platform. I do want to mention that some libs like liblcms are 3rd party open source libraries and it may not always be possible to convince upstream to change their code. -phil. On 03/04/2015 08:30 AM, Alan Bateman wrote: > On 04/03/2015 15:03, Magnus Ihse Bursie wrote: >> I believe all warnings are important to check! Unfortunately, this >> has not been done for a lot of warnings for a lot of time. :( > Right, although in the past we had some areas close to be cleared of > warnings, it's just that we didn't keep up the effort and of course > the compilers get more pedantic with each version. > >> >> With this framework, it is simple to enable a single warning, >> recompile and see the effect. Hopefully this lowers the threshold far >> enough so that all warnings are given proper attention. The >> incremental build functionality will come in very handy. Just by >> simply removing a warning from the DISABLED_WARNINGS_ on a >> library and running "make" again, only the files affected will be >> recompiled. > Yes, it looks easy to maintain. > > >> >> I can easily paste in what warning categories are disabled for a >> specific library, yes. >> >> However, if you are asking me to build each library, individually, >> with warnings re-enabled, and pasting the output, I'd rather not. >> That would be a lot of work, to detangle the output of each >> individual library. > I'm not asking that, it would be too much work. Maybe it's worth > saving the logs somewhere so that you can point the bugs at it. It > would also be useful for the bugs to point to your change sets (when > they are pushed) so that it's obvious which make files were changed to > silence the warnings. > > -Alan From mandy.chung at oracle.com Thu Mar 5 01:13:50 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Mar 2015 17:13:50 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules Message-ID: <54F7ADCE.50900@oracle.com> As listed in an open issue in JEP 200: The jdk.dev and jdk.runtime modules contain miscellaneous tools that do not obviously belong to any other module; these modules will eventually be either renamed or refactored. Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in the JDK that are organized around its primary tool. Such organization is easy to name, document and understand. This patch proposes to move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, jdk.policytool modules. Overall Webrev that will be convenient to review the build change and modules.xml change. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ Separate webrevs for each issue: 1. pack200, unpack200 to jdk.pack200 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ 2. jar, jarsigner to jdk.jartool http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ 3. policytool to jdk.policytool http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ There are remaining tools in jdk.dev that will be handled separately. jdk.dev will disappear when all of the remaining tools find its home. Mandy From jonathan.gibbons at oracle.com Thu Mar 5 02:13:04 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 04 Mar 2015 18:13:04 -0800 Subject: make clean-docs Message-ID: <54F7BBB0.2040002@oracle.com> Build team, Given the versatility of "make clean" and friends, I was surprised that "make clean-docs" did not appear to be supported. -- Jon From weijun.wang at oracle.com Thu Mar 5 02:55:26 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Mar 2015 10:55:26 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. So what I am suggesting is - Create jdk.security.util - Move jarsigner, policytool to jdk.security.util - Create the new APIs in this module - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). Or, we can break it into jdk.security.tools and jdk.security.util. Put the executables into tools and APIs into util. --Max > On Mar 5, 2015, at 09:13, Mandy Chung wrote: > > As listed in an open issue in JEP 200: > > The jdk.dev and jdk.runtime modules contain miscellaneous tools that do > not obviously belong to any other module; these modules will eventually > be either renamed or refactored. > > Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in > the JDK that are organized around its primary tool. Such organization > is easy to name, document and understand. This patch proposes to > move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, > jdk.policytool modules. > > Overall Webrev that will be convenient to review the build change > and modules.xml change. > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > There are remaining tools in jdk.dev that will be handled separately. > jdk.dev will disappear when all of the remaining tools find its home. > > Mandy > From mandy.chung at oracle.com Thu Mar 5 03:25:16 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Mar 2015 19:25:16 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: References: <54F7ADCE.50900@oracle.com> Message-ID: <54F7CC9C.2020500@oracle.com> On 3/4/2015 6:55 PM, Wang Weijun wrote: > I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. Are you referring to these 2 RFEs? https://bugs.openjdk.java.net/browse/JDK-8056174 https://bugs.openjdk.java.net/browse/JDK-8058778 We have to see the details and webrev to comment on your proposed jdk.security.tools and jdk.security.util modules. There is no issue in keeping a CLI like keytool in java.base. What is your concern? policytool is a GUI app that depends on java.desktop module. If you move jarsigner, policytool and keytool, this new module would require java.desktop to be present to be used. Mandy > So what I am suggesting is > > - Create jdk.security.util > - Move jarsigner, policytool to jdk.security.util > - Create the new APIs in this module > - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). > > Or, we can break it into jdk.security.tools and jdk.security.util. Put the executables into tools and APIs into util. > > --Max > >> On Mar 5, 2015, at 09:13, Mandy Chung wrote: >> >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> From weijun.wang at oracle.com Thu Mar 5 03:33:12 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Mar 2015 11:33:12 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7CC9C.2020500@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F7CC9C.2020500@oracle.com> Message-ID: > On Mar 5, 2015, at 11:25, Mandy Chung wrote: > > > On 3/4/2015 6:55 PM, Wang Weijun wrote: >> I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. > > Are you referring to these 2 RFEs? > https://bugs.openjdk.java.net/browse/JDK-8056174 > https://bugs.openjdk.java.net/browse/JDK-8058778 > > We have to see the details and webrev to comment on your > proposed jdk.security.tools and jdk.security.util modules. Still in design, but you can look at it at http://cr.openjdk.java.net/~weijun/8058778/webrev.00. Or you can read the CCCs. > > There is no issue in keeping a CLI like keytool in java.base. > What is your concern? I just think keytool and jarsigner should stay together. :-) > > policytool is a GUI app that depends on java.desktop module. > If you move jarsigner, policytool and keytool, this new module > would require java.desktop to be present to be used. Correct. Put it in its own module. --Max > > Mandy From Alan.Bateman at oracle.com Thu Mar 5 08:23:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:23:50 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: References: <54F7ADCE.50900@oracle.com> Message-ID: <54F81296.5080006@oracle.com> On 05/03/2015 02:55, Wang Weijun wrote: > - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). > > The reason that keytool is in java.base is so that keys and certificates can be managed on a small runtime. It's the same reason that it is in our compact1 builds too. I wasn't aware of JDK-8058778 but it can't result in java.base exporting a JDK-specific API. -Alan From Alan.Bateman at oracle.com Thu Mar 5 08:31:31 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:31:31 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F81463.7000903@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > : > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > I think this looks okay. In the unshuffle_list (for back/forward porting patches) then it lists specific files, I wonder if we can move that to directories. I also see remnants of the tracing API in that file, I assume they can be removed. -Alan. From Alan.Bateman at oracle.com Thu Mar 5 08:35:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:35:11 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F8153F.9060301@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > This part looks good to me. -Alan From erik.joelsson at oracle.com Thu Mar 5 09:05:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 05 Mar 2015 10:05:21 +0100 Subject: RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole. In-Reply-To: References: Message-ID: <54F81C51.4070307@oracle.com> Hello, The specification for the properties file format says that a comment is a line that has either a ! or # as the first non whitespace character. Greping around in the source shows we have several instances if comments tarting a few spaces in. I don't think we are using ! for comments anywhere though. Using this expression seems to do the trick for me: 's/^[ ]*#.*/#/g' Note that the contents of the [] is one space and a literal tab as \t is not portable to all versions of sed that we use. The cleaning mechanism is hard to make really safe without semantic parsing. Have you considered using the CompileProperties option instead? For most of the resource bundles in the jdk, we convert the properties into java src. As I understand it, resource bundles work seamlessly as classes or properties files. I assume this is done for runtime performance. You could also choose to just copy the properties files instead of cleaning them, especially if there are no or few comments in them. /Erik On 2015-03-04 20:21, Staffan Larsen wrote: > The problem is that the makefiles do "cleanup" of the resource files, accidentally deleting half of some strings. In this case > > GC_INFO=Name = ''{0}'', Collections = {1,choice,-1#Unavailable|0#{1,number,integer}}, Total time spent = {2} > > becomes > > GC_INFO=Name \= ''{0}'', Collections \= {1,choice,-1# > > The below diff fixes the problem. I added an extra ^ before the # so that only # at the beginning of the line are treated as comments. I don?t know if this has other implications, though? Should # anywhere on the line be treated as the beginning of a comment? In that case we need to handle the jconsole resource file specially. > > Thanks, > /Staffan > > > diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk > --- a/make/common/JavaCompilation.gmk > +++ b/make/common/JavaCompilation.gmk > @@ -393,7 +393,7 @@ > $(MKDIR) -p $$(@D) > export LC_ALL=C ; ( $(CAT) $$< && $(ECHO) "" ) \ > | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ > - -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ > + -e 's/\([^\\]\)!/\1\\!/g' -e 's/^#.*/#/g' \ > | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ > | $(SED) -e '/^#/d' -e '/^$$$$/d' \ > -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ From chris.hegarty at oracle.com Thu Mar 5 09:05:31 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 Mar 2015 09:05:31 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81463.7000903@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81463.7000903@oracle.com> Message-ID: On 5 Mar 2015, at 08:31, Alan Bateman wrote: > On 05/03/2015 01:13, Mandy Chung wrote: >> : >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > I think this looks okay. In the unshuffle_list (for back/forward porting patches) then it lists specific files, I wonder if we can move that to directories. It should be possible to reduced the following set down from: jdk/src/jdk.pack200/share/native/common-unpack/bands.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/bands.cpp jdk/src/jdk.pack200/share/native/common-unpack/bands.h : jdk/src/share/native/com/sun/java/util/jar/pack/bands.h jdk/src/jdk.pack200/share/native/common-unpack/bytes.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/bytes.cpp jdk/src/jdk.pack200/share/native/common-unpack/bytes.h : jdk/src/share/native/com/sun/java/util/jar/pack/bytes.h jdk/src/jdk.pack200/share/native/common-unpack/coding.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/coding.cpp jdk/src/jdk.pack200/share/native/common-unpack/coding.h : jdk/src/share/native/com/sun/java/util/jar/pack/coding.h jdk/src/jdk.pack200/share/native/common-unpack/constants.h : jdk/src/share/native/com/sun/java/util/jar/pack/constants.h jdk/src/jdk.pack200/share/native/common-unpack/defines.h : jdk/src/share/native/com/sun/java/util/jar/pack/defines.h jdk/src/jdk.pack200/share/native/common-unpack/unpack.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/unpack.cpp jdk/src/jdk.pack200/share/native/common-unpack/unpack.h : jdk/src/share/native/com/sun/java/util/jar/pack/unpack.h jdk/src/jdk.pack200/share/native/common-unpack/utils.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/utils.cpp jdk/src/jdk.pack200/share/native/common-unpack/utils.h : jdk/src/share/native/com/sun/java/util/jar/pack/utils.h jdk/src/jdk.pack200/share/native/common-unpack/zip.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp jdk/src/jdk.pack200/share/native/common-unpack/zip.h : jdk/src/share/native/com/sun/java/util/jar/pack/zip.h to jdk/src/jdk.pack200/share/native/common-unpack : jdk/src/share/native/com/sun/java/util/jar/pack ...since the script attempts to match the full path, before reducing. I did mean to do further reductions on this shuffle list, but it just doesn?t seem worth it now, and care needs to be taken to ensure both shuffling and unshuffling work correctly. -Chris. > I also see remnants of the tracing API in that file, I assume they can be removed. > > -Alan. From erik.joelsson at oracle.com Thu Mar 5 09:07:12 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 05 Mar 2015 10:07:12 +0100 Subject: make clean-docs In-Reply-To: <54F7BBB0.2040002@oracle.com> References: <54F7BBB0.2040002@oracle.com> Message-ID: <54F81CC0.5070008@oracle.com> Yes, it has been noted and I created a bug for it while back. I was missing it myself just yesterday so it should happen anytime now. :) /Erik On 2015-03-05 03:13, Jonathan Gibbons wrote: > Build team, > > Given the versatility of "make clean" and friends, I was surprised > that "make clean-docs" did not appear to be supported. > > -- Jon From erik.joelsson at oracle.com Thu Mar 5 09:07:52 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 05 Mar 2015 10:07:52 +0100 Subject: make clean-docs In-Reply-To: <54F81CC0.5070008@oracle.com> References: <54F7BBB0.2040002@oracle.com> <54F81CC0.5070008@oracle.com> Message-ID: <54F81CE8.1090601@oracle.com> Link to bug: https://bugs.openjdk.java.net/browse/JDK-8073634 /Erik On 2015-03-05 10:07, Erik Joelsson wrote: > Yes, it has been noted and I created a bug for it while back. I was > missing it myself just yesterday so it should happen anytime now. :) > > /Erik > > On 2015-03-05 03:13, Jonathan Gibbons wrote: >> Build team, >> >> Given the versatility of "make clean" and friends, I was surprised >> that "make clean-docs" did not appear to be supported. >> >> -- Jon > From weijun.wang at oracle.com Thu Mar 5 09:13:19 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 05 Mar 2015 17:13:19 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81296.5080006@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> Message-ID: <54F81E2F.7010000@oracle.com> There is no problem the new API be in a separate module. It is independent of keytool now. Said that, I've been thinking about rewriting keytool to use this new API. --Max On 3/5/2015 16:23, Alan Bateman wrote: > On 05/03/2015 02:55, Wang Weijun wrote: >> - Move keytool to jdk.security.util, it's now in java.base but keytool >> is not part of Java SE spec (Of course, if that means keytool will be >> in JDK instead of JRE please stop. But will there will the name >> difference anymore? I am thinking of an installer like cygwin that you >> can choose anything except that java.base is checked grayed). >> >> > The reason that keytool is in java.base is so that keys and certificates > can be managed on a small runtime. It's the same reason that it is in > our compact1 builds too. I wasn't aware of JDK-8058778 but it can't > result in java.base exporting a JDK-specific API. > > -Alan From erik.joelsson at oracle.com Thu Mar 5 09:25:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 05 Mar 2015 10:25:06 +0100 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F820F2.8070009@oracle.com> Hello Mandy, The build changes look ok to me. /Erik On 2015-03-05 02:13, Mandy Chung wrote: > As listed in an open issue in JEP 200: > > The jdk.dev and jdk.runtime modules contain miscellaneous tools that do > not obviously belong to any other module; these modules will eventually > be either renamed or refactored. > > Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in > the JDK that are organized around its primary tool. Such organization > is easy to name, document and understand. This patch proposes to > move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, > jdk.policytool modules. > > Overall Webrev that will be convenient to review the build change > and modules.xml change. > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > > There are remaining tools in jdk.dev that will be handled separately. > jdk.dev will disappear when all of the remaining tools find its home. > > Mandy > From staffan.larsen at oracle.com Thu Mar 5 10:37:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 5 Mar 2015 11:37:53 +0100 Subject: RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole. In-Reply-To: <54F81C51.4070307@oracle.com> References: <54F81C51.4070307@oracle.com> Message-ID: <1CC01E7D-58A9-47E3-8311-7DB2127D8C49@oracle.com> Your expression looks good to me (and I verified that it solved the jconsole bug). I will push that. Thanks, /Staffan > On 5 mar 2015, at 10:05, Erik Joelsson wrote: > > Hello, > > The specification for the properties file format says that a comment is a line that has either a ! or # as the first non whitespace character. Greping around in the source shows we have several instances if comments tarting a few spaces in. I don't think we are using ! for comments anywhere though. Using this expression seems to do the trick for me: > > 's/^[ ]*#.*/#/g' > > Note that the contents of the [] is one space and a literal tab as \t is not portable to all versions of sed that we use. > > The cleaning mechanism is hard to make really safe without semantic parsing. Have you considered using the CompileProperties option instead? For most of the resource bundles in the jdk, we convert the properties into java src. As I understand it, resource bundles work seamlessly as classes or properties files. I assume this is done for runtime performance. You could also choose to just copy the properties files instead of cleaning them, especially if there are no or few comments in them. > > /Erik > > On 2015-03-04 20:21, Staffan Larsen wrote: >> The problem is that the makefiles do "cleanup" of the resource files, accidentally deleting half of some strings. In this case >> >> GC_INFO=Name = ''{0}'', Collections = {1,choice,-1#Unavailable|0#{1,number,integer}}, Total time spent = {2} >> >> becomes >> >> GC_INFO=Name \= ''{0}'', Collections \= {1,choice,-1# >> >> The below diff fixes the problem. I added an extra ^ before the # so that only # at the beginning of the line are treated as comments. I don?t know if this has other implications, though? Should # anywhere on the line be treated as the beginning of a comment? In that case we need to handle the jconsole resource file specially. >> >> Thanks, >> /Staffan >> >> >> diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk >> --- a/make/common/JavaCompilation.gmk >> +++ b/make/common/JavaCompilation.gmk >> @@ -393,7 +393,7 @@ >> $(MKDIR) -p $$(@D) >> export LC_ALL=C ; ( $(CAT) $$< && $(ECHO) "" ) \ >> | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ >> - -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ >> + -e 's/\([^\\]\)!/\1\\!/g' -e 's/^#.*/#/g' \ >> | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \ >> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ > From jonathan.gibbons at oracle.com Thu Mar 5 15:05:21 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 05 Mar 2015 07:05:21 -0800 Subject: make clean-docs In-Reply-To: <54F81CE8.1090601@oracle.com> References: <54F7BBB0.2040002@oracle.com> <54F81CC0.5070008@oracle.com> <54F81CE8.1090601@oracle.com> Message-ID: <54F870B1.2060509@oracle.com> Thanks, Erik. -- Jon On 03/05/2015 01:07 AM, Erik Joelsson wrote: > Link to bug: https://bugs.openjdk.java.net/browse/JDK-8073634 > /Erik > > On 2015-03-05 10:07, Erik Joelsson wrote: >> Yes, it has been noted and I created a bug for it while back. I was >> missing it myself just yesterday so it should happen anytime now. :) >> >> /Erik >> >> On 2015-03-05 03:13, Jonathan Gibbons wrote: >>> Build team, >>> >>> Given the versatility of "make clean" and friends, I was surprised >>> that "make clean-docs" did not appear to be supported. >>> >>> -- Jon >> > From Alan.Bateman at oracle.com Thu Mar 5 16:07:04 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 16:07:04 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F87F28.2080904@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > : > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > It seems reasonable to have both jar and jarsigner in the same module so I think this is good. This will also work if Max adds an API to the jarsigner tool as he mentioned in one of the mails. -Alan From mandy.chung at oracle.com Thu Mar 5 16:19:23 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Mar 2015 08:19:23 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81463.7000903@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81463.7000903@oracle.com> Message-ID: <54F8820B.2050201@oracle.com> On 3/5/2015 12:31 AM, Alan Bateman wrote: > On 05/03/2015 01:13, Mandy Chung wrote: >> : >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> > I think this looks okay. In the unshuffle_list (for back/forward > porting patches) then it lists specific files, I wonder if we can move > that to directories. I also see remnants of the tracing API in that > file, I assume they can be removed. I also notice the tracing API left in unshuffle_list should be removed. At some point the entire jdk.dev should go away and so I'm thinking to leave this cleanup for the removal of jdk.dev. Mandy From mandy.chung at oracle.com Thu Mar 5 17:55:44 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Mar 2015 09:55:44 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81E2F.7010000@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> <54F81E2F.7010000@oracle.com> Message-ID: <54F898A0.90707@oracle.com> Max, Since the new APIs you're working on are still in design phase, I think it's a bit early to discuss where these new APIs should be in. Just one thing to say about the new JarSigner API from your webrev. com.sun.jarsigner is an existing exported package that you should consider whether the new APIs should be added there rather than a new package. Anyway, we can discuss that when your work is further along. For this review request, are you okay with this patch moving policytool and jarsigner tools to the new home? Mandy [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/85b61f4eee66/src/jdk.dev/share/classes/com/sun/jarsigner/package-info.java On 3/5/15 1:13 AM, Weijun Wang wrote: > There is no problem the new API be in a separate module. It is > independent of keytool now. > > Said that, I've been thinking about rewriting keytool to use this new > API. > > --Max > > On 3/5/2015 16:23, Alan Bateman wrote: >> On 05/03/2015 02:55, Wang Weijun wrote: >>> - Move keytool to jdk.security.util, it's now in java.base but keytool >>> is not part of Java SE spec (Of course, if that means keytool will be >>> in JDK instead of JRE please stop. But will there will the name >>> difference anymore? I am thinking of an installer like cygwin that you >>> can choose anything except that java.base is checked grayed). >>> >>> >> The reason that keytool is in java.base is so that keys and certificates >> can be managed on a small runtime. It's the same reason that it is in >> our compact1 builds too. I wasn't aware of JDK-8058778 but it can't >> result in java.base exporting a JDK-specific API. >> >> -Alan From weijun.wang at oracle.com Fri Mar 6 01:16:46 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 09:16:46 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F898A0.90707@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> <54F81E2F.7010000@oracle.com> <54F898A0.90707@oracle.com> Message-ID: <8BCFD039-161B-42EE-9638-6E81E3B62F0C@oracle.com> > On Mar 6, 2015, at 01:55, Mandy Chung wrote: > > For this review request, are you okay with this patch moving policytool and jarsigner tools to the new home? Yes. --Max From magnus.ihse.bursie at oracle.com Fri Mar 6 13:44:49 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 14:44:49 +0100 Subject: RFR: JDK-8074554 Create custom hook for running after AC_OUTPUT Message-ID: <54F9AF51.1070005@oracle.com> The custom configure additions needs to be extended with a hook right after AC_OUTPUT. Bug: https://bugs.openjdk.java.net/browse/JDK-8074554 Patch inlined: diff --git a/common/autoconf/configure.ac b/common/autoconf/configure.ac --- a/common/autoconf/configure.ac +++ b/common/autoconf/configure.ac @@ -54,6 +54,7 @@ AC_DEFUN_ONCE([CUSTOM_EARLY_HOOK]) AC_DEFUN_ONCE([CUSTOM_LATE_HOOK]) +AC_DEFUN_ONCE([CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK]) AC_DEFUN_ONCE([CUSTOM_SUMMARY_AND_WARNINGS_HOOK]) # This line needs to be here, verbatim, after all includes and the dummy hook @@ -264,6 +265,7 @@ # Create the actual output files. Now the main work of configure is done. AC_OUTPUT +CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK # Try to move the config.log file to the output directory. if test -e ./config.log; then magnusi at sthihse3:/localhome/hg/jdk9-client-EXP$ I intend to push this to jdk9/client, not jdk9/dev. /Magnus From erik.joelsson at oracle.com Fri Mar 6 13:47:22 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 06 Mar 2015 14:47:22 +0100 Subject: RFR: JDK-8074554 Create custom hook for running after AC_OUTPUT In-Reply-To: <54F9AF51.1070005@oracle.com> References: <54F9AF51.1070005@oracle.com> Message-ID: <54F9AFEA.4040000@oracle.com> Looks good to me. /Erik On 2015-03-06 14:44, Magnus Ihse Bursie wrote: > The custom configure additions needs to be extended with a hook right > after AC_OUTPUT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074554 > Patch inlined: > > diff --git a/common/autoconf/configure.ac b/common/autoconf/configure.ac > --- a/common/autoconf/configure.ac > +++ b/common/autoconf/configure.ac > @@ -54,6 +54,7 @@ > > AC_DEFUN_ONCE([CUSTOM_EARLY_HOOK]) > AC_DEFUN_ONCE([CUSTOM_LATE_HOOK]) > +AC_DEFUN_ONCE([CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK]) > AC_DEFUN_ONCE([CUSTOM_SUMMARY_AND_WARNINGS_HOOK]) > > # This line needs to be here, verbatim, after all includes and the > dummy hook > @@ -264,6 +265,7 @@ > > # Create the actual output files. Now the main work of configure is > done. > AC_OUTPUT > +CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK > > # Try to move the config.log file to the output directory. > if test -e ./config.log; then > magnusi at sthihse3:/localhome/hg/jdk9-client-EXP$ > > I intend to push this to jdk9/client, not jdk9/dev. > > /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 6 14:09:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 15:09:20 +0100 Subject: RFR: JDK-8074554 Create custom hook for running after AC_OUTPUT (8u backport) Message-ID: <54F9B510.4040509@oracle.com> Please review this backport of JDK-8074554 to 8u. While it did not automatically apply cleanly, the difference was trivially resolved. diff --git a/common/autoconf/configure.ac b/common/autoconf/configure.ac --- a/common/autoconf/configure.ac +++ b/common/autoconf/configure.ac @@ -53,6 +53,7 @@ AC_DEFUN_ONCE([CUSTOM_EARLY_HOOK]) AC_DEFUN_ONCE([CUSTOM_LATE_HOOK]) +AC_DEFUN_ONCE([CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK]) # This line needs to be here, verbatim, after all includes and the dummy hook # definitions. It is replaced with custom functionality when building @@ -237,6 +238,7 @@ # Create the actual output files. Now the main work of configure is done. AC_OUTPUT +CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK # Try to move the config.log file to the output directory. if test -e ./config.log; then /Magnus From erik.joelsson at oracle.com Fri Mar 6 14:27:54 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 06 Mar 2015 15:27:54 +0100 Subject: RFR: JDK-8074554 Create custom hook for running after AC_OUTPUT (8u backport) In-Reply-To: <54F9B510.4040509@oracle.com> References: <54F9B510.4040509@oracle.com> Message-ID: <54F9B96A.8040004@oracle.com> Looks good. /Erik On 2015-03-06 15:09, Magnus Ihse Bursie wrote: > Please review this backport of JDK-8074554 to 8u. While it did not > automatically apply cleanly, the difference was trivially resolved. > > diff --git a/common/autoconf/configure.ac b/common/autoconf/configure.ac > --- a/common/autoconf/configure.ac > +++ b/common/autoconf/configure.ac > @@ -53,6 +53,7 @@ > > AC_DEFUN_ONCE([CUSTOM_EARLY_HOOK]) > AC_DEFUN_ONCE([CUSTOM_LATE_HOOK]) > +AC_DEFUN_ONCE([CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK]) > > # This line needs to be here, verbatim, after all includes and the > dummy hook > # definitions. It is replaced with custom functionality when building > @@ -237,6 +238,7 @@ > > # Create the actual output files. Now the main work of configure is > done. > AC_OUTPUT > +CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK > > # Try to move the config.log file to the output directory. > if test -e ./config.log; then > > /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 6 14:33:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 15:33:28 +0100 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F820F2.8070009@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F820F2.8070009@oracle.com> Message-ID: <54F9BAB8.1070601@oracle.com> On 2015-03-05 10:25, Erik Joelsson wrote: > Hello Mandy, > > The build changes look ok to me. Build changes are OK for me too. /Magnus > > /Erik > > On 2015-03-05 02:13, Mandy Chung wrote: >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> > From magnus.ihse.bursie at oracle.com Fri Mar 6 14:41:37 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 15:41:37 +0100 Subject: [8u-dev] Request for approval for JDK-8074554 Create custom hook for running after AC_OUTPUT In-Reply-To: <54F9B96A.8040004@oracle.com> References: <54F9B510.4040509@oracle.com> <54F9B96A.8040004@oracle.com> Message-ID: <54F9BCA1.2020204@oracle.com> Requesting approval to backport this JDK9 fix to jdk8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8074554 Original JDK9 changeset: http://hg.openjdk.java.net/jdk9/client/rev/8b9bd5ba445e /Magnus On 2015-03-06 15:27, Erik Joelsson wrote: > Looks good. > > /Erik > > On 2015-03-06 15:09, Magnus Ihse Bursie wrote: >> Please review this backport of JDK-8074554 to 8u. While it did not >> automatically apply cleanly, the difference was trivially resolved. >> >> diff --git a/common/autoconf/configure.ac b/common/autoconf/configure.ac >> --- a/common/autoconf/configure.ac >> +++ b/common/autoconf/configure.ac >> @@ -53,6 +53,7 @@ >> >> AC_DEFUN_ONCE([CUSTOM_EARLY_HOOK]) >> AC_DEFUN_ONCE([CUSTOM_LATE_HOOK]) >> +AC_DEFUN_ONCE([CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK]) >> >> # This line needs to be here, verbatim, after all includes and the >> dummy hook >> # definitions. It is replaced with custom functionality when building >> @@ -237,6 +238,7 @@ >> >> # Create the actual output files. Now the main work of configure is >> done. >> AC_OUTPUT >> +CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK >> >> # Try to move the config.log file to the output directory. >> if test -e ./config.log; then >> >> /Magnus > From magnus.ihse.bursie at oracle.com Fri Mar 6 14:50:14 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 15:50:14 +0100 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> Message-ID: <54F9BEA6.3010700@oracle.com> On 2015-03-04 22:03, Martin Buchholz wrote: > I agree that configure should not mess with user's PATH and should > "auto-find" programs in /usr/ccs/bin only as a last resort. > > It would be reasonable, when configure fails on Solaris, to notice that the > user does not have /usr/ccs/bin on PATH and suggest appending. I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. Adding a warning to failed configure on Solaris due to missing build tools that presumably resides in /usr/ccs/bin seems like quite a lot of work. I suggest the following: Instead of prepending, append /usr/ccs/bin, so any binaries in the user's specified PATH are picked first. This will allow a properly set PATH to function, but it will still provide the "best effort" approach of configure to look in "well-known locations" for tools. Does that seem like an acceptable solution? /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 6 14:52:42 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 15:52:42 +0100 Subject: History data for "JDK-8058150: Compile for Specific Platform Version" In-Reply-To: <54F72CAC.5060001@oracle.com> References: <54F02B54.3030700@oracle.com> <54F07590.90509@oracle.com> <54F0940F.7060007@oracle.com> <54F09CBE.200@oracle.com> <54F0A14E.7080401@oracle.com> <54F72CAC.5060001@oracle.com> Message-ID: <54F9BF3A.2020804@oracle.com> On 2015-03-04 17:02, Jan Lahoda wrote: > Magnus, Jon, > > As per your suggestions, I've split the ct.sym.txt into several files > approximately per (current) module. I've changed to format to a > baseline+change files as well. The biggest file is java.desktop > baseline (OpenJDK 7 content) which is <5MB, followed by java.base > baseline whose size is ~4.5MB. The total size of all these files > inside the .hg folder is still ~1.7MB. > > The files can be seen here: > http://hg.openjdk.java.net/jdk9/sandbox/file/7f017edb8377/make/data/symbols > > > An example of the change file: > http://hg.openjdk.java.net/jdk9/sandbox/file/7f017edb8377/make/data/symbols/jdk.dev-8.sym.txt > > > Does this look reasonable? Most definitely! I think you've found a sweetspot between too many small and too few large files. Also, the baselining seems reasonable. Hopefully future changes can be stored as highly compressible diffs. /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 6 15:03:51 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 16:03:51 +0100 Subject: Unused DEBUG_CLASSFILES variable in makefiles In-Reply-To: <1424338999.3641.13.camel@redhat.com> References: <20141010165203.GE2698@redhat.com> <543B9414.1080108@oracle.com> <543BBF40.5050100@oracle.com> <20141118165732.GC4240@redhat.com> <20150211225223.GM11144@redhat.com> <1424338999.3641.13.camel@redhat.com> Message-ID: <54F9C1D7.8080407@oracle.com> Hi Severin and Omair, Sorry for not replying to this earlier. I agree that the handling of debug information in OpenJDK has not properly addressed the needs of the Linux distribution community. :-( And even if this does not really help you, I can perhaps comfort you slightly by saying that the needs of Oracle is not properly addressed either. :-& So I'd really like to spend some effort of revamping the code related to debug symbols, so that it properly aligns with the needs of all interested parties. Your mail have brought the issue higher up on the urgency list. I'm trying to get a proper description of all use cases that we need to support. I'll get back to you when I have such a description, to check that I have not misunderstood the needs of the linux distribution community. /Magnus On 2015-02-19 10:43, Severin Gehwolf wrote: > Hi, > > On Wed, 2015-02-11 at 17:52 -0500, Omair Majid wrote: >> Hi, >> >> * Omair Majid [2014-11-18 11:57]: >>> * Magnus Ihse Bursie [2014-10-13 07:49]: >>>> On 2014-10-13 10:57, Erik Joelsson wrote: >>>>> I think it's still used by the hotspot makefiles (sa-jdi.jar). Seems weird >>>>> that we still set it in configure but then ignore the value in the jdk >>>>> build. I would vote for resurrecting the option. >>>> [...] >>>>> I'm not sure if even more debug levels is the right way to go. It seems >>>>> hard to name and that probably means it will be hard to understand. >>>>> Perhaps completely separating native debug level and java debug level >>>>> would make more sense? >>>> I'm not sure "resurrecting" (which actually means adding functionality which >>>> has been gone for quite some time now) is good, since it adds to the >>>> complexity. >>> Well, we do need the debug information, but I am not at all tied to >>> specific implementation. I would be happy to try and implement something >>> that takes a different approach than resurrecting the feature. >>> >>>> However, there have been recurring requests of having more control of debug >>>> vs release builds, and I think we need to address them in some way. >>> Any suggestions for a suitable implementation? >> Sorry to resurrect an old thread, but this just bit me again. > I believe it is fair to say that this issue affects *all* Linux > distributions attempting to build from an upstream OpenJDK tree. This is > to stress that it's a significant issue and it keeps creeping up (the > issue being debug symbols in Java class files and natives - hotspot and > JDK). I'm *very* interested to help find a solution to this once and for > all. > > FWIW, there are a couple of checks we perform that during Fedora OpenJDK > builds in an attempt to ensure that hotspot debug symbols are there: > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n1160 > > Similarly, Java debug info is checked this way: > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n1177 > > Wouldn't it be possible to add similar checks to the OpenJDK builds > system? This is to ensure that it doesn't regress again. Thoughts? > > Finally, I've created this bug in order to track this: > https://bugs.openjdk.java.net/browse/JDK-8073461 > > Thanks, > Severin > From sgehwolf at redhat.com Fri Mar 6 15:11:30 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 06 Mar 2015 16:11:30 +0100 Subject: Unused DEBUG_CLASSFILES variable in makefiles In-Reply-To: <54F9C1D7.8080407@oracle.com> References: <20141010165203.GE2698@redhat.com> <543B9414.1080108@oracle.com> <543BBF40.5050100@oracle.com> <20141118165732.GC4240@redhat.com> <20150211225223.GM11144@redhat.com> <1424338999.3641.13.camel@redhat.com> <54F9C1D7.8080407@oracle.com> Message-ID: <1425654690.3324.66.camel@redhat.com> Hi Magnus, On Fri, 2015-03-06 at 16:03 +0100, Magnus Ihse Bursie wrote: > Hi Severin and Omair, > > Sorry for not replying to this earlier. > > I agree that the handling of debug information in OpenJDK has not > properly addressed the needs of the Linux distribution community. :-( > > And even if this does not really help you, I can perhaps comfort you > slightly by saying that the needs of Oracle is not properly addressed > either. :-& > > So I'd really like to spend some effort of revamping the code related to > debug symbols, so that it properly aligns with the needs of all > interested parties. Your mail have brought the issue higher up on the > urgency list. > > I'm trying to get a proper description of all use cases that we need to > support. I'll get back to you when I have such a description, to check > that I have not misunderstood the needs of the linux distribution community. Thanks very much! I'm very much looking forward to your proposals. Which bug are you going to use to track this? This perhaps? https://bugs.openjdk.java.net/browse/JDK-8073461 Cheers, Severin > /Magnus > > On 2015-02-19 10:43, Severin Gehwolf wrote: > > Hi, > > > > On Wed, 2015-02-11 at 17:52 -0500, Omair Majid wrote: > >> Hi, > >> > >> * Omair Majid [2014-11-18 11:57]: > >>> * Magnus Ihse Bursie [2014-10-13 07:49]: > >>>> On 2014-10-13 10:57, Erik Joelsson wrote: > >>>>> I think it's still used by the hotspot makefiles (sa-jdi.jar). Seems weird > >>>>> that we still set it in configure but then ignore the value in the jdk > >>>>> build. I would vote for resurrecting the option. > >>>> [...] > >>>>> I'm not sure if even more debug levels is the right way to go. It seems > >>>>> hard to name and that probably means it will be hard to understand. > >>>>> Perhaps completely separating native debug level and java debug level > >>>>> would make more sense? > >>>> I'm not sure "resurrecting" (which actually means adding functionality which > >>>> has been gone for quite some time now) is good, since it adds to the > >>>> complexity. > >>> Well, we do need the debug information, but I am not at all tied to > >>> specific implementation. I would be happy to try and implement something > >>> that takes a different approach than resurrecting the feature. > >>> > >>>> However, there have been recurring requests of having more control of debug > >>>> vs release builds, and I think we need to address them in some way. > >>> Any suggestions for a suitable implementation? > >> Sorry to resurrect an old thread, but this just bit me again. > > I believe it is fair to say that this issue affects *all* Linux > > distributions attempting to build from an upstream OpenJDK tree. This is > > to stress that it's a significant issue and it keeps creeping up (the > > issue being debug symbols in Java class files and natives - hotspot and > > JDK). I'm *very* interested to help find a solution to this once and for > > all. > > > > FWIW, there are a couple of checks we perform that during Fedora OpenJDK > > builds in an attempt to ensure that hotspot debug symbols are there: > > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n1160 > > > > Similarly, Java debug info is checked this way: > > http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n1177 > > > > Wouldn't it be possible to add similar checks to the OpenJDK builds > > system? This is to ensure that it doesn't regress again. Thoughts? > > > > Finally, I've created this bug in order to track this: > > https://bugs.openjdk.java.net/browse/JDK-8073461 > > > > Thanks, > > Severin > > > From magnus.ihse.bursie at oracle.com Fri Mar 6 15:59:37 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 16:59:37 +0100 Subject: Unused DEBUG_CLASSFILES variable in makefiles In-Reply-To: <1425654690.3324.66.camel@redhat.com> References: <20141010165203.GE2698@redhat.com> <543B9414.1080108@oracle.com> <543BBF40.5050100@oracle.com> <20141118165732.GC4240@redhat.com> <20150211225223.GM11144@redhat.com> <1424338999.3641.13.camel@redhat.com> <54F9C1D7.8080407@oracle.com> <1425654690.3324.66.camel@redhat.com> Message-ID: <54F9CEE9.8010109@oracle.com> On 2015-03-06 16:11, Severin Gehwolf wrote: > Hi Magnus, > > On Fri, 2015-03-06 at 16:03 +0100, Magnus Ihse Bursie wrote: >> Hi Severin and Omair, >> >> Sorry for not replying to this earlier. >> >> I agree that the handling of debug information in OpenJDK has not >> properly addressed the needs of the Linux distribution community. :-( >> >> And even if this does not really help you, I can perhaps comfort you >> slightly by saying that the needs of Oracle is not properly addressed >> either. :-& >> >> So I'd really like to spend some effort of revamping the code related to >> debug symbols, so that it properly aligns with the needs of all >> interested parties. Your mail have brought the issue higher up on the >> urgency list. >> >> I'm trying to get a proper description of all use cases that we need to >> support. I'll get back to you when I have such a description, to check >> that I have not misunderstood the needs of the linux distribution community. > Thanks very much! I'm very much looking forward to your proposals. > > Which bug are you going to use to track this? This perhaps? > https://bugs.openjdk.java.net/browse/JDK-8073461 Sure, it's as good as any. :) /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 6 16:13:09 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 17:13:09 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F73337.3090309@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com> <54F71EB8.3030109@oracle.com> <54F73337.3090309@oracle.com> Message-ID: <54F9D215.8090806@oracle.com> On 2015-03-04 17:30, Alan Bateman wrote: > On 04/03/2015 15:03, Magnus Ihse Bursie wrote: >> I believe all warnings are important to check! Unfortunately, this >> has not been done for a lot of warnings for a lot of time. :( > Right, although in the past we had some areas close to be cleared of > warnings, it's just that we didn't keep up the effort and of course > the compilers get more pedantic with each version. > >> >> With this framework, it is simple to enable a single warning, >> recompile and see the effect. Hopefully this lowers the threshold far >> enough so that all warnings are given proper attention. The >> incremental build functionality will come in very handy. Just by >> simply removing a warning from the DISABLED_WARNINGS_ on a >> library and running "make" again, only the files affected will be >> recompiled. > Yes, it looks easy to maintain. > > >> >> I can easily paste in what warning categories are disabled for a >> specific library, yes. >> >> However, if you are asking me to build each library, individually, >> with warnings re-enabled, and pasting the output, I'd rather not. >> That would be a lot of work, to detangle the output of each >> individual library. > I'm not asking that, it would be too much work. Maybe it's worth > saving the logs somewhere so that you can point the bugs at it. It > would also be useful for the bugs to point to your change sets (when > they are pushed) so that it's obvious which make files were changed to > silence the warnings. I'll try to locate a suitable way of storing the logs, and record a pointer to that in the bugs. I'll also link to the change set in the bugs as you request. /Magnus > > -Alan From magnus.ihse.bursie at oracle.com Fri Mar 6 16:14:57 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 17:14:57 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F70949.4040900@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com> Message-ID: <54F9D281.3030206@oracle.com> On 2015-03-04 14:31, Erik Joelsson wrote: > Hello, > > Really nice to finally see this patch getting done! > > Only one comment: > > flags.m4: > In the grep expression, could you move the extra [] outside of the > actual command line options to grep so that the command line could be > copied to the shell for debugging in the future? Also, how hard would > it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead > test for capability? I have updated the fix to use the eminent FLAGS_COMPILER_CHECK_ARGUMENTS instead. :-) http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.02 /Magnus From tim.bell at oracle.com Fri Mar 6 16:43:17 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 06 Mar 2015 08:43:17 -0800 Subject: RFR: JDK-8074554 Create custom hook for running after AC_OUTPUT In-Reply-To: <54F9AFEA.4040000@oracle.com> References: <54F9AF51.1070005@oracle.com> <54F9AFEA.4040000@oracle.com> Message-ID: <54F9D925.9080308@oracle.com> Magnus: Looks good to me as well. Tim On 03/06/15 05:47, Erik Joelsson wrote: > Looks good to me. > > /Erik > > On 2015-03-06 14:44, Magnus Ihse Bursie wrote: >> The custom configure additions needs to be extended with a hook right >> after AC_OUTPUT. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074554 >> Patch inlined: >> >> diff --git a/common/autoconf/configure.ac b/common/autoconf/configure.ac >> --- a/common/autoconf/configure.ac >> +++ b/common/autoconf/configure.ac >> @@ -54,6 +54,7 @@ >> >> AC_DEFUN_ONCE([CUSTOM_EARLY_HOOK]) >> AC_DEFUN_ONCE([CUSTOM_LATE_HOOK]) >> +AC_DEFUN_ONCE([CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK]) >> AC_DEFUN_ONCE([CUSTOM_SUMMARY_AND_WARNINGS_HOOK]) >> >> # This line needs to be here, verbatim, after all includes and the >> dummy hook >> @@ -264,6 +265,7 @@ >> >> # Create the actual output files. Now the main work of configure is >> done. >> AC_OUTPUT >> +CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK >> >> # Try to move the config.log file to the output directory. >> if test -e ./config.log; then >> magnusi at sthihse3:/localhome/hg/jdk9-client-EXP$ >> >> I intend to push this to jdk9/client, not jdk9/dev. >> >> /Magnus > From rob.mckenna at oracle.com Fri Mar 6 17:31:47 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 06 Mar 2015 17:31:47 +0000 Subject: [8u-dev] Request for approval for JDK-8074554 Create custom hook for running after AC_OUTPUT In-Reply-To: <54F9BCA1.2020204@oracle.com> References: <54F9B510.4040509@oracle.com> <54F9B96A.8040004@oracle.com> <54F9BCA1.2020204@oracle.com> Message-ID: <54F9E483.3000208@oracle.com> Approved. Please add a suitable noreg keyword. -Rob On 06/03/15 14:41, Magnus Ihse Bursie wrote: > Requesting approval to backport this JDK9 fix to jdk8u-dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074554 > Original JDK9 changeset: > http://hg.openjdk.java.net/jdk9/client/rev/8b9bd5ba445e > > /Magnus > > On 2015-03-06 15:27, Erik Joelsson wrote: >> Looks good. >> >> /Erik >> >> On 2015-03-06 15:09, Magnus Ihse Bursie wrote: >>> Please review this backport of JDK-8074554 to 8u. While it did not >>> automatically apply cleanly, the difference was trivially resolved. >>> >>> diff --git a/common/autoconf/configure.ac >>> b/common/autoconf/configure.ac >>> --- a/common/autoconf/configure.ac >>> +++ b/common/autoconf/configure.ac >>> @@ -53,6 +53,7 @@ >>> >>> AC_DEFUN_ONCE([CUSTOM_EARLY_HOOK]) >>> AC_DEFUN_ONCE([CUSTOM_LATE_HOOK]) >>> +AC_DEFUN_ONCE([CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK]) >>> >>> # This line needs to be here, verbatim, after all includes and the >>> dummy hook >>> # definitions. It is replaced with custom functionality when building >>> @@ -237,6 +238,7 @@ >>> >>> # Create the actual output files. Now the main work of configure is >>> done. >>> AC_OUTPUT >>> +CUSTOM_CONFIG_OUTPUT_GENERATED_HOOK >>> >>> # Try to move the config.log file to the output directory. >>> if test -e ./config.log; then >>> >>> /Magnus >> > From tim.bell at oracle.com Fri Mar 6 18:30:22 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 06 Mar 2015 10:30:22 -0800 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54F9BEA6.3010700@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> Message-ID: <54F9F23E.1000606@oracle.com> On 03/06/15 06:50, Magnus Ihse Bursie wrote: > On 2015-03-04 22:03, Martin Buchholz wrote: >> I agree that configure should not mess with user's PATH and should >> "auto-find" programs in /usr/ccs/bin only as a last resort. >> >> It would be reasonable, when configure fails on Solaris, to notice >> that the >> user does not have /usr/ccs/bin on PATH and suggest appending. > > I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. > > Adding a warning to failed configure on Solaris due to missing build > tools that presumably resides in /usr/ccs/bin seems like quite a lot > of work. > > I suggest the following: > Instead of prepending, append /usr/ccs/bin, so any binaries in the > user's specified PATH are picked first. This will allow a properly set > PATH to function, but it will still provide the "best effort" approach > of configure to look in "well-known locations" for tools. > > Does that seem like an acceptable solution? Sounds good to me. Tim From martinrb at google.com Fri Mar 6 18:58:16 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Mar 2015 10:58:16 -0800 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54F9BEA6.3010700@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> Message-ID: On Fri, Mar 6, 2015 at 6:50 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2015-03-04 22:03, Martin Buchholz wrote: > >> I agree that configure should not mess with user's PATH and should >> "auto-find" programs in /usr/ccs/bin only as a last resort. >> >> It would be reasonable, when configure fails on Solaris, to notice that >> the >> user does not have /usr/ccs/bin on PATH and suggest appending. >> > > I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. > > Adding a warning to failed configure on Solaris due to missing build tools > that presumably resides in /usr/ccs/bin seems like quite a lot of work. > > I suggest the following: > Instead of prepending, append /usr/ccs/bin, so any binaries in the user's > specified PATH are picked first. This will allow a properly set PATH to > function, but it will still provide the "best effort" approach of configure > to look in "well-known locations" for tools. > > Does that seem like an acceptable solution? > > That does seem pretty reasonable, although it will fail if locations of programs are not converted to absolute paths during configure. Hopefully explicit flags or standard configure environment variables like CC will always override $PATH. > /Magnus > From magnus.ihse.bursie at oracle.com Fri Mar 6 19:17:16 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 6 Mar 2015 20:17:16 +0100 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> Message-ID: > 6 mar 2015 kl. 19:58 skrev Martin Buchholz : > > > >> On Fri, Mar 6, 2015 at 6:50 AM, Magnus Ihse Bursie wrote: >>> On 2015-03-04 22:03, Martin Buchholz wrote: >>> I agree that configure should not mess with user's PATH and should >>> "auto-find" programs in /usr/ccs/bin only as a last resort. >>> >>> It would be reasonable, when configure fails on Solaris, to notice that the >>> user does not have /usr/ccs/bin on PATH and suggest appending. >> >> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. >> >> Adding a warning to failed configure on Solaris due to missing build tools that presumably resides in /usr/ccs/bin seems like quite a lot of work. >> >> I suggest the following: >> Instead of prepending, append /usr/ccs/bin, so any binaries in the user's specified PATH are picked first. This will allow a properly set PATH to function, but it will still provide the "best effort" approach of configure to look in "well-known locations" for tools. >> >> Does that seem like an acceptable solution? > > That does seem pretty reasonable, although it will fail if locations of programs are not converted to absolute paths during configure. Hopefully explicit flags or standard configure environment variables like CC will always override $PATH. All tools detected by configure gets rewritten with an absolute path, all the time. Explicit overrides always have precedence. /Magnus > >> /Magnus > From dmitry.samersoff at oracle.com Fri Mar 6 19:17:59 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 06 Mar 2015 22:17:59 +0300 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54F9BEA6.3010700@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> Message-ID: <54F9FD67.5060301@oracle.com> Magnus, You can add a generic warning: if configure fails finding some tools and it's solaris then warn about /usr/ccs/bin that should be in a path end I'm against of altering PATH any way (appending or prepending anything) because it might lead to the situation where wrong tool is picked and it's hard to debug. -Dmitry On 2015-03-06 17:50, Magnus Ihse Bursie wrote: > On 2015-03-04 22:03, Martin Buchholz wrote: >> I agree that configure should not mess with user's PATH and should >> "auto-find" programs in /usr/ccs/bin only as a last resort. >> >> It would be reasonable, when configure fails on Solaris, to notice >> that the >> user does not have /usr/ccs/bin on PATH and suggest appending. > > I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. > > Adding a warning to failed configure on Solaris due to missing build > tools that presumably resides in /usr/ccs/bin seems like quite a lot of > work. > > I suggest the following: > Instead of prepending, append /usr/ccs/bin, so any binaries in the > user's specified PATH are picked first. This will allow a properly set > PATH to function, but it will still provide the "best effort" approach > of configure to look in "well-known locations" for tools. > > Does that seem like an acceptable solution? > > /Magnus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Sat Mar 7 02:18:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 07 Mar 2015 12:18:54 +1000 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54F9BEA6.3010700@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> Message-ID: <54FA600E.1090503@oracle.com> On 7/03/2015 12:50 AM, Magnus Ihse Bursie wrote: > On 2015-03-04 22:03, Martin Buchholz wrote: >> I agree that configure should not mess with user's PATH and should >> "auto-find" programs in /usr/ccs/bin only as a last resort. >> >> It would be reasonable, when configure fails on Solaris, to notice >> that the >> user does not have /usr/ccs/bin on PATH and suggest appending. > > I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. > > Adding a warning to failed configure on Solaris due to missing build > tools that presumably resides in /usr/ccs/bin seems like quite a lot of > work. > > I suggest the following: > Instead of prepending, append /usr/ccs/bin, so any binaries in the > user's specified PATH are picked first. This will allow a properly set > PATH to function, but it will still provide the "best effort" approach > of configure to look in "well-known locations" for tools. > > Does that seem like an acceptable solution? Yes if not for that fact that there seems to have been an explicit reason for pre-pending in the first place. But if noone can recall what that was ... Thanks, David > /Magnus From magnus.ihse.bursie at oracle.com Sat Mar 7 05:59:51 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 7 Mar 2015 06:59:51 +0100 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54FA600E.1090503@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> <54FA600E.1090503@oracle.com> Message-ID: <446CDEF2-4651-4488-B69E-923A9FB8FC8F@oracle.com> > 7 mar 2015 kl. 03:18 skrev David Holmes : > > > >> On 7/03/2015 12:50 AM, Magnus Ihse Bursie wrote: >>> On 2015-03-04 22:03, Martin Buchholz wrote: >>> I agree that configure should not mess with user's PATH and should >>> "auto-find" programs in /usr/ccs/bin only as a last resort. >>> >>> It would be reasonable, when configure fails on Solaris, to notice >>> that the >>> user does not have /usr/ccs/bin on PATH and suggest appending. >> >> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. >> >> Adding a warning to failed configure on Solaris due to missing build >> tools that presumably resides in /usr/ccs/bin seems like quite a lot of >> work. >> >> I suggest the following: >> Instead of prepending, append /usr/ccs/bin, so any binaries in the >> user's specified PATH are picked first. This will allow a properly set >> PATH to function, but it will still provide the "best effort" approach >> of configure to look in "well-known locations" for tools. >> >> Does that seem like an acceptable solution? > > Yes if not for that fact that there seems to have been an explicit reason for pre-pending in the first place. But if noone can recall what that was ... I think I know what it was but it is no longer relevant. The reason was to get the configure based build to work out of the box on certain machine configurations in Oracle, where the old build picked up tools from /usr/ccs/bin automatically. However, since Solaris machines in the Oracle setting should be using the devkit, this is no longer an issue. /Magnus > > Thanks, > David > >> /Magnus From magnus.ihse.bursie at oracle.com Sat Mar 7 06:09:33 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 7 Mar 2015 07:09:33 +0100 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54F9FD67.5060301@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> <54F9FD67.5060301@oracle.com> Message-ID: <7F744023-CF0C-45FF-B5A2-39FCA7D5576F@oracle.com> > 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff : > > Magnus, > > You can add a generic warning: > > if configure fails finding some tools and it's solaris > then > warn about /usr/ccs/bin that should be in a path > end This is exactly what I said would be technically hard to do. Much harder than what's justified for this issue. > > I'm against of altering PATH any way (appending or prepending anything) > because it might lead to the situation where wrong tool is picked and > it's hard to debug. I think we might just be misunderstanding each other here. Configure will not (and in fact cannot) alter the user's PATH in his/her environment. We do use the PATH as one way - but not the only way - to find tools needed to be able to build. One of the design goals of the configure script is "if the tool exist on the system, we should find it". This is to minimize the amount of configuration needed by the user. If you are worried that configure should find a tool that would work, but not be the exact version that you wanted, then you will have to point it out for configure, using eg. --with-devkit, --with-bootjdk, SED=, GREP= etc. So looking in /usr/ccs/bin instead of failing, is just like the rest of the processing configure does. /Magnus > > -Dmitry > > > >> On 2015-03-06 17:50, Magnus Ihse Bursie wrote: >>> On 2015-03-04 22:03, Martin Buchholz wrote: >>> I agree that configure should not mess with user's PATH and should >>> "auto-find" programs in /usr/ccs/bin only as a last resort. >>> >>> It would be reasonable, when configure fails on Solaris, to notice >>> that the >>> user does not have /usr/ccs/bin on PATH and suggest appending. >> >> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. >> >> Adding a warning to failed configure on Solaris due to missing build >> tools that presumably resides in /usr/ccs/bin seems like quite a lot of >> work. >> >> I suggest the following: >> Instead of prepending, append /usr/ccs/bin, so any binaries in the >> user's specified PATH are picked first. This will allow a properly set >> PATH to function, but it will still provide the "best effort" approach >> of configure to look in "well-known locations" for tools. >> >> Does that seem like an acceptable solution? >> >> /Magnus > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From erik.joelsson at oracle.com Mon Mar 9 09:08:54 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Mar 2015 10:08:54 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F9D281.3030206@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com> <54F9D281.3030206@oracle.com> Message-ID: <54FD6326.4070403@oracle.com> Thanks, looks good! /Erik On 2015-03-06 17:14, Magnus Ihse Bursie wrote: > On 2015-03-04 14:31, Erik Joelsson wrote: >> Hello, >> >> Really nice to finally see this patch getting done! >> >> Only one comment: >> >> flags.m4: >> In the grep expression, could you move the extra [] outside of the >> actual command line options to grep so that the command line could be >> copied to the shell for debugging in the future? Also, how hard would >> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead >> test for capability? > > I have updated the fix to use the eminent > FLAGS_COMPILER_CHECK_ARGUMENTS instead. :-) > > http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.02 > > > /Magnus > From erik.joelsson at oracle.com Mon Mar 9 11:16:55 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Mar 2015 12:16:55 +0100 Subject: RFR: JDK-8073021: add native code coverage target into makefiles Message-ID: <54FD8127.3040404@oracle.com> Hello, Please review this patch. A new configure parameter --enable-native-coverage is introduced. Setting it only works when using gcc, for now. It adds '-fprofile-arcs -ftest-coverage -fno-inline' to compiler flags and '-fprofile-arcs' to linker flags, for both jdk and hotspot native libraries (but not for native test libraries). Setting this causes gcc to generate code coverage instrumentation into the binaries as well as generating a .gcno file for each object file created. The gcno files are needed for converting gathered coverage data into a comprehensible report. When native coverage is active, a new image containing the .gcno files is created by the images target. Bug: https://bugs.openjdk.java.net/browse/JDK-8073021 Webrev: http://cr.openjdk.java.net/~erikj/8073021/webrev.root.01/ /Erik From magnus.ihse.bursie at oracle.com Mon Mar 9 11:31:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 09 Mar 2015 12:31:19 +0100 Subject: RFR: JDK-8073021: add native code coverage target into makefiles In-Reply-To: <54FD8127.3040404@oracle.com> References: <54FD8127.3040404@oracle.com> Message-ID: <54FD8487.9040006@oracle.com> On 2015-03-09 12:16, Erik Joelsson wrote: > Hello, > > Please review this patch. A new configure parameter > --enable-native-coverage is introduced. Setting it only works when > using gcc, for now. It adds '-fprofile-arcs -ftest-coverage > -fno-inline' to compiler flags and '-fprofile-arcs' to linker flags, > for both jdk and hotspot native libraries (but not for native test > libraries). Setting this causes gcc to generate code coverage > instrumentation into the binaries as well as generating a .gcno file > for each object file created. The gcno files are needed for converting > gathered coverage data into a comprehensible report. When native > coverage is active, a new image containing the .gcno files is created > by the images target. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073021 > Webrev: http://cr.openjdk.java.net/~erikj/8073021/webrev.root.01/ Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 9 11:46:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 09 Mar 2015 12:46:01 +0100 Subject: RFR: JDK-8074690 Fix for JDK-8074429 was not complete Message-ID: <54FD87F9.3030604@oracle.com> The fix for JDK-8074429 moved the jar tool into a new jdk.jartool module. However, it did not remove all references from the old module. Gensrc-jdk.dev.gmk still references the old jar path, which is no longer valid. Bug: https://bugs.openjdk.java.net/browse/JDK-8074690 Patch inline: diff --git a/make/gensrc/Gensrc-jdk.dev.gmk b/make/gensrc/Gensrc-jdk.dev.gmk --- a/make/gensrc/Gensrc-jdk.dev.gmk +++ b/make/gensrc/Gensrc-jdk.dev.gmk @@ -32,8 +32,7 @@ $(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, \ $(filter %.properties, \ $(call CacheFind, \ - $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources \ - $(JDK_TOPDIR)/src/jdk.dev/share/classes/sun/tools/jar/resources)), \ + $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources)), \ ListResourceBundle)) TARGETS += $(COMPILE_PROPERTIES) /Magnus From Alan.Bateman at oracle.com Mon Mar 9 11:50:13 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 09 Mar 2015 11:50:13 +0000 Subject: RFR: JDK-8074690 Fix for JDK-8074429 was not complete In-Reply-To: <54FD87F9.3030604@oracle.com> References: <54FD87F9.3030604@oracle.com> Message-ID: <54FD88F5.1040200@oracle.com> On 09/03/2015 11:46, Magnus Ihse Bursie wrote: > The fix for JDK-8074429 > moved the jar tool > into a new jdk.jartool module. > > However, it did not remove all references from the old module. > Gensrc-jdk.dev.gmk still references the old jar path, which is no > longer valid. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074690 > Patch inline: > diff --git a/make/gensrc/Gensrc-jdk.dev.gmk > b/make/gensrc/Gensrc-jdk.dev.gmk > --- a/make/gensrc/Gensrc-jdk.dev.gmk > +++ b/make/gensrc/Gensrc-jdk.dev.gmk > @@ -32,8 +32,7 @@ > $(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, \ > $(filter %.properties, \ > $(call CacheFind, \ > - $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources \ > - $(JDK_TOPDIR)/src/jdk.dev/share/classes/sun/tools/jar/resources)), \ > + $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources)), \ > ListResourceBundle)) This looks okay to me, very easy to leave references when it doesn't cause a warning or failure. -Alan From magnus.ihse.bursie at oracle.com Mon Mar 9 12:09:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 09 Mar 2015 13:09:28 +0100 Subject: RFR: JDK-8074690 Fix for JDK-8074429 was not complete In-Reply-To: <54FD88F5.1040200@oracle.com> References: <54FD87F9.3030604@oracle.com> <54FD88F5.1040200@oracle.com> Message-ID: <54FD8D78.1090908@oracle.com> On 2015-03-09 12:50, Alan Bateman wrote: > > > On 09/03/2015 11:46, Magnus Ihse Bursie wrote: >> The fix for JDK-8074429 >> moved the jar tool >> into a new jdk.jartool module. >> >> However, it did not remove all references from the old module. >> Gensrc-jdk.dev.gmk still references the old jar path, which is no >> longer valid. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074690 >> Patch inline: >> diff --git a/make/gensrc/Gensrc-jdk.dev.gmk >> b/make/gensrc/Gensrc-jdk.dev.gmk >> --- a/make/gensrc/Gensrc-jdk.dev.gmk >> +++ b/make/gensrc/Gensrc-jdk.dev.gmk >> @@ -32,8 +32,7 @@ >> $(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, \ >> $(filter %.properties, \ >> $(call CacheFind, \ >> - $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources \ >> - $(JDK_TOPDIR)/src/jdk.dev/share/classes/sun/tools/jar/resources)), \ >> + >> $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources)), \ >> ListResourceBundle)) > This looks okay to me, very easy to leave references when it doesn't > cause a warning or failure. It did leave a warning, though (that's how I noticed it): /usr/bin/find: `/localhome/hg/jdk9-dev-BAR/jdk/src/jdk.dev/share/classes/sun/tools/jar/resources': No such file or directory But as you said, it didn't cause a failure. Maybe we should tighten the implementation on CacheFind to catch invalid paths. /Magnus From erik.joelsson at oracle.com Mon Mar 9 14:53:11 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Mar 2015 15:53:11 +0100 Subject: RFR: JDK-8074690 Fix for JDK-8074429 was not complete In-Reply-To: <54FD87F9.3030604@oracle.com> References: <54FD87F9.3030604@oracle.com> Message-ID: <54FDB3D7.8080808@oracle.com> Looks good. /Erik On 2015-03-09 12:46, Magnus Ihse Bursie wrote: > The fix for JDK-8074429 > moved the jar tool > into a new jdk.jartool module. > > However, it did not remove all references from the old module. > Gensrc-jdk.dev.gmk still references the old jar path, which is no > longer valid. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074690 > Patch inline: > diff --git a/make/gensrc/Gensrc-jdk.dev.gmk > b/make/gensrc/Gensrc-jdk.dev.gmk > --- a/make/gensrc/Gensrc-jdk.dev.gmk > +++ b/make/gensrc/Gensrc-jdk.dev.gmk > @@ -32,8 +32,7 @@ > $(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, \ > $(filter %.properties, \ > $(call CacheFind, \ > - $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources \ > - $(JDK_TOPDIR)/src/jdk.dev/share/classes/sun/tools/jar/resources)), \ > + $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources)), \ > ListResourceBundle)) > > TARGETS += $(COMPILE_PROPERTIES) > > /Magnus From tim.bell at oracle.com Mon Mar 9 15:13:41 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 09 Mar 2015 08:13:41 -0700 Subject: RFR: JDK-8073021: add native code coverage target into makefiles In-Reply-To: <54FD8487.9040006@oracle.com> References: <54FD8127.3040404@oracle.com> <54FD8487.9040006@oracle.com> Message-ID: <54FDB8A5.1020204@oracle.com> Erik: >> Hello, >> >> Please review this patch. A new configure parameter >> --enable-native-coverage is introduced. Setting it only works when >> using gcc, for now. It adds '-fprofile-arcs -ftest-coverage >> -fno-inline' to compiler flags and '-fprofile-arcs' to linker flags, >> for both jdk and hotspot native libraries (but not for native test >> libraries). Setting this causes gcc to generate code coverage >> instrumentation into the binaries as well as generating a .gcno file >> for each object file created. The gcno files are needed for >> converting gathered coverage data into a comprehensible report. When >> native coverage is active, a new image containing the .gcno files is >> created by the images target. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073021 >> Webrev: http://cr.openjdk.java.net/~erikj/8073021/webrev.root.01/ > > Looks good to me. > > /Magnus Looks good to me as well. Tim From mandy.chung at oracle.com Mon Mar 9 16:18:04 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 09 Mar 2015 09:18:04 -0700 Subject: RFR: JDK-8074690 Fix for JDK-8074429 was not complete In-Reply-To: <54FD87F9.3030604@oracle.com> References: <54FD87F9.3030604@oracle.com> Message-ID: <54FDC7BC.5000704@oracle.com> On 3/9/15 4:46 AM, Magnus Ihse Bursie wrote: > The fix for JDK-8074429 > moved the jar tool > into a new jdk.jartool module. > > However, it did not remove all references from the old module. > Gensrc-jdk.dev.gmk still references the old jar path, which is no > longer valid. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074690 > Patch inline: > diff --git a/make/gensrc/Gensrc-jdk.dev.gmk > b/make/gensrc/Gensrc-jdk.dev.gmk > --- a/make/gensrc/Gensrc-jdk.dev.gmk > +++ b/make/gensrc/Gensrc-jdk.dev.gmk > @@ -32,8 +32,7 @@ > $(eval $(call SetupCompileProperties,COMPILE_PROPERTIES, \ > $(filter %.properties, \ > $(call CacheFind, \ > - $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources \ > - $(JDK_TOPDIR)/src/jdk.dev/share/classes/sun/tools/jar/resources)), \ > + $(JDK_TOPDIR)/src/jdk.dev/share/classes/jdk/tools/jimage/resources)), \ > ListResourceBundle)) > > TARGETS += $(COMPILE_PROPERTIES) Looks good. Thanks for the follow-up fix. Sorry for missing this reference. Mandy From martinrb at google.com Mon Mar 9 17:03:28 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Mar 2015 10:03:28 -0700 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <7F744023-CF0C-45FF-B5A2-39FCA7D5576F@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> <54F9FD67.5060301@oracle.com> <7F744023-CF0C-45FF-B5A2-39FCA7D5576F@oracle.com> Message-ID: I support Magnus' strategy. Slightly unrelated, /usr/ccs/bin is a very old directory, and ISTR that it was slowly going away. On SunOS 5.10 I see a cornucopia of nm's muddying the waters: /usr/ccs/bin/sparcv9/nm /usr/ccs/bin/nm /usr/xpg4/bin/nm /usr/sfw/sparc-sun-solaris2.10/bin/nm On Fri, Mar 6, 2015 at 10:09 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > > 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff >: > > > > Magnus, > > > > You can add a generic warning: > > > > if configure fails finding some tools and it's solaris > > then > > warn about /usr/ccs/bin that should be in a path > > end > > This is exactly what I said would be technically hard to do. Much harder > than what's justified for this issue. > > > > > I'm against of altering PATH any way (appending or prepending anything) > > because it might lead to the situation where wrong tool is picked and > > it's hard to debug. > > I think we might just be misunderstanding each other here. Configure will > not (and in fact cannot) alter the user's PATH in his/her environment. > > We do use the PATH as one way - but not the only way - to find tools > needed to be able to build. One of the design goals of the configure script > is "if the tool exist on the system, we should find it". This is to > minimize the amount of configuration needed by the user. > > If you are worried that configure should find a tool that would work, but > not be the exact version that you wanted, then you will have to point it > out for configure, using eg. --with-devkit, --with-bootjdk, SED=, GREP= etc. > > So looking in /usr/ccs/bin instead of failing, is just like the rest of > the processing configure does. > > /Magnus > > > > > -Dmitry > > > > > > > >> On 2015-03-06 17:50, Magnus Ihse Bursie wrote: > >>> On 2015-03-04 22:03, Martin Buchholz wrote: > >>> I agree that configure should not mess with user's PATH and should > >>> "auto-find" programs in /usr/ccs/bin only as a last resort. > >>> > >>> It would be reasonable, when configure fails on Solaris, to notice > >>> that the > >>> user does not have /usr/ccs/bin on PATH and suggest appending. > >> > >> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. > >> > >> Adding a warning to failed configure on Solaris due to missing build > >> tools that presumably resides in /usr/ccs/bin seems like quite a lot of > >> work. > >> > >> I suggest the following: > >> Instead of prepending, append /usr/ccs/bin, so any binaries in the > >> user's specified PATH are picked first. This will allow a properly set > >> PATH to function, but it will still provide the "best effort" approach > >> of configure to look in "well-known locations" for tools. > >> > >> Does that seem like an acceptable solution? > >> > >> /Magnus > > > > > > -- > > Dmitry Samersoff > > Oracle Java development team, Saint Petersburg, Russia > > * I would love to change the world, but they won't give me the sources. > From dmitry.samersoff at oracle.com Mon Mar 9 18:06:31 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 09 Mar 2015 21:06:31 +0300 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <7F744023-CF0C-45FF-B5A2-39FCA7D5576F@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> <54F9FD67.5060301@oracle.com> <7F744023-CF0C-45FF-B5A2-39FCA7D5576F@oracle.com> Message-ID: <54FDE127.1060901@oracle.com> Magnus, On 2015-03-07 09:09, Magnus Ihse Bursie wrote: > >> 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff : >> >> Magnus, >> >> You can add a generic warning: >> >> if configure fails finding some tools and it's solaris >> then >> warn about /usr/ccs/bin that should be in a path >> end > > This is exactly what I said would be technically hard to do. Much harder than what's justified for this issue. What about if configure fails for any reason and it's solaris then warn about /usr/ccs/bin that should be in a path end or ever if /usr/ccs/bin is not in the path and it's solaris then warn about /usr/ccs/bin that should be in a path end >> I'm against of altering PATH any way (appending or prepending anything) >> because it might lead to the situation where wrong tool is picked and >> it's hard to debug. > > I think we might just be misunderstanding each other here. Configure will not (and in fact cannot) alter the user's PATH in his/her environment. > > We do use the PATH as one way - but not the only way - to find tools needed to be able to build. One of the design goals of the configure script is "if the tool exist on the system, we should find it". This is to minimize the amount of configuration needed by the user. > > If you are worried that configure should find a tool that would work, but not be the exact version that you wanted, then you will have to point it out for configure, using eg. --with-devkit, --with-bootjdk, SED=, GREP= etc. > > So looking in /usr/ccs/bin instead of failing, is just like the rest of the processing configure does. If configure picks (e.g.) wrong *nm* it can cause a fail when linker attempts to apply version script and at this stage it is not obvious what is going wrong. So I still against of altering user PATH. -Dmitry > > /Magnus > >> >> -Dmitry >> >> >> >>> On 2015-03-06 17:50, Magnus Ihse Bursie wrote: >>>> On 2015-03-04 22:03, Martin Buchholz wrote: >>>> I agree that configure should not mess with user's PATH and should >>>> "auto-find" programs in /usr/ccs/bin only as a last resort. >>>> >>>> It would be reasonable, when configure fails on Solaris, to notice >>>> that the >>>> user does not have /usr/ccs/bin on PATH and suggest appending. >>> >>> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. >>> >>> Adding a warning to failed configure on Solaris due to missing build >>> tools that presumably resides in /usr/ccs/bin seems like quite a lot of >>> work. >>> >>> I suggest the following: >>> Instead of prepending, append /usr/ccs/bin, so any binaries in the >>> user's specified PATH are picked first. This will allow a properly set >>> PATH to function, but it will still provide the "best effort" approach >>> of configure to look in "well-known locations" for tools. >>> >>> Does that seem like an acceptable solution? >>> >>> /Magnus >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Mar 9 18:20:59 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 09 Mar 2015 21:20:59 +0300 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> <54F9FD67.5060301@oracle.com> <7F744023-CF0C-45FF-B5A2-39FCA7D5576F@oracle.com> Message-ID: <54FDE48B.1070204@oracle.com> Martin, if we *append* /usr/ccs/bin to the path we are in risk that configure picks GNU tool instead of solaris one. if we *prepend* /usr/ccs/bin to the path we lost an ability to override /usr/ccs/bin tool with user-supplied one. So both solutions above looks bad for me. And yes, this all is mostly about *nm* -Dmitry On 2015-03-09 20:03, Martin Buchholz wrote: > I support Magnus' strategy. > > Slightly unrelated, /usr/ccs/bin is a very old directory, and ISTR that > it was slowly going away. > > On SunOS 5.10 I see a cornucopia of nm's muddying the waters: > /usr/ccs/bin/sparcv9/nm > /usr/ccs/bin/nm > /usr/xpg4/bin/nm > /usr/sfw/sparc-sun-solaris2.10/bin/nm > > > On Fri, Mar 6, 2015 at 10:09 PM, Magnus Ihse Bursie > > > wrote: > > > > 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff > >: > > > > Magnus, > > > > You can add a generic warning: > > > > if configure fails finding some tools and it's solaris > > then > > warn about /usr/ccs/bin that should be in a path > > end > > This is exactly what I said would be technically hard to do. Much > harder than what's justified for this issue. > > > > > I'm against of altering PATH any way (appending or prepending anything) > > because it might lead to the situation where wrong tool is picked and > > it's hard to debug. > > I think we might just be misunderstanding each other here. Configure > will not (and in fact cannot) alter the user's PATH in his/her > environment. > > We do use the PATH as one way - but not the only way - to find tools > needed to be able to build. One of the design goals of the configure > script is "if the tool exist on the system, we should find it". This > is to minimize the amount of configuration needed by the user. > > If you are worried that configure should find a tool that would > work, but not be the exact version that you wanted, then you will > have to point it out for configure, using eg. --with-devkit, > --with-bootjdk, SED=, GREP= etc. > > So looking in /usr/ccs/bin instead of failing, is just like the rest > of the processing configure does. > > /Magnus > > > > > -Dmitry > > > > > > > >> On 2015-03-06 17:50, Magnus Ihse Bursie wrote: > >>> On 2015-03-04 22:03, Martin Buchholz wrote: > >>> I agree that configure should not mess with user's PATH and should > >>> "auto-find" programs in /usr/ccs/bin only as a last resort. > >>> > >>> It would be reasonable, when configure fails on Solaris, to notice > >>> that the > >>> user does not have /usr/ccs/bin on PATH and suggest appending. > >> > >> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. > >> > >> Adding a warning to failed configure on Solaris due to missing build > >> tools that presumably resides in /usr/ccs/bin seems like quite a > lot of > >> work. > >> > >> I suggest the following: > >> Instead of prepending, append /usr/ccs/bin, so any binaries in the > >> user's specified PATH are picked first. This will allow a > properly set > >> PATH to function, but it will still provide the "best effort" > approach > >> of configure to look in "well-known locations" for tools. > >> > >> Does that seem like an acceptable solution? > >> > >> /Magnus > > > > > > -- > > Dmitry Samersoff > > Oracle Java development team, Saint Petersburg, Russia > > * I would love to change the world, but they won't give me the > sources. > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From igor.ignatyev at oracle.com Mon Mar 9 12:03:40 2015 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Mon, 09 Mar 2015 15:03:40 +0300 Subject: =?utf-8?B?UmU6IFJGUjogSkRLLTgwNzMwMjE6IGFkZCBuYXRpdmUgY29kZSBjb3ZlcmFnZSB0?= =?utf-8?B?YXJnZXQgaW50byBtYWtlZmlsZXM=?= Message-ID: <201503091203.t29C3qF5017905@aserv0122.oracle.com> Look good to me. -- II ----- Reply message ----- From: "Magnus Ihse Bursie" To: "Erik Joelsson" , "build-dev" , "hotspot-dev developers" Subject: RFR: JDK-8073021: add native code coverage target into makefiles Date: Mon, Mar 9, 2015 14:31 On 2015-03-09 12:16, Erik Joelsson wrote: > Hello, > > Please review this patch. A new configure parameter > --enable-native-coverage is introduced. Setting it only works when > using gcc, for now. It adds '-fprofile-arcs -ftest-coverage > -fno-inline' to compiler flags and '-fprofile-arcs' to linker flags, > for both jdk and hotspot native libraries (but not for native test > libraries). Setting this causes gcc to generate code coverage > instrumentation into the binaries as well as generating a .gcno file > for each object file created. The gcno files are needed for converting > gathered coverage data into a comprehensible report. When native > coverage is active, a new image containing the .gcno files is created > by the images target. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073021 > Webrev: http://cr.openjdk.java.net/~erikj/8073021/webrev.root.01/ Looks good to me. /Magnus From martinrb at google.com Mon Mar 9 19:12:08 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Mar 2015 12:12:08 -0700 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54FDE48B.1070204@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> <54F9FD67.5060301@oracle.com> <7F744023-CF0C-45FF-B5A2-39FCA7D5576F@oracle.com> <54FDE48B.1070204@oracle.com> Message-ID: If the user has not explicitly provided an nm (i.e. almost always) then it makes sense for the configure script to test the nm that may be on the PATH, and if that's definitely not good enough (are you sure? gnu nm also supports linker scripts), fall back to /usr/ccs/bin/nm. On Mon, Mar 9, 2015 at 11:20 AM, Dmitry Samersoff < dmitry.samersoff at oracle.com> wrote: > Martin, > > if we *append* /usr/ccs/bin to the path we are in risk that configure > picks GNU tool instead of solaris one. > > if we *prepend* /usr/ccs/bin to the path we lost an ability to override > /usr/ccs/bin tool with user-supplied one. > > So both solutions above looks bad for me. > > And yes, this all is mostly about *nm* > > -Dmitry > > > On 2015-03-09 20:03, Martin Buchholz wrote: > > I support Magnus' strategy. > > > > Slightly unrelated, /usr/ccs/bin is a very old directory, and ISTR that > > it was slowly going away. > > > > On SunOS 5.10 I see a cornucopia of nm's muddying the waters: > > /usr/ccs/bin/sparcv9/nm > > /usr/ccs/bin/nm > > /usr/xpg4/bin/nm > > /usr/sfw/sparc-sun-solaris2.10/bin/nm > > > > > > On Fri, Mar 6, 2015 at 10:09 PM, Magnus Ihse Bursie > > > > > wrote: > > > > > > > 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff > > >: > > > > > > Magnus, > > > > > > You can add a generic warning: > > > > > > if configure fails finding some tools and it's solaris > > > then > > > warn about /usr/ccs/bin that should be in a path > > > end > > > > This is exactly what I said would be technically hard to do. Much > > harder than what's justified for this issue. > > > > > > > > I'm against of altering PATH any way (appending or prepending > anything) > > > because it might lead to the situation where wrong tool is picked > and > > > it's hard to debug. > > > > I think we might just be misunderstanding each other here. Configure > > will not (and in fact cannot) alter the user's PATH in his/her > > environment. > > > > We do use the PATH as one way - but not the only way - to find tools > > needed to be able to build. One of the design goals of the configure > > script is "if the tool exist on the system, we should find it". This > > is to minimize the amount of configuration needed by the user. > > > > If you are worried that configure should find a tool that would > > work, but not be the exact version that you wanted, then you will > > have to point it out for configure, using eg. --with-devkit, > > --with-bootjdk, SED=, GREP= etc. > > > > So looking in /usr/ccs/bin instead of failing, is just like the rest > > of the processing configure does. > > > > /Magnus > > > > > > > > -Dmitry > > > > > > > > > > > >> On 2015-03-06 17:50, Magnus Ihse Bursie wrote: > > >>> On 2015-03-04 22:03, Martin Buchholz wrote: > > >>> I agree that configure should not mess with user's PATH and > should > > >>> "auto-find" programs in /usr/ccs/bin only as a last resort. > > >>> > > >>> It would be reasonable, when configure fails on Solaris, to > notice > > >>> that the > > >>> user does not have /usr/ccs/bin on PATH and suggest appending. > > >> > > >> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. > > >> > > >> Adding a warning to failed configure on Solaris due to missing > build > > >> tools that presumably resides in /usr/ccs/bin seems like quite a > > lot of > > >> work. > > >> > > >> I suggest the following: > > >> Instead of prepending, append /usr/ccs/bin, so any binaries in the > > >> user's specified PATH are picked first. This will allow a > > properly set > > >> PATH to function, but it will still provide the "best effort" > > approach > > >> of configure to look in "well-known locations" for tools. > > >> > > >> Does that seem like an acceptable solution? > > >> > > >> /Magnus > > > > > > > > > -- > > > Dmitry Samersoff > > > Oracle Java development team, Saint Petersburg, Russia > > > * I would love to change the world, but they won't give me the > > sources. > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > From david.holmes at oracle.com Tue Mar 10 06:06:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 16:06:03 +1000 Subject: Tracking hotspot dependencies in a full build ? Message-ID: <54FE89CB.2080504@oracle.com> Did a full build (images) then edited a hotspot header file, ran "make images" again and nothing was updated. :( Is there something missing from the dependency management here? Is it the lack of full integration of the hotspot build into the full build? Any suggestions on what I can delete to force things to rebuild (short of doing a clean of course) Thanks, David From david.holmes at oracle.com Tue Mar 10 06:21:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 16:21:37 +1000 Subject: Tracking hotspot dependencies in a full build ? In-Reply-To: <54FE89CB.2080504@oracle.com> References: <54FE89CB.2080504@oracle.com> Message-ID: <54FE8D71.5050802@oracle.com> Please ignore - user error. I was observing the "silence of the logs" with the 9 build. I've been building 7 and 8 lately and was expecting something noisier :) David On 10/03/2015 4:06 PM, David Holmes wrote: > Did a full build (images) then edited a hotspot header file, ran "make > images" again and nothing was updated. :( > > Is there something missing from the dependency management here? Is it > the lack of full integration of the hotspot build into the full build? > > Any suggestions on what I can delete to force things to rebuild (short > of doing a clean of course) > > Thanks, > David From magnus.ihse.bursie at oracle.com Tue Mar 10 08:06:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 10 Mar 2015 09:06:05 +0100 Subject: Use of /usr/ccs/bin on Solaris In-Reply-To: <54FDE48B.1070204@oracle.com> References: <54F64DDB.3010605@oracle.com> <54F6C131.6020303@oracle.com> <54F6C2E6.5040601@oracle.com> <54F9BEA6.3010700@oracle.com> <54F9FD67.5060301@oracle.com> <7F744023-CF0C-45FF-B5A2-39FCA7D5576F@oracle.com> <54FDE48B.1070204@oracle.com> Message-ID: <54FEA5ED.6080107@oracle.com> On 2015-03-09 19:20, Dmitry Samersoff wrote: > Martin, > > if we *append* /usr/ccs/bin to the path we are in risk that configure > picks GNU tool instead of solaris one. It is the resonsiblitiy of the configure script to make sure the proper tool is located. Sometimes version checks etc are needed, and if we at first detect a tool that seemed to be correct but not is suitable (e.g. like when we find a too old jdk), then configure will have to continue looking. For the "simple" tools, normally we'd just need to find a binary with the correct name. With more "complex" tools, like the compiler, we need to take additional steps to make sure we have located the correct tool. It might turn out to be the same for some tools in /usr/ccs/bin, like nm. /Magnus From kumar.x.srinivasan at oracle.com Tue Mar 10 17:23:48 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 10 Mar 2015 10:23:48 -0700 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54FF28A4.9080303@oracle.com> The changes look ok to me, however I am wondering if the module could be called jdk.unpack200 and not jdk.pack200 ? since it contains only the unpacker, and the bin utilities are pack200 and unpack200. Kumar On 3/4/2015 5:13 PM, Mandy Chung wrote: > As listed in an open issue in JEP 200: > > The jdk.dev and jdk.runtime modules contain miscellaneous tools that do > not obviously belong to any other module; these modules will eventually > be either renamed or refactored. > > Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in > the JDK that are organized around its primary tool. Such organization > is easy to name, document and understand. This patch proposes to > move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, > jdk.policytool modules. > > Overall Webrev that will be convenient to review the build change > and modules.xml change. > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > > There are remaining tools in jdk.dev that will be handled separately. > jdk.dev will disappear when all of the remaining tools find its home. > > Mandy > From philip.race at oracle.com Tue Mar 10 22:44:16 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 10 Mar 2015 15:44:16 -0700 Subject: RFR: 8074910 hgforest.sh needs an option to bring over a smaller set of extra repos Message-ID: <54FF73C0.6090009@oracle.com> Right now to get the extra repos you do sh get_source.sh http://server.whatits.org This gets more than most people need which wastes time and disk. Here is a small change such that you can now do sh get_source.sh jdk http://server.whatits.org ie add "jdk" to indicate you'd like only the repos needed to build JDK. If you decide later you want them all, just repeat using the old form. If you are unaware of the new arg, nothing changes. https://bugs.openjdk.java.net/browse/JDK-8074910 http://cr.openjdk.java.net/~prr/8074910/ -phil. From erik.joelsson at oracle.com Wed Mar 11 08:55:30 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Mar 2015 09:55:30 +0100 Subject: RFR: 8074910 hgforest.sh needs an option to bring over a smaller set of extra repos In-Reply-To: <54FF73C0.6090009@oracle.com> References: <54FF73C0.6090009@oracle.com> Message-ID: <55000302.4010500@oracle.com> Hello, Line 187 looks like debug output left about. Perhaps also 219 but I think that echo makes sense to keep. Otherwise looks good to me. /Erik On 2015-03-10 23:44, Phil Race wrote: > > Right now to get the extra repos you do > sh get_source.sh http://server.whatits.org > > This gets more than most people need which wastes time and disk. > Here is a small change such that you can now do > > sh get_source.sh jdk http://server.whatits.org > > ie add "jdk" to indicate you'd like only the repos needed to build JDK. > > If you decide later you want them all, just repeat using the old form. > > If you are unaware of the new arg, nothing changes. > > https://bugs.openjdk.java.net/browse/JDK-8074910 > http://cr.openjdk.java.net/~prr/8074910/ > > -phil. From chris.hegarty at oracle.com Wed Mar 11 14:16:07 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 Mar 2015 14:16:07 +0000 Subject: RFR: 8074910 hgforest.sh needs an option to bring over a smaller set of extra repos In-Reply-To: <55000302.4010500@oracle.com> References: <54FF73C0.6090009@oracle.com> <55000302.4010500@oracle.com> Message-ID: <55004E27.5020007@oracle.com> Thank you Phil, doing something along the lines of this has been on my list for a while now. On 11/03/15 08:55, Erik Joelsson wrote: > Hello, > > Line 187 looks like debug output left about. Perhaps also 219 but I > think that echo makes sense to keep. Otherwise looks good to me. +1. -Chris. > /Erik > > On 2015-03-10 23:44, Phil Race wrote: >> >> Right now to get the extra repos you do >> sh get_source.sh http://server.whatits.org >> >> This gets more than most people need which wastes time and disk. >> Here is a small change such that you can now do >> >> sh get_source.sh jdk http://server.whatits.org >> >> ie add "jdk" to indicate you'd like only the repos needed to build JDK. >> >> If you decide later you want them all, just repeat using the old form. >> >> If you are unaware of the new arg, nothing changes. >> >> https://bugs.openjdk.java.net/browse/JDK-8074910 >> http://cr.openjdk.java.net/~prr/8074910/ >> >> -phil. > From philip.race at oracle.com Wed Mar 11 15:25:42 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Mar 2015 08:25:42 -0700 Subject: RFR: 8074910 hgforest.sh needs an option to bring over a smaller set of extra repos In-Reply-To: <55000302.4010500@oracle.com> References: <54FF73C0.6090009@oracle.com> <55000302.4010500@oracle.com> Message-ID: <55005E76.4050103@oracle.com> OK I will remove 187 before pushing, but yes 219 was intentional ... -phil. On 3/11/2015 1:55 AM, Erik Joelsson wrote: > Hello, > > Line 187 looks like debug output left about. Perhaps also 219 but I > think that echo makes sense to keep. Otherwise looks good to me. > > /Erik > > On 2015-03-10 23:44, Phil Race wrote: >> >> Right now to get the extra repos you do >> sh get_source.sh http://server.whatits.org >> >> This gets more than most people need which wastes time and disk. >> Here is a small change such that you can now do >> >> sh get_source.sh jdk http://server.whatits.org >> >> ie add "jdk" to indicate you'd like only the repos needed to build JDK. >> >> If you decide later you want them all, just repeat using the old form. >> >> If you are unaware of the new arg, nothing changes. >> >> https://bugs.openjdk.java.net/browse/JDK-8074910 >> http://cr.openjdk.java.net/~prr/8074910/ >> >> -phil. > From erik.joelsson at oracle.com Wed Mar 11 15:47:29 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Mar 2015 16:47:29 +0100 Subject: RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions Message-ID: <55006391.7060301@oracle.com> (including nashorn-dev since a makefile there is touched) When creating a Setup* macro that takes named parameters, like SetupJavaCompilation, there is a lot of copied boilerplate code that needs to be written. The code, which is essentially copied for all these macro definitions, handles converting the named parameters into local variables and some debugging features. Here is SetupJavaCompilation as an example: define SetupJavaCompilation $(if $(16),$(error Internal makefile error: Too many arguments to SetupJavaCompilation, please update JavaCompilation.gmk)) $(call EvalDebugWrapper,$(strip $1),$(call SetupJavaCompilationInner,$(strip $1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))) endef define SetupJavaCompilationInner $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip $($i)),$1_$(strip $($i)))$(NEWLINE)) $(call LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)) $(if $(16),$(error Internal makefile error: Too many arguments to SetupJavaCompilation, please update JavaCompilation.gmk)) ... endef I have figured out a way to reduce this boilerplate significantly, massively reducing the overhead and resistance for creating new macros. The logic for converting the named parameters and all the debugging features are now defined only once in MakeBase.gmk. The corresponding declaration of SetupJavaCompilation is reduced to this: SetupJavaCompilation = $(NamedParamsMacroTemplate) define SetupJavaCompilationBody ... endef Bug: https://bugs.openjdk.java.net/browse/JDK-8074988 Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01/ /Erik From tim.bell at oracle.com Wed Mar 11 16:24:03 2015 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 11 Mar 2015 09:24:03 -0700 Subject: RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions In-Reply-To: <55006391.7060301@oracle.com> References: <55006391.7060301@oracle.com> Message-ID: <55006C23.9050401@oracle.com> Erik: > (including nashorn-dev since a makefile there is touched) > > When creating a Setup* macro that takes named parameters, like > SetupJavaCompilation, there is a lot of copied boilerplate code that > needs to be written. The code, which is essentially copied for all > these macro definitions, handles converting the named parameters into > local variables and some debugging features. Here is > SetupJavaCompilation as an example: > > define SetupJavaCompilation > $(if $(16),$(error Internal makefile error: Too many arguments to > SetupJavaCompilation, please update JavaCompilation.gmk)) > $(call EvalDebugWrapper,$(strip $1),$(call > SetupJavaCompilationInner,$(strip > $1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))) > endef > > define SetupJavaCompilationInner > $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip > $($i)),$1_$(strip $($i)))$(NEWLINE)) > $(call > LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)) > $(if $(16),$(error Internal makefile error: Too many arguments to > SetupJavaCompilation, please update JavaCompilation.gmk)) > ... > endef > > > I have figured out a way to reduce this boilerplate significantly, > massively reducing the overhead and resistance for creating new > macros. The logic for converting the named parameters and all the > debugging features are now defined only once in MakeBase.gmk. The > corresponding declaration of SetupJavaCompilation is reduced to this: > > SetupJavaCompilation = $(NamedParamsMacroTemplate) > define SetupJavaCompilationBody > ... > endef > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074988 > Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01 Only two minor things to pick on: make/common/MakeBase.gmk at new line #399: 'macor' should be 'macro' test/make/TestJavaCompilation.gmk at line #70 'DEPSENDENCIES' should be 'DEPENDENCIES' Otherwise, looks good to me. No need to respin the webrev for these fixes. /Tim From joe.darcy at oracle.com Thu Mar 12 02:53:06 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 11 Mar 2015 19:53:06 -0700 Subject: JDK 9 RFR of JDK-8072734: Turn on doclint checking in the build of modules in the jdk repo Message-ID: <5500FF92.5050206@oracle.com> Hello, With package filtering of doclint checking now available (JDK-8071851: Provide filtering of doclint checking based on packages), the time has come to enable a subset of doclint checking in the main build for java.* and javax.* packages. First, there is the simple subtask of doing this for the relevant files hosted in the langtools repository (JDK-8075035: Turn on doclint checking of modules in the langtools repo): diff -r 072008f47620 make/build.properties --- a/make/build.properties Wed Mar 11 22:24:05 2015 +0100 +++ b/make/build.properties Wed Mar 11 19:32:58 2015 -0700 @@ -28,7 +28,7 @@ javac.debuglevel = source,lines,vars javac.extra.opts=-XDignore.symbol.file=true javac.includes= -javac.lint.opts = -Xlint:all,-deprecation -Werror +javac.lint.opts = -Xlint:all,-deprecation -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' -Werror javac.source = 8 javac.target = 8 Next are the more extensive changes for modules in the jdk repo: JDK-8072734 : Turn on doclint checking in the build of modules in the jdk repo http://cr.openjdk.java.net/~darcy/8072734.0/ Full patch below. A few notes on the checks excluded from doclint checking. In the desktop module, there are still hundreds of method with missing javadoc (JDK-8071630) and the "missing" check cannot be enabled until that javadoc is added. The javadoc of the base module contains a few @see or @link references to members outside of the base module. Those outside members are not currently visible to javac when the base module is being compiled. That may change at some point later in JDK 9. If and when it does, the "reference" check can be enabled. In the desktop module some generated files are referencing other types in javadoc that aren't visible at that point. A later build change may be able to address this. There are five categories of doclint checks so my strong preference is to get a subset of checks enabled in the build and then work on enabling the remaining ones later on. With the application of a javadoc fix in the jdk repo I have out for review (JDK-8075034), a local build with the langtools and jdk-repo module checks has succeeded. To apply all due caution, upon successful review, I will have a jprt job submitted to push this change to verify there are no unexpected platform dependencies that would cause a build failure. To be clear, with this set of changes, it will be a true build error if certain categories of doclint problems is introduced to a java.* or javax.* type. This would be a large step toward completing the remaining goals of JEP 212: Resolve Lint and Doclint Warnings. Thanks, Thanks, -Joe --- old/make/CompileJavaModules.gmk 2015-03-11 19:39:09.884348698 -0700 +++ new/make/CompileJavaModules.gmk 2015-03-11 19:39:09.796304698 -0700 @@ -42,6 +42,7 @@ ################################################################################ +java.base_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' java.base_COPY := .icu .dat .spp content-types.properties hijrah-config-islamic-umalqura.properties java.base_CLEAN := intrinsic.properties @@ -89,10 +90,12 @@ ################################################################################ +java.datatransfer_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' java.datatransfer_COPY := flavormap.properties ################################################################################ +java.desktop_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-missing,-reference '-Xdoclint/package:java.*,javax.*' java.desktop_COPY := .gif .png .wav .txt .xml .css .pf java.desktop_CLEAN := iio-plugin.properties cursors.properties @@ -239,15 +242,18 @@ ################################################################################ +java.scripting_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' java.scripting_COPY := .js java.scripting_CLEAN := .properties ################################################################################ +java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS ################################################################################ +java.sql.rowset_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' java.sql.rowset_CLEAN_FILES := $(wildcard \ $(JDK_TOPDIR)/src/java.sql.rowset/share/classes/com/sun/rowset/*.properties \ $(JDK_TOPDIR)/src/java.sql.rowset/share/classes/javax/sql/rowset/*.properties) @@ -261,6 +267,7 @@ ################################################################################ +java.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' java.rmi_CLEAN_FILES := $(wildcard \ $(JDK_TOPDIR)/src/java.rmi/share/classes/sun/rmi/registry/resources/*.properties \ $(JDK_TOPDIR)/src/java.rmi/share/classes/sun/rmi/server/resources/*.properties) @@ -309,14 +316,17 @@ ################################################################################ +java.naming_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' java.naming_CLEAN := jndiprovider.properties ################################################################################ +java.security.saaj_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' java.security.saaj_CLEAN := .properties ################################################################################ +java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' java.xml.crypto_COPY := .dtd .xml java.xml.crypto_CLEAN := .properties @@ -485,7 +495,7 @@ $1_CLASSPATH := $$($1_CLASSPATH) $$(addprefix $(JDK_OUTPUTDIR)/modules/,jdk.hotspot.agent) endif $1_CLASSPATH := $$(subst $$(SPACE),$$(PATH_SEP),$$($1_CLASSPATH)) - $1_JAVAC_FLAGS := -bootclasspath "$$($1_CLASSPATH)" + $1_JAVAC_FLAGS := -bootclasspath "$$($1_CLASSPATH)" $$($1_ADD_JAVAC_FLAGS) $$(eval $$(call SetupJavaCompilation,$1, \ SETUP := $$(if $$($1_SETUP), $$($1_SETUP), GENERATE_JDKBYTECODE), \ From jonathan.gibbons at oracle.com Thu Mar 12 03:04:40 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Mar 2015 20:04:40 -0700 Subject: JDK 9 RFR of JDK-8072734: Turn on doclint checking in the build of modules in the jdk repo In-Reply-To: <5500FF92.5050206@oracle.com> References: <5500FF92.5050206@oracle.com> Message-ID: <55010248.50803@oracle.com> Joe, This is excellent work. Can I suggest that until we achieve perfection, we keep a status table somewhere listing the current level of goodness on a per-module basis, meaning, in a more digestible form than crawling through makefiles. -- Jon On 03/11/2015 07:53 PM, joe darcy wrote: > Hello, > > With package filtering of doclint checking now available (JDK-8071851: > Provide filtering of doclint checking based on packages), the time has > come to enable a subset of doclint checking in the main build for > java.* and javax.* packages. > > First, there is the simple subtask of doing this for the relevant > files hosted in the langtools repository (JDK-8075035: Turn on doclint > checking of modules in the langtools repo): > > diff -r 072008f47620 make/build.properties > --- a/make/build.properties Wed Mar 11 22:24:05 2015 +0100 > +++ b/make/build.properties Wed Mar 11 19:32:58 2015 -0700 > @@ -28,7 +28,7 @@ > javac.debuglevel = source,lines,vars > javac.extra.opts=-XDignore.symbol.file=true > javac.includes= > -javac.lint.opts = -Xlint:all,-deprecation -Werror > +javac.lint.opts = -Xlint:all,-deprecation -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' -Werror > javac.source = 8 > javac.target = 8 > > Next are the more extensive changes for modules in the jdk repo: > > JDK-8072734 : Turn on doclint checking in the build of modules in > the jdk repo > http://cr.openjdk.java.net/~darcy/8072734.0/ > > Full patch below. A few notes on the checks excluded from doclint > checking. In the desktop module, there are still hundreds of method > with missing javadoc (JDK-8071630) and the "missing" check cannot be > enabled until that javadoc is added. > > The javadoc of the base module contains a few @see or @link references > to members outside of the base module. Those outside members are not > currently visible to javac when the base module is being compiled. > That may change at some point later in JDK 9. If and when it does, the > "reference" check can be enabled. > > In the desktop module some generated files are referencing other types > in javadoc that aren't visible at that point. A later build change may > be able to address this. > > There are five categories of doclint checks so my strong preference is > to get a subset of checks enabled in the build and then work on > enabling the remaining ones later on. > > With the application of a javadoc fix in the jdk repo I have out for > review (JDK-8075034), a local build with the langtools and jdk-repo > module checks has succeeded. To apply all due caution, upon successful > review, I will have a jprt job submitted to push this change to verify > there are no unexpected platform dependencies that would cause a build > failure. > > To be clear, with this set of changes, it will be a true build error > if certain categories of doclint problems is introduced to a java.* or > javax.* type. This would be a large step toward completing the > remaining goals of JEP 212: Resolve Lint and Doclint Warnings. > > Thanks, > > Thanks, > > -Joe > > --- old/make/CompileJavaModules.gmk 2015-03-11 19:39:09.884348698 > -0700 > +++ new/make/CompileJavaModules.gmk 2015-03-11 19:39:09.796304698 > -0700 > @@ -42,6 +42,7 @@ > > ################################################################################ > > > +java.base_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference > '-Xdoclint/package:java.*,javax.*' > java.base_COPY := .icu .dat .spp content-types.properties > hijrah-config-islamic-umalqura.properties > java.base_CLEAN := intrinsic.properties > > @@ -89,10 +90,12 @@ > > ################################################################################ > > > +java.datatransfer_ADD_JAVAC_FLAGS := > -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' > java.datatransfer_COPY := flavormap.properties > > ################################################################################ > > > +java.desktop_ADD_JAVAC_FLAGS := > -Xdoclint:all/protected,-missing,-reference > '-Xdoclint/package:java.*,javax.*' > java.desktop_COPY := .gif .png .wav .txt .xml .css .pf > java.desktop_CLEAN := iio-plugin.properties cursors.properties > > @@ -239,15 +242,18 @@ > > ################################################################################ > > > +java.scripting_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.scripting_COPY := .js > java.scripting_CLEAN := .properties > > ################################################################################ > > > +java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS > > ################################################################################ > > > +java.sql.rowset_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.sql.rowset_CLEAN_FILES := $(wildcard \ > $(JDK_TOPDIR)/src/java.sql.rowset/share/classes/com/sun/rowset/*.properties > \ > $(JDK_TOPDIR)/src/java.sql.rowset/share/classes/javax/sql/rowset/*.properties) > > @@ -261,6 +267,7 @@ > > ################################################################################ > > > +java.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.rmi_CLEAN_FILES := $(wildcard \ > $(JDK_TOPDIR)/src/java.rmi/share/classes/sun/rmi/registry/resources/*.properties > \ > $(JDK_TOPDIR)/src/java.rmi/share/classes/sun/rmi/server/resources/*.properties) > > @@ -309,14 +316,17 @@ > > ################################################################################ > > > +java.naming_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.naming_CLEAN := jndiprovider.properties > > ################################################################################ > > > +java.security.saaj_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.security.saaj_CLEAN := .properties > > ################################################################################ > > > +java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.xml.crypto_COPY := .dtd .xml > java.xml.crypto_CLEAN := .properties > > @@ -485,7 +495,7 @@ > $1_CLASSPATH := $$($1_CLASSPATH) $$(addprefix > $(JDK_OUTPUTDIR)/modules/,jdk.hotspot.agent) > endif > $1_CLASSPATH := $$(subst $$(SPACE),$$(PATH_SEP),$$($1_CLASSPATH)) > - $1_JAVAC_FLAGS := -bootclasspath "$$($1_CLASSPATH)" > + $1_JAVAC_FLAGS := -bootclasspath "$$($1_CLASSPATH)" > $$($1_ADD_JAVAC_FLAGS) > > $$(eval $$(call SetupJavaCompilation,$1, \ > SETUP := $$(if $$($1_SETUP), $$($1_SETUP), > GENERATE_JDKBYTECODE), \ > From joe.darcy at oracle.com Thu Mar 12 04:46:16 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 11 Mar 2015 21:46:16 -0700 Subject: JDK 9 RFR of JDK-8072734: Turn on doclint checking in the build of modules in the jdk repo In-Reply-To: <55010248.50803@oracle.com> References: <5500FF92.5050206@oracle.com> <55010248.50803@oracle.com> Message-ID: <55011A18.1030202@oracle.com> Hi Jon, On 3/11/2015 8:04 PM, Jonathan Gibbons wrote: > Joe, > > This is excellent work. Thank you. It builds on previous excellent work getting doclint into the platform :-) > > Can I suggest that until we achieve perfection, we keep a status table > somewhere listing the current level of goodness on a per-module basis, > meaning, in a more digestible form than crawling through makefiles. Hmm... On a related note, I should have mentioned that the preferred way to turn doclint on would to be modify ./common/SetupJavaCompilers.gmk along the lines of --- a/make/common/SetupJavaCompilers.gmk Wed Mar 11 08:25:55 2015 -0700 +++ b/make/common/SetupJavaCompilers.gmk Wed Mar 11 21:35:03 2015 -0700 @@ -32,7 +32,7 @@ # If warnings needs to be non-fatal for testing purposes use a command like: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" -JAVAC_WARNINGS := -Xlint:all -Werror +JAVAC_WARNINGS := -Xlint:all -Werror -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools # and the interim javac, to be run by the boot jdk. which would set a consistently high level of doclint checking in one go throughout the modules hosted in the jdk repo. (For good measure, in time we could also include the non-internal parts of the jdk.* package in the set of packages checked.) Until the preconditions of getting one simple check in place are met, the incremental approach is to have module-specific doclint settings which can be adjusted up over time, as in the patch out for review. Did you have a location in mind for such a table? Somewhere is the source tree is preferable. If a better alternative doesn't present itself, perhaps a comment in the CompileJavaModules.gmk file would be better than nothing. For the patch sent out for review, I only updated the command for modules which already had some sort of customized handling and I doubt all modules where covered. However, I suspect the majority of the code in the jdk repo is in either the java.base or java.desktop module so those alone represent most of the API surface. Thanks, -Joe > > -- Jon > > On 03/11/2015 07:53 PM, joe darcy wrote: >> Hello, >> >> With package filtering of doclint checking now available >> (JDK-8071851: Provide filtering of doclint checking based on >> packages), the time has come to enable a subset of doclint checking >> in the main build for java.* and javax.* packages. >> >> First, there is the simple subtask of doing this for the relevant >> files hosted in the langtools repository (JDK-8075035: Turn on >> doclint checking of modules in the langtools repo): >> >> diff -r 072008f47620 make/build.properties >> --- a/make/build.properties Wed Mar 11 22:24:05 2015 +0100 >> +++ b/make/build.properties Wed Mar 11 19:32:58 2015 -0700 >> @@ -28,7 +28,7 @@ >> javac.debuglevel = source,lines,vars >> javac.extra.opts=-XDignore.symbol.file=true >> javac.includes= >> -javac.lint.opts = -Xlint:all,-deprecation -Werror >> +javac.lint.opts = -Xlint:all,-deprecation -Xdoclint:all/protected >> '-Xdoclint/package:java.*,javax.*' -Werror >> javac.source = 8 >> javac.target = 8 >> >> Next are the more extensive changes for modules in the jdk repo: >> >> JDK-8072734 : Turn on doclint checking in the build of modules in >> the jdk repo >> http://cr.openjdk.java.net/~darcy/8072734.0/ >> >> Full patch below. A few notes on the checks excluded from doclint >> checking. In the desktop module, there are still hundreds of method >> with missing javadoc (JDK-8071630) and the "missing" check cannot be >> enabled until that javadoc is added. >> >> The javadoc of the base module contains a few @see or @link >> references to members outside of the base module. Those outside >> members are not currently visible to javac when the base module is >> being compiled. That may change at some point later in JDK 9. If and >> when it does, the "reference" check can be enabled. >> >> In the desktop module some generated files are referencing other >> types in javadoc that aren't visible at that point. A later build >> change may be able to address this. >> >> There are five categories of doclint checks so my strong preference >> is to get a subset of checks enabled in the build and then work on >> enabling the remaining ones later on. >> >> With the application of a javadoc fix in the jdk repo I have out for >> review (JDK-8075034), a local build with the langtools and jdk-repo >> module checks has succeeded. To apply all due caution, upon >> successful review, I will have a jprt job submitted to push this >> change to verify there are no unexpected platform dependencies that >> would cause a build failure. >> >> To be clear, with this set of changes, it will be a true build error >> if certain categories of doclint problems is introduced to a java.* >> or javax.* type. This would be a large step toward completing the >> remaining goals of JEP 212: Resolve Lint and Doclint Warnings. >> >> Thanks, >> >> Thanks, >> >> -Joe >> >> --- old/make/CompileJavaModules.gmk 2015-03-11 19:39:09.884348698 >> -0700 >> +++ new/make/CompileJavaModules.gmk 2015-03-11 19:39:09.796304698 >> -0700 >> @@ -42,6 +42,7 @@ >> >> ################################################################################ >> >> >> +java.base_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference >> '-Xdoclint/package:java.*,javax.*' >> java.base_COPY := .icu .dat .spp content-types.properties >> hijrah-config-islamic-umalqura.properties >> java.base_CLEAN := intrinsic.properties >> >> @@ -89,10 +90,12 @@ >> >> ################################################################################ >> >> >> +java.datatransfer_ADD_JAVAC_FLAGS := >> -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' >> java.datatransfer_COPY := flavormap.properties >> >> ################################################################################ >> >> >> +java.desktop_ADD_JAVAC_FLAGS := >> -Xdoclint:all/protected,-missing,-reference >> '-Xdoclint/package:java.*,javax.*' >> java.desktop_COPY := .gif .png .wav .txt .xml .css .pf >> java.desktop_CLEAN := iio-plugin.properties cursors.properties >> >> @@ -239,15 +242,18 @@ >> >> ################################################################################ >> >> >> +java.scripting_ADD_JAVAC_FLAGS := -Xdoclint:all/protected >> '-Xdoclint/package:java.*,javax.*' >> java.scripting_COPY := .js >> java.scripting_CLEAN := .properties >> >> ################################################################################ >> >> >> +java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected >> '-Xdoclint/package:java.*,javax.*' >> java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS >> >> ################################################################################ >> >> >> +java.sql.rowset_ADD_JAVAC_FLAGS := -Xdoclint:all/protected >> '-Xdoclint/package:java.*,javax.*' >> java.sql.rowset_CLEAN_FILES := $(wildcard \ >> $(JDK_TOPDIR)/src/java.sql.rowset/share/classes/com/sun/rowset/*.properties >> \ >> $(JDK_TOPDIR)/src/java.sql.rowset/share/classes/javax/sql/rowset/*.properties) >> >> @@ -261,6 +267,7 @@ >> >> ################################################################################ >> >> >> +java.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected >> '-Xdoclint/package:java.*,javax.*' >> java.rmi_CLEAN_FILES := $(wildcard \ >> $(JDK_TOPDIR)/src/java.rmi/share/classes/sun/rmi/registry/resources/*.properties >> \ >> $(JDK_TOPDIR)/src/java.rmi/share/classes/sun/rmi/server/resources/*.properties) >> >> @@ -309,14 +316,17 @@ >> >> ################################################################################ >> >> >> +java.naming_ADD_JAVAC_FLAGS := -Xdoclint:all/protected >> '-Xdoclint/package:java.*,javax.*' >> java.naming_CLEAN := jndiprovider.properties >> >> ################################################################################ >> >> >> +java.security.saaj_ADD_JAVAC_FLAGS := -Xdoclint:all/protected >> '-Xdoclint/package:java.*,javax.*' >> java.security.saaj_CLEAN := .properties >> >> ################################################################################ >> >> >> +java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected >> '-Xdoclint/package:java.*,javax.*' >> java.xml.crypto_COPY := .dtd .xml >> java.xml.crypto_CLEAN := .properties >> >> @@ -485,7 +495,7 @@ >> $1_CLASSPATH := $$($1_CLASSPATH) $$(addprefix >> $(JDK_OUTPUTDIR)/modules/,jdk.hotspot.agent) >> endif >> $1_CLASSPATH := $$(subst $$(SPACE),$$(PATH_SEP),$$($1_CLASSPATH)) >> - $1_JAVAC_FLAGS := -bootclasspath "$$($1_CLASSPATH)" >> + $1_JAVAC_FLAGS := -bootclasspath "$$($1_CLASSPATH)" >> $$($1_ADD_JAVAC_FLAGS) >> >> $$(eval $$(call SetupJavaCompilation,$1, \ >> SETUP := $$(if $$($1_SETUP), $$($1_SETUP), >> GENERATE_JDKBYTECODE), \ >> > From erik.joelsson at oracle.com Thu Mar 12 08:24:34 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Mar 2015 09:24:34 +0100 Subject: JDK 9 RFR of JDK-8072734: Turn on doclint checking in the build of modules in the jdk repo In-Reply-To: <5500FF92.5050206@oracle.com> References: <5500FF92.5050206@oracle.com> Message-ID: <55014D42.8010502@oracle.com> Hello, Looks good to me, and as always, wonderful to see progress on this! /Erik On 2015-03-12 03:53, joe darcy wrote: > Hello, > > With package filtering of doclint checking now available (JDK-8071851: > Provide filtering of doclint checking based on packages), the time has > come to enable a subset of doclint checking in the main build for > java.* and javax.* packages. > > First, there is the simple subtask of doing this for the relevant > files hosted in the langtools repository (JDK-8075035: Turn on doclint > checking of modules in the langtools repo): > > diff -r 072008f47620 make/build.properties > --- a/make/build.properties Wed Mar 11 22:24:05 2015 +0100 > +++ b/make/build.properties Wed Mar 11 19:32:58 2015 -0700 > @@ -28,7 +28,7 @@ > javac.debuglevel = source,lines,vars > javac.extra.opts=-XDignore.symbol.file=true > javac.includes= > -javac.lint.opts = -Xlint:all,-deprecation -Werror > +javac.lint.opts = -Xlint:all,-deprecation -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' -Werror > javac.source = 8 > javac.target = 8 > > Next are the more extensive changes for modules in the jdk repo: > > JDK-8072734 : Turn on doclint checking in the build of modules in > the jdk repo > http://cr.openjdk.java.net/~darcy/8072734.0/ > > Full patch below. A few notes on the checks excluded from doclint > checking. In the desktop module, there are still hundreds of method > with missing javadoc (JDK-8071630) and the "missing" check cannot be > enabled until that javadoc is added. > > The javadoc of the base module contains a few @see or @link references > to members outside of the base module. Those outside members are not > currently visible to javac when the base module is being compiled. > That may change at some point later in JDK 9. If and when it does, the > "reference" check can be enabled. > > In the desktop module some generated files are referencing other types > in javadoc that aren't visible at that point. A later build change may > be able to address this. > > There are five categories of doclint checks so my strong preference is > to get a subset of checks enabled in the build and then work on > enabling the remaining ones later on. > > With the application of a javadoc fix in the jdk repo I have out for > review (JDK-8075034), a local build with the langtools and jdk-repo > module checks has succeeded. To apply all due caution, upon successful > review, I will have a jprt job submitted to push this change to verify > there are no unexpected platform dependencies that would cause a build > failure. > > To be clear, with this set of changes, it will be a true build error > if certain categories of doclint problems is introduced to a java.* or > javax.* type. This would be a large step toward completing the > remaining goals of JEP 212: Resolve Lint and Doclint Warnings. > > Thanks, > > Thanks, > > -Joe > > --- old/make/CompileJavaModules.gmk 2015-03-11 19:39:09.884348698 > -0700 > +++ new/make/CompileJavaModules.gmk 2015-03-11 19:39:09.796304698 > -0700 > @@ -42,6 +42,7 @@ > > ################################################################################ > > > +java.base_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference > '-Xdoclint/package:java.*,javax.*' > java.base_COPY := .icu .dat .spp content-types.properties > hijrah-config-islamic-umalqura.properties > java.base_CLEAN := intrinsic.properties > > @@ -89,10 +90,12 @@ > > ################################################################################ > > > +java.datatransfer_ADD_JAVAC_FLAGS := > -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' > java.datatransfer_COPY := flavormap.properties > > ################################################################################ > > > +java.desktop_ADD_JAVAC_FLAGS := > -Xdoclint:all/protected,-missing,-reference > '-Xdoclint/package:java.*,javax.*' > java.desktop_COPY := .gif .png .wav .txt .xml .css .pf > java.desktop_CLEAN := iio-plugin.properties cursors.properties > > @@ -239,15 +242,18 @@ > > ################################################################################ > > > +java.scripting_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.scripting_COPY := .js > java.scripting_CLEAN := .properties > > ################################################################################ > > > +java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS > > ################################################################################ > > > +java.sql.rowset_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.sql.rowset_CLEAN_FILES := $(wildcard \ > $(JDK_TOPDIR)/src/java.sql.rowset/share/classes/com/sun/rowset/*.properties > \ > $(JDK_TOPDIR)/src/java.sql.rowset/share/classes/javax/sql/rowset/*.properties) > > @@ -261,6 +267,7 @@ > > ################################################################################ > > > +java.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.rmi_CLEAN_FILES := $(wildcard \ > $(JDK_TOPDIR)/src/java.rmi/share/classes/sun/rmi/registry/resources/*.properties > \ > $(JDK_TOPDIR)/src/java.rmi/share/classes/sun/rmi/server/resources/*.properties) > > @@ -309,14 +316,17 @@ > > ################################################################################ > > > +java.naming_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.naming_CLEAN := jndiprovider.properties > > ################################################################################ > > > +java.security.saaj_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.security.saaj_CLEAN := .properties > > ################################################################################ > > > +java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > java.xml.crypto_COPY := .dtd .xml > java.xml.crypto_CLEAN := .properties > > @@ -485,7 +495,7 @@ > $1_CLASSPATH := $$($1_CLASSPATH) $$(addprefix > $(JDK_OUTPUTDIR)/modules/,jdk.hotspot.agent) > endif > $1_CLASSPATH := $$(subst $$(SPACE),$$(PATH_SEP),$$($1_CLASSPATH)) > - $1_JAVAC_FLAGS := -bootclasspath "$$($1_CLASSPATH)" > + $1_JAVAC_FLAGS := -bootclasspath "$$($1_CLASSPATH)" > $$($1_ADD_JAVAC_FLAGS) > > $$(eval $$(call SetupJavaCompilation,$1, \ > SETUP := $$(if $$($1_SETUP), $$($1_SETUP), > GENERATE_JDKBYTECODE), \ > From magnus.ihse.bursie at oracle.com Thu Mar 12 10:02:47 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Mar 2015 11:02:47 +0100 Subject: RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions In-Reply-To: <55006C23.9050401@oracle.com> References: <55006391.7060301@oracle.com> <55006C23.9050401@oracle.com> Message-ID: <55016447.4090705@oracle.com> On 2015-03-11 17:24, Tim Bell wrote: > Erik: > >> (including nashorn-dev since a makefile there is touched) >> >> When creating a Setup* macro that takes named parameters, like >> SetupJavaCompilation, there is a lot of copied boilerplate code that >> needs to be written. The code, which is essentially copied for all >> these macro definitions, handles converting the named parameters into >> local variables and some debugging features. Here is >> SetupJavaCompilation as an example: >> >> define SetupJavaCompilation >> $(if $(16),$(error Internal makefile error: Too many arguments to >> SetupJavaCompilation, please update JavaCompilation.gmk)) >> $(call EvalDebugWrapper,$(strip $1),$(call >> SetupJavaCompilationInner,$(strip >> $1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))) >> endef >> >> define SetupJavaCompilationInner >> $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip >> $($i)),$1_$(strip $($i)))$(NEWLINE)) >> $(call >> LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)) >> $(if $(16),$(error Internal makefile error: Too many arguments to >> SetupJavaCompilation, please update JavaCompilation.gmk)) >> ... >> endef >> >> >> I have figured out a way to reduce this boilerplate significantly, >> massively reducing the overhead and resistance for creating new >> macros. The logic for converting the named parameters and all the >> debugging features are now defined only once in MakeBase.gmk. The >> corresponding declaration of SetupJavaCompilation is reduced to this: >> >> SetupJavaCompilation = $(NamedParamsMacroTemplate) >> define SetupJavaCompilationBody >> ... >> endef >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074988 >> Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01 > > Only two minor things to pick on: > > make/common/MakeBase.gmk at new line #399: > 'macor' should be 'macro' > > test/make/TestJavaCompilation.gmk at line #70 > 'DEPSENDENCIES' should be 'DEPENDENCIES' Good catch! Apart from these typos, it looks good to me too. /Magnus From erik.joelsson at oracle.com Thu Mar 12 11:12:27 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Mar 2015 12:12:27 +0100 Subject: RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions In-Reply-To: <55016447.4090705@oracle.com> References: <55006391.7060301@oracle.com> <55006C23.9050401@oracle.com> <55016447.4090705@oracle.com> Message-ID: <5501749B.5000600@oracle.com> Thanks, I will correct those before pushing. /Erik On 2015-03-12 11:02, Magnus Ihse Bursie wrote: > On 2015-03-11 17:24, Tim Bell wrote: >> Erik: >> >>> (including nashorn-dev since a makefile there is touched) >>> >>> When creating a Setup* macro that takes named parameters, like >>> SetupJavaCompilation, there is a lot of copied boilerplate code that >>> needs to be written. The code, which is essentially copied for all >>> these macro definitions, handles converting the named parameters >>> into local variables and some debugging features. Here is >>> SetupJavaCompilation as an example: >>> >>> define SetupJavaCompilation >>> $(if $(16),$(error Internal makefile error: Too many arguments to >>> SetupJavaCompilation, please update JavaCompilation.gmk)) >>> $(call EvalDebugWrapper,$(strip $1),$(call >>> SetupJavaCompilationInner,$(strip >>> $1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))) >>> endef >>> >>> define SetupJavaCompilationInner >>> $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip >>> $($i)),$1_$(strip $($i)))$(NEWLINE)) >>> $(call >>> LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)) >>> $(if $(16),$(error Internal makefile error: Too many arguments to >>> SetupJavaCompilation, please update JavaCompilation.gmk)) >>> ... >>> endef >>> >>> >>> I have figured out a way to reduce this boilerplate significantly, >>> massively reducing the overhead and resistance for creating new >>> macros. The logic for converting the named parameters and all the >>> debugging features are now defined only once in MakeBase.gmk. The >>> corresponding declaration of SetupJavaCompilation is reduced to this: >>> >>> SetupJavaCompilation = $(NamedParamsMacroTemplate) >>> define SetupJavaCompilationBody >>> ... >>> endef >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074988 >>> Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01 >> >> Only two minor things to pick on: >> >> make/common/MakeBase.gmk at new line #399: >> 'macor' should be 'macro' >> >> test/make/TestJavaCompilation.gmk at line #70 >> 'DEPSENDENCIES' should be 'DEPENDENCIES' > > Good catch! > > Apart from these typos, it looks good to me too. > > /Magnus From staffan.larsen at oracle.com Thu Mar 12 12:54:17 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Mar 2015 13:54:17 +0100 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole Message-ID: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. bug: https://bugs.openjdk.java.net/browse/JDK-8075056 webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ Thanks, /Staffan From erik.joelsson at oracle.com Thu Mar 12 13:00:07 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Mar 2015 14:00:07 +0100 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <55018DD7.4010100@oracle.com> Looks good. /Erik On 2015-03-12 13:54, Staffan Larsen wrote: > The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ > > Thanks, > /Staffan From Alan.Bateman at oracle.com Thu Mar 12 13:07:44 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Mar 2015 13:07:44 +0000 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <55018FA0.6030900@oracle.com> On 12/03/2015 12:54, Staffan Larsen wrote: > The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ > > Looks okay to me. -Alan From magnus.ihse.bursie at oracle.com Thu Mar 12 14:05:42 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Mar 2015 15:05:42 +0100 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <55019D36.2060501@oracle.com> On 2015-03-12 13:54, Staffan Larsen wrote: > The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ > > Thanks, > /Staffan Looks good. Thank you! /Magnus From volker.simonis at gmail.com Thu Mar 12 14:34:58 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 Mar 2015 15:34:58 +0100 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: <545A1F86.3090301@oracle.com> References: <545A082D.1000001@oracle.com> <545A173E.8060908@oracle.com> <545A17BF.7090705@oracle.com> <545A1F86.3090301@oracle.com> Message-ID: Hi, I understand that I'm a little late to the game but I just run into this problem myself:) The funny thing is that this problem doesn't occur with MinGW/MSYS but just with Cygwin and I can't understand why? We have a little special setup here at SAP: we do the Windows builds with MinGW/MSYS and by default we always build with --disable-zip-debug-info. So until now we had no problems. Now I started to migrate our build to Cygwin (but still with --disable-zip-debug-info) and run into the problem. I think the origin of the dependency on the .map (and .pdb) files is clear - it is set right in SetupNativeCompilation if we don't want to zip the debug information (i.e. --disable-zip-debug-info): ifeq ($(ZIP_DEBUGINFO_FILES), true) ... else ifeq ($(OPENJDK_TARGET_OS), windows) $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb But we also have the following pattern rule in SetupNativeCompilation which should copy the .map and .pdb from OBJECT_DIR to OUTPUT_DIR: ifneq ($$($1_OUTPUT_DIR),$$($1_OBJECT_DIR)) $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/% $(CP) $$< $$@ endif This rule works perfectly with MinGW/MSYS but it doesn't get triggered with Cygwin. And that's the reason why we get the error "*** No rule to make target `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map'" which says that it can not make the .map file in the OUTPUT_DIR. But notice that the .map file is there in the OBJECT_DIR directory (i.e. ../objs/libverify/verify.map), but make under Cygwin somehow doesn't recognize that there's a rule to copy it over to the OUTPUT_DIR directory. I tried the workaround proposed by Magnus' but unfortunately it doesn't work. I think that's because the problem is not that the .map files are not created - the problem is that they are not copied over to the OUTPUT_DIR. So here's what really helped: ifeq ($(OPENJDK_TARGET_OS), windows) $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map : $$($1_OBJECT_DIR)/$$($1_LIBRARY).map echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" $(CP) $$< $$@ $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb : $$($1_OBJECT_DIR)/$$($1_LIBRARY).pdb echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" $(CP) $$< $$@ And you need the same fix for the PROGRAM build part: ifeq ($(OPENJDK_TARGET_OS), windows) $1 += $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map \ $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map : $$($1_OBJECT_DIR)/$$($1_PROGRAM).map echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" $(CP) $$< $$@ $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb : $$($1_OBJECT_DIR)/$$($1_PROGRAM).pdb echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" $(CP) $$< $$@ So for me this works now and I will change our internal build accordingly. I don't know if there's any interest of bringing this to jdk8u. I just though I'll let you know:) It would also be interesting if somebody has some explanation for why the pattern rule for copying the .map files works under MinGW/MSYS but not under Cygwin. Regards, Volker On Wed, Nov 5, 2014 at 2:00 PM, David Holmes wrote: > On 5/11/2014 10:27 PM, Magnus Ihse Bursie wrote: >> >> On 2014-11-05 13:25, Magnus Ihse Bursie wrote: >>> >>> I even have a vague memory of a fix along these lines in jdk9. If >>> that's correct, it's probably due for backporting. I'll see if I can >>> locate it. >> >> >> https://bugs.openjdk.java.net/browse/JDK-8025936 >> >> It might be some work backporting it though, the comments in the bug >> says it needed to be substantially rewritten due to changes in JDK9. > > > Thanks Magnus. Seems this is unlikely to be fixed then - which means I can't > test what I'm working on for the case where we don't zip the debuginfo files > :( > > David > >> /Magnus From dmitry.samersoff at oracle.com Thu Mar 12 14:39:49 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 Mar 2015 17:39:49 +0300 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: References: <545A082D.1000001@oracle.com> <545A173E.8060908@oracle.com> <545A17BF.7090705@oracle.com> <545A1F86.3090301@oracle.com> Message-ID: <5501A535.7020801@oracle.com> Volker, What version of *make* do you use in both cases? -Dmitry On 2015-03-12 17:34, Volker Simonis wrote: > Hi, > > I understand that I'm a little late to the game but I just run into > this problem myself:) > > The funny thing is that this problem doesn't occur with MinGW/MSYS but > just with Cygwin and I can't understand why? > > We have a little special setup here at SAP: we do the Windows builds > with MinGW/MSYS and by default we always build with > --disable-zip-debug-info. So until now we had no problems. > > Now I started to migrate our build to Cygwin (but still with > --disable-zip-debug-info) and run into the problem. > > I think the origin of the dependency on the .map (and .pdb) files is > clear - it is set right in SetupNativeCompilation if we don't want to > zip the debug information (i.e. --disable-zip-debug-info): > > ifeq ($(ZIP_DEBUGINFO_FILES), true) > ... > else > ifeq ($(OPENJDK_TARGET_OS), windows) > $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ > $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb > > But we also have the following pattern rule in SetupNativeCompilation > which should copy the .map and .pdb from OBJECT_DIR to OUTPUT_DIR: > > ifneq ($$($1_OUTPUT_DIR),$$($1_OBJECT_DIR)) > $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/% > $(CP) $$< $$@ > endif > > This rule works perfectly with MinGW/MSYS but it doesn't get triggered > with Cygwin. And that's the reason why we get the error "*** No rule > to make target `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map'" > which says that it can not make the .map file in the OUTPUT_DIR. But > notice that the .map file is there in the OBJECT_DIR directory (i.e. > ../objs/libverify/verify.map), but make under Cygwin somehow doesn't > recognize that there's a rule to copy it over to the OUTPUT_DIR > directory. > > I tried the workaround proposed by Magnus' but unfortunately it > doesn't work. I think that's because the problem is not that the .map > files are not created - the problem is that they are not copied over > to the OUTPUT_DIR. > > So here's what really helped: > > ifeq ($(OPENJDK_TARGET_OS), windows) > $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ > $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb > > $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map : > $$($1_OBJECT_DIR)/$$($1_LIBRARY).map > echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" > $(CP) $$< $$@ > $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb : > $$($1_OBJECT_DIR)/$$($1_LIBRARY).pdb > echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" > $(CP) $$< $$@ > > And you need the same fix for the PROGRAM build part: > > ifeq ($(OPENJDK_TARGET_OS), windows) > $1 += $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map \ > $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb > > $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map : > $$($1_OBJECT_DIR)/$$($1_PROGRAM).map > echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" > $(CP) $$< $$@ > $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb : > $$($1_OBJECT_DIR)/$$($1_PROGRAM).pdb > echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" > $(CP) $$< $$@ > > So for me this works now and I will change our internal build accordingly. > > I don't know if there's any interest of bringing this to jdk8u. I just > though I'll let you know:) > > It would also be interesting if somebody has some explanation for why > the pattern rule for copying the .map files works under MinGW/MSYS but > not under Cygwin. > > Regards, > Volker > > On Wed, Nov 5, 2014 at 2:00 PM, David Holmes wrote: >> On 5/11/2014 10:27 PM, Magnus Ihse Bursie wrote: >>> >>> On 2014-11-05 13:25, Magnus Ihse Bursie wrote: >>>> >>>> I even have a vague memory of a fix along these lines in jdk9. If >>>> that's correct, it's probably due for backporting. I'll see if I can >>>> locate it. >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8025936 >>> >>> It might be some work backporting it though, the comments in the bug >>> says it needed to be substantially rewritten due to changes in JDK9. >> >> >> Thanks Magnus. Seems this is unlikely to be fixed then - which means I can't >> test what I'm working on for the case where we don't zip the debuginfo files >> :( >> >> David >> >>> /Magnus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From volker.simonis at gmail.com Thu Mar 12 14:54:43 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 Mar 2015 15:54:43 +0100 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: <5501A535.7020801@oracle.com> References: <545A082D.1000001@oracle.com> <545A173E.8060908@oracle.com> <545A17BF.7090705@oracle.com> <545A1F86.3090301@oracle.com> <5501A535.7020801@oracle.com> Message-ID: Hi Dmitry, no, they are not the same. I forgot to mention that. On MinGW we have 3.81 and on Cygwin 4.1 Are there any known problems with the new Version? I specially use GNU make 4.1 on Cygwin because it can nicely handle ":" in target path names (unfortunately we still have them in our build :(. With older version of make this leads to "multiple target patterns" errors. Regards, Volker On Thu, Mar 12, 2015 at 3:39 PM, Dmitry Samersoff wrote: > Volker, > > What version of *make* do you use in both cases? > > -Dmitry > > On 2015-03-12 17:34, Volker Simonis wrote: >> Hi, >> >> I understand that I'm a little late to the game but I just run into >> this problem myself:) >> >> The funny thing is that this problem doesn't occur with MinGW/MSYS but >> just with Cygwin and I can't understand why? >> >> We have a little special setup here at SAP: we do the Windows builds >> with MinGW/MSYS and by default we always build with >> --disable-zip-debug-info. So until now we had no problems. >> >> Now I started to migrate our build to Cygwin (but still with >> --disable-zip-debug-info) and run into the problem. >> >> I think the origin of the dependency on the .map (and .pdb) files is >> clear - it is set right in SetupNativeCompilation if we don't want to >> zip the debug information (i.e. --disable-zip-debug-info): >> >> ifeq ($(ZIP_DEBUGINFO_FILES), true) >> ... >> else >> ifeq ($(OPENJDK_TARGET_OS), windows) >> $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ >> $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb >> >> But we also have the following pattern rule in SetupNativeCompilation >> which should copy the .map and .pdb from OBJECT_DIR to OUTPUT_DIR: >> >> ifneq ($$($1_OUTPUT_DIR),$$($1_OBJECT_DIR)) >> $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/% >> $(CP) $$< $$@ >> endif >> >> This rule works perfectly with MinGW/MSYS but it doesn't get triggered >> with Cygwin. And that's the reason why we get the error "*** No rule >> to make target `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map'" >> which says that it can not make the .map file in the OUTPUT_DIR. But >> notice that the .map file is there in the OBJECT_DIR directory (i.e. >> ../objs/libverify/verify.map), but make under Cygwin somehow doesn't >> recognize that there's a rule to copy it over to the OUTPUT_DIR >> directory. >> >> I tried the workaround proposed by Magnus' but unfortunately it >> doesn't work. I think that's because the problem is not that the .map >> files are not created - the problem is that they are not copied over >> to the OUTPUT_DIR. >> >> So here's what really helped: >> >> ifeq ($(OPENJDK_TARGET_OS), windows) >> $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ >> $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb >> >> $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map : >> $$($1_OBJECT_DIR)/$$($1_LIBRARY).map >> echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" >> $(CP) $$< $$@ >> $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb : >> $$($1_OBJECT_DIR)/$$($1_LIBRARY).pdb >> echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" >> $(CP) $$< $$@ >> >> And you need the same fix for the PROGRAM build part: >> >> ifeq ($(OPENJDK_TARGET_OS), windows) >> $1 += $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map \ >> $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb >> >> $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map : >> $$($1_OBJECT_DIR)/$$($1_PROGRAM).map >> echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" >> $(CP) $$< $$@ >> $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb : >> $$($1_OBJECT_DIR)/$$($1_PROGRAM).pdb >> echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" >> $(CP) $$< $$@ >> >> So for me this works now and I will change our internal build accordingly. >> >> I don't know if there's any interest of bringing this to jdk8u. I just >> though I'll let you know:) >> >> It would also be interesting if somebody has some explanation for why >> the pattern rule for copying the .map files works under MinGW/MSYS but >> not under Cygwin. >> >> Regards, >> Volker >> >> On Wed, Nov 5, 2014 at 2:00 PM, David Holmes wrote: >>> On 5/11/2014 10:27 PM, Magnus Ihse Bursie wrote: >>>> >>>> On 2014-11-05 13:25, Magnus Ihse Bursie wrote: >>>>> >>>>> I even have a vague memory of a fix along these lines in jdk9. If >>>>> that's correct, it's probably due for backporting. I'll see if I can >>>>> locate it. >>>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8025936 >>>> >>>> It might be some work backporting it though, the comments in the bug >>>> says it needed to be substantially rewritten due to changes in JDK9. >>> >>> >>> Thanks Magnus. Seems this is unlikely to be fixed then - which means I can't >>> test what I'm working on for the case where we don't zip the debuginfo files >>> :( >>> >>> David >>> >>>> /Magnus > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From magnus.ihse.bursie at oracle.com Thu Mar 12 15:04:17 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Mar 2015 16:04:17 +0100 Subject: RFR: JDK-8074796 Disabling warnings on clang triggers compiler bug for libunpack Message-ID: <5501AAF1.8070001@oracle.com> With JDK-8074096, some warnings produced by libunpack was silenced. However, it turned out that the version of clang shipped with Xcode 5.1 has some weird behavior, which I would classify as a compiler bug. The generated output differs markedly, if -Wno-foo is present on the command line. Enough to trigger a failure in an Oracle-internal test of libunpack. Removing the disabled warnings restore the previous behaviour. While I've spent too much time on this already, I have not been able to pinpoint exactly what triggers this behavior. It seems that all files in libunpack are affected, but no other libs. (However there are also some minor changes in ./java.desktop/libawt_lwawt/OGLPaints.o ./java.desktop/liblcms/cmsps2.o ./java.desktop/libmlib_image/mlib_ImageColorTrue2Index.o which there really should not be.) And it only affects libunpack, not the unpack200 exe which shares part of the code. I have no explanation for this. The simple solution at this point is to back out the warning changes for clang. There is already a fix on the way to resolve the root cause of this failures. (And yes, I tried running that patch. It did indeed remove the warnings. But when running with the -Wno-foo flags, clang *still* generated broken code.) Bug: https://bugs.openjdk.java.net/browse/JDK-8074796 Patch inline: diff --git a/make/lib/Lib-jdk.pack200.gmk b/make/lib/Lib-jdk.pack200.gmk --- a/make/lib/Lib-jdk.pack200.gmk +++ b/make/lib/Lib-jdk.pack200.gmk @@ -42,7 +42,6 @@ CFLAGS_release := -DPRODUCT, \ DISABLED_WARNINGS_gcc := conversion-null sign-compare format-security \ format-nonliteral parentheses, \ - DISABLED_WARNINGS_clang := bool-conversion format-security, \ DISABLED_WARNINGS_solstudio := truncwarn, \ DISABLED_WARNINGS_microsoft := 4267 4018, \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libunpack/mapfile-vers, \ /Magnus From erik.joelsson at oracle.com Thu Mar 12 15:23:33 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Mar 2015 16:23:33 +0100 Subject: RFR: JDK-8074796 Disabling warnings on clang triggers compiler bug for libunpack In-Reply-To: <5501AAF1.8070001@oracle.com> References: <5501AAF1.8070001@oracle.com> Message-ID: <5501AF75.7080104@oracle.com> Looks good to me. /Erik On 2015-03-12 16:04, Magnus Ihse Bursie wrote: > With JDK-8074096, some warnings produced by libunpack was silenced. > > However, it turned out that the version of clang shipped with Xcode > 5.1 has some weird behavior, which I would classify as a compiler bug. > The generated output differs markedly, if -Wno-foo is present on the > command line. Enough to trigger a failure in an Oracle-internal test > of libunpack. > > Removing the disabled warnings restore the previous behaviour. > > While I've spent too much time on this already, I have not been able > to pinpoint exactly what triggers this behavior. It seems that all > files in libunpack are affected, but no other libs. (However there are > also some minor changes in ./java.desktop/libawt_lwawt/OGLPaints.o > ./java.desktop/liblcms/cmsps2.o > ./java.desktop/libmlib_image/mlib_ImageColorTrue2Index.o which there > really should not be.) And it only affects libunpack, not the > unpack200 exe which shares part of the code. I have no explanation for > this. > > The simple solution at this point is to back out the warning changes > for clang. There is already a fix on the way to resolve the root cause > of this failures. (And yes, I tried running that patch. It did indeed > remove the warnings. But when running with the -Wno-foo flags, clang > *still* generated broken code.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074796 > Patch inline: > > diff --git a/make/lib/Lib-jdk.pack200.gmk b/make/lib/Lib-jdk.pack200.gmk > --- a/make/lib/Lib-jdk.pack200.gmk > +++ b/make/lib/Lib-jdk.pack200.gmk > @@ -42,7 +42,6 @@ > CFLAGS_release := -DPRODUCT, \ > DISABLED_WARNINGS_gcc := conversion-null sign-compare > format-security \ > format-nonliteral parentheses, \ > - DISABLED_WARNINGS_clang := bool-conversion format-security, \ > DISABLED_WARNINGS_solstudio := truncwarn, \ > DISABLED_WARNINGS_microsoft := 4267 4018, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libunpack/mapfile-vers, \ > > /Magnus From mandy.chung at oracle.com Thu Mar 12 16:05:55 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 Mar 2015 09:05:55 -0700 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <5501B963.9010002@oracle.com> On 3/12/2015 5:54 AM, Staffan Larsen wrote: > The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ jconsole is redistributable. It's possible that customers can run jconsole with a JRE of different version. Now it's linked in the image and we will have look into whether we want to continue jconsole be redistributable and perhaps it will not be in JDK 9 and this change would be okay. Mandy From iris.clark at oracle.com Thu Mar 12 16:19:01 2015 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 12 Mar 2015 09:19:01 -0700 (PDT) Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: Hi, Staffan. > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ Looks good. I'm always happy to see changes where complexity is reduced. Thanks, iris From magnus.ihse.bursie at oracle.com Thu Mar 12 19:48:03 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Mar 2015 20:48:03 +0100 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: References: <545A082D.1000001@oracle.com> <545A173E.8060908@oracle.com> <545A17BF.7090705@oracle.com> <545A1F86.3090301@oracle.com> Message-ID: We have had issues before with pattern rules on Windows/cygwin. An older incarnation of Images.gmk used pattern rules extensively, but it hanged or crashed mysteriously. Also, in general, we've tried to avoid pattern rules since they make it hard to see what files are actually being processed. So I'm not against your fix. :) However, I think it might be possible to generalize it slightly to avoid the duplicate code. /Magnus > 12 mar 2015 kl. 15:34 skrev Volker Simonis : > > Hi, > > I understand that I'm a little late to the game but I just run into > this problem myself:) > > The funny thing is that this problem doesn't occur with MinGW/MSYS but > just with Cygwin and I can't understand why? > > We have a little special setup here at SAP: we do the Windows builds > with MinGW/MSYS and by default we always build with > --disable-zip-debug-info. So until now we had no problems. > > Now I started to migrate our build to Cygwin (but still with > --disable-zip-debug-info) and run into the problem. > > I think the origin of the dependency on the .map (and .pdb) files is > clear - it is set right in SetupNativeCompilation if we don't want to > zip the debug information (i.e. --disable-zip-debug-info): > > ifeq ($(ZIP_DEBUGINFO_FILES), true) > ... > else > ifeq ($(OPENJDK_TARGET_OS), windows) > $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ > $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb > > But we also have the following pattern rule in SetupNativeCompilation > which should copy the .map and .pdb from OBJECT_DIR to OUTPUT_DIR: > > ifneq ($$($1_OUTPUT_DIR),$$($1_OBJECT_DIR)) > $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/% > $(CP) $$< $$@ > endif > > This rule works perfectly with MinGW/MSYS but it doesn't get triggered > with Cygwin. And that's the reason why we get the error "*** No rule > to make target `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map'" > which says that it can not make the .map file in the OUTPUT_DIR. But > notice that the .map file is there in the OBJECT_DIR directory (i.e. > ../objs/libverify/verify.map), but make under Cygwin somehow doesn't > recognize that there's a rule to copy it over to the OUTPUT_DIR > directory. > > I tried the workaround proposed by Magnus' but unfortunately it > doesn't work. I think that's because the problem is not that the .map > files are not created - the problem is that they are not copied over > to the OUTPUT_DIR. > > So here's what really helped: > > ifeq ($(OPENJDK_TARGET_OS), windows) > $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ > $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb > > $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map : > $$($1_OBJECT_DIR)/$$($1_LIBRARY).map > echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" > $(CP) $$< $$@ > $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb : > $$($1_OBJECT_DIR)/$$($1_LIBRARY).pdb > echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" > $(CP) $$< $$@ > > And you need the same fix for the PROGRAM build part: > > ifeq ($(OPENJDK_TARGET_OS), windows) > $1 += $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map \ > $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb > > $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map : > $$($1_OBJECT_DIR)/$$($1_PROGRAM).map > echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" > $(CP) $$< $$@ > $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb : > $$($1_OBJECT_DIR)/$$($1_PROGRAM).pdb > echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" > $(CP) $$< $$@ > > So for me this works now and I will change our internal build accordingly. > > I don't know if there's any interest of bringing this to jdk8u. I just > though I'll let you know:) > > It would also be interesting if somebody has some explanation for why > the pattern rule for copying the .map files works under MinGW/MSYS but > not under Cygwin. > > Regards, > Volker > >> On Wed, Nov 5, 2014 at 2:00 PM, David Holmes wrote: >>> On 5/11/2014 10:27 PM, Magnus Ihse Bursie wrote: >>> >>>> On 2014-11-05 13:25, Magnus Ihse Bursie wrote: >>>> >>>> I even have a vague memory of a fix along these lines in jdk9. If >>>> that's correct, it's probably due for backporting. I'll see if I can >>>> locate it. >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8025936 >>> >>> It might be some work backporting it though, the comments in the bug >>> says it needed to be substantially rewritten due to changes in JDK9. >> >> >> Thanks Magnus. Seems this is unlikely to be fixed then - which means I can't >> test what I'm working on for the case where we don't zip the debuginfo files >> :( >> >> David >> >>> /Magnus From erik.gahlin at oracle.com Thu Mar 12 20:53:23 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 12 Mar 2015 21:53:23 +0100 Subject: RFR: JDK-8075056 Remove Version.java.template from jconsole In-Reply-To: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> References: <49906944-9257-4233-83D9-5595758FA2DE@oracle.com> Message-ID: <5501FCC3.3010905@oracle.com> Looks good, jconsole now compile in Eclipse! Erik Staffan Larsen skrev 2015-03-12 13:54: > The build for jconsole currently takes a template file and inserts the > version number of the build into the file. We can simplify this by > removing the template file and reading the java.runtime.version system > property at runtime. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075056 > webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/ > > > Thanks, > /Staffan From joe.darcy at oracle.com Fri Mar 13 06:45:37 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 12 Mar 2015 23:45:37 -0700 Subject: JDK 9 RFR of doclint updates to cover langtools API Message-ID: <55028791.10408@oracle.com> Hello, As a follow-up to the recent work to add doclint flags to the build of various modules, please review the additional patch below to add such coverage to the API defined in the langtools repo. (The change to java.desktop deletes a trailing space character.) Thanks, -Joe diff -r ac80b5d194b1 make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk Thu Mar 12 12:30:36 2015 -0700 +++ b/make/CompileJavaModules.gmk Thu Mar 12 23:42:43 2015 -0700 @@ -90,12 +90,16 @@ ################################################################################ +java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' + +################################################################################ + java.datatransfer_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' java.datatransfer_COPY := flavormap.properties ################################################################################ -java.desktop_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-missing,-reference '-Xdoclint/package:java.*,javax.*' +java.desktop_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-missing,-reference '-Xdoclint/package:java.*,javax.*' java.desktop_COPY := .gif .png .wav .txt .xml .css .pf java.desktop_CLEAN := iio-plugin.properties cursors.properties @@ -336,6 +340,7 @@ ################################################################################ +jdk.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:-com.sun.tools.*' jdk.compiler_COPY := javax.tools.JavaCompilerTool jdk.compiler_CLEAN_FILES := $(wildcard \ $(patsubst %, $(JDK_TOPDIR)/src/jdk.compiler/share/classes/%/*.properties, \ From magnus.ihse.bursie at oracle.com Fri Mar 13 09:01:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 13 Mar 2015 10:01:55 +0100 Subject: JDK 9 RFR of doclint updates to cover langtools API In-Reply-To: <55028791.10408@oracle.com> References: <55028791.10408@oracle.com> Message-ID: <5502A783.3010006@oracle.com> On 2015-03-13 07:45, joe darcy wrote: > Hello, > > As a follow-up to the recent work to add doclint flags to the build of > various modules, please review the additional patch below to add such > coverage to the API defined in the langtools repo. > > (The change to java.desktop deletes a trailing space character.) Looks good to me. /Magnus > > Thanks, > > -Joe > > diff -r ac80b5d194b1 make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk Thu Mar 12 12:30:36 2015 -0700 > +++ b/make/CompileJavaModules.gmk Thu Mar 12 23:42:43 2015 -0700 > @@ -90,12 +90,16 @@ > > ################################################################################ > > > +java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference > '-Xdoclint/package:java.*,javax.*' > + > +################################################################################ > > + > java.datatransfer_ADD_JAVAC_FLAGS := > -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' > java.datatransfer_COPY := flavormap.properties > > ################################################################################ > > > -java.desktop_ADD_JAVAC_FLAGS := > -Xdoclint:all/protected,-missing,-reference > '-Xdoclint/package:java.*,javax.*' > +java.desktop_ADD_JAVAC_FLAGS := > -Xdoclint:all/protected,-missing,-reference > '-Xdoclint/package:java.*,javax.*' > java.desktop_COPY := .gif .png .wav .txt .xml .css .pf > java.desktop_CLEAN := iio-plugin.properties cursors.properties > > @@ -336,6 +340,7 @@ > > ################################################################################ > > > +jdk.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:-com.sun.tools.*' > jdk.compiler_COPY := javax.tools.JavaCompilerTool > jdk.compiler_CLEAN_FILES := $(wildcard \ > $(patsubst %, > $(JDK_TOPDIR)/src/jdk.compiler/share/classes/%/*.properties, \ > From magnus.ihse.bursie at oracle.com Fri Mar 13 12:37:04 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 13 Mar 2015 13:37:04 +0100 Subject: RFR: JDK-8075054 Mixed case Windows path break native dependency checks Message-ID: <5502D9F0.8080709@oracle.com> Bug description: If the top-level directory of the forest contains mixed case elements in the path, then the script which checks for native C/C++ headers dependencies doesn't work properly. This happens because Visual Studio compiler sometimes (?) produce lower-case only paths when invoked with the -showIncludes option used in the dependency tracking, and the script doesn't match these paths with the mixed case paths produced from the top-level directory. For example, if the top-level directory is /cygdrive/c/Vadim/jdk9, then the cl.exe invocation cmdline looks like this: /cygdrive/c/Vadim/jdk9/.../fixpath.exe -c ...cl ... -c -showIncludes ... /cygdrive/c/Vadim/jdk9/...foo.cpp | tee ... foo.d.raw The .d.raw file contains these lines (note the lowercase path): Note: including file: c:\vadim\jdk9-cpu\jdk\src\java.desktop\share\native\foo.h My proposed fix: diff --git a/make/common/NativeCompilation.gmk b/make/common/NativeCompilation.gmk --- a/make/common/NativeCompilation.gmk +++ b/make/common/NativeCompilation.gmk @@ -60,7 +60,7 @@ -e 's|Note: including file: *||' \ -e 's|\\|/|g' \ -e 's|^\([a-zA-Z]\):|$(UNIX_PATH_PREFIX)/\1|g' \ - -e '/$(subst /,\/,$(TOPDIR))/!d' \ + -e '\|$(TOPDIR)|I !d' \ -e 's|$$$$| \\|g' \ # @@ -153,7 +153,7 @@ exit `cat $$($1_$2_DEP).exitvalue` $(RM) $$($1_$2_DEP).exitvalue ($(ECHO) $$@: \\ \ - && $(SED) $(WINDOWS_SHOWINCLUDE_SED_PATTERN) $$($1_$2_DEP).raw) > $$($1_$2_DEP) + && $(SED) $(WINDOWS_SHOWINCLUDE_SED_PATTERN) $$($1_$2_DEP).raw) | $(SORT) -u > $$($1_$2_DEP) endif # Create a dependency target file from the dependency file. # Solution suggested by http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ Some comments might be warranted. I learned a bit about sed expressions when fixing this. :) For those who didn't know, sed expressions consists of two parts, an "address" and a "command". A typical "s/foo/bar/" is just the command "s" with some arguments. The "s" command allows the separator to be changed from / to anything else, eg "s!foo!bar!", and without an address, it works on all lines. The problematic line is instead using the "d" (delete), or more precisely, the "!d" (not delete) command. The expression in front is the "address", which in this case is a regexp. So lines matching the regexp would not be deleted (but all others will). Since TOPDIR contains slashes, the old expression used make $(subst) to espace these slashes, so they wouldn't be interpreted as ending the address regexp. A better solution is to use a different character, but for the address, this require the regexp to be preceeded by a backslash. Hence, e.g. "\|foo| d" would delete all lines matching foo. After the expression is what solves this bug. It is an uppercase I, which is a GNU sed extension to make the regexp case insensitive. While it is available in GNU sed only, this is not a problem since it's only being used on Windows, where only GNU sed is supported. The second changed line is strictly not needed to fix the bug, but removes the prolific duplication of header files that the .d files had on Windows before, drastically reducing them in size. Bug: https://bugs.openjdk.java.net/browse/JDK-8075054 /Magnus From erik.joelsson at oracle.com Fri Mar 13 12:56:50 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Mar 2015 13:56:50 +0100 Subject: RFR: JDK-8075054 Mixed case Windows path break native dependency checks In-Reply-To: <5502D9F0.8080709@oracle.com> References: <5502D9F0.8080709@oracle.com> Message-ID: <5502DE92.3000700@oracle.com> Looks good! /Erik On 2015-03-13 13:37, Magnus Ihse Bursie wrote: > Bug description: > > If the top-level directory of the forest contains mixed case elements > in the path, then the script which checks for native C/C++ headers > dependencies doesn't work properly. > This happens because Visual Studio compiler sometimes (?) produce > lower-case only paths when invoked with the -showIncludes option used > in the dependency tracking, and the script doesn't match these paths > with the mixed case paths produced from the top-level directory. > > For example, if the top-level directory is /cygdrive/c/Vadim/jdk9, > then the cl.exe invocation cmdline looks like this: > /cygdrive/c/Vadim/jdk9/.../fixpath.exe -c ...cl ... -c -showIncludes > ... /cygdrive/c/Vadim/jdk9/...foo.cpp | tee ... foo.d.raw > The .d.raw file contains these lines (note the lowercase path): > Note: including file: > c:\vadim\jdk9-cpu\jdk\src\java.desktop\share\native\foo.h > > My proposed fix: > > diff --git a/make/common/NativeCompilation.gmk > b/make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk > +++ b/make/common/NativeCompilation.gmk > @@ -60,7 +60,7 @@ > -e 's|Note: including file: *||' \ > -e 's|\\|/|g' \ > -e 's|^\([a-zA-Z]\):|$(UNIX_PATH_PREFIX)/\1|g' \ > - -e '/$(subst /,\/,$(TOPDIR))/!d' \ > + -e '\|$(TOPDIR)|I !d' \ > -e 's|$$$$| \\|g' \ > # > > @@ -153,7 +153,7 @@ > exit `cat $$($1_$2_DEP).exitvalue` > $(RM) $$($1_$2_DEP).exitvalue > ($(ECHO) $$@: \\ \ > - && $(SED) $(WINDOWS_SHOWINCLUDE_SED_PATTERN) > $$($1_$2_DEP).raw) > $$($1_$2_DEP) > + && $(SED) $(WINDOWS_SHOWINCLUDE_SED_PATTERN) > $$($1_$2_DEP).raw) | $(SORT) -u > $$($1_$2_DEP) > endif > # Create a dependency target file from the dependency file. > # Solution suggested by > http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ > > Some comments might be warranted. > > I learned a bit about sed expressions when fixing this. :) For those > who didn't know, sed expressions consists of two parts, an "address" > and a "command". A typical "s/foo/bar/" is just the command "s" with > some arguments. The "s" command allows the separator to be changed > from / to anything else, eg "s!foo!bar!", and without an address, it > works on all lines. > > The problematic line is instead using the "d" (delete), or more > precisely, the "!d" (not delete) command. The expression in front is > the "address", which in this case is a regexp. So lines matching the > regexp would not be deleted (but all others will). Since TOPDIR > contains slashes, the old expression used make $(subst) to espace > these slashes, so they wouldn't be interpreted as ending the address > regexp. A better solution is to use a different character, but for the > address, this require the regexp to be preceeded by a backslash. > Hence, e.g. "\|foo| d" would delete all lines matching foo. > > After the expression is what solves this bug. It is an uppercase I, > which is a GNU sed extension to make the regexp case insensitive. > While it is available in GNU sed only, this is not a problem since > it's only being used on Windows, where only GNU sed is supported. > > The second changed line is strictly not needed to fix the bug, but > removes the prolific duplication of header files that the .d files had > on Windows before, drastically reducing them in size. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075054 > > /Magnus > From tim.bell at oracle.com Fri Mar 13 13:50:14 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 13 Mar 2015 06:50:14 -0700 Subject: RFR: JDK-8075054 Mixed case Windows path break native dependency checks In-Reply-To: <5502DE92.3000700@oracle.com> References: <5502D9F0.8080709@oracle.com> <5502DE92.3000700@oracle.com> Message-ID: <5502EB16.7080902@oracle.com> Magnus: Looks good to me as well. Tim On 03/13/15 05:56, Erik Joelsson wrote: > Looks good! > > /Erik > > On 2015-03-13 13:37, Magnus Ihse Bursie wrote: >> Bug description: >> >> If the top-level directory of the forest contains mixed case elements >> in the path, then the script which checks for native C/C++ headers >> dependencies doesn't work properly. >> This happens because Visual Studio compiler sometimes (?) produce >> lower-case only paths when invoked with the -showIncludes option used >> in the dependency tracking, and the script doesn't match these paths >> with the mixed case paths produced from the top-level directory. >> >> For example, if the top-level directory is /cygdrive/c/Vadim/jdk9, >> then the cl.exe invocation cmdline looks like this: >> /cygdrive/c/Vadim/jdk9/.../fixpath.exe -c ...cl ... -c -showIncludes >> ... /cygdrive/c/Vadim/jdk9/...foo.cpp | tee ... foo.d.raw >> The .d.raw file contains these lines (note the lowercase path): >> Note: including file: >> c:\vadim\jdk9-cpu\jdk\src\java.desktop\share\native\foo.h >> >> My proposed fix: >> >> diff --git a/make/common/NativeCompilation.gmk >> b/make/common/NativeCompilation.gmk >> --- a/make/common/NativeCompilation.gmk >> +++ b/make/common/NativeCompilation.gmk >> @@ -60,7 +60,7 @@ >> -e 's|Note: including file: *||' \ >> -e 's|\\|/|g' \ >> -e 's|^\([a-zA-Z]\):|$(UNIX_PATH_PREFIX)/\1|g' \ >> - -e '/$(subst /,\/,$(TOPDIR))/!d' \ >> + -e '\|$(TOPDIR)|I !d' \ >> -e 's|$$$$| \\|g' \ >> # >> >> @@ -153,7 +153,7 @@ >> exit `cat $$($1_$2_DEP).exitvalue` >> $(RM) $$($1_$2_DEP).exitvalue >> ($(ECHO) $$@: \\ \ >> - && $(SED) $(WINDOWS_SHOWINCLUDE_SED_PATTERN) >> $$($1_$2_DEP).raw) > $$($1_$2_DEP) >> + && $(SED) $(WINDOWS_SHOWINCLUDE_SED_PATTERN) >> $$($1_$2_DEP).raw) | $(SORT) -u > $$($1_$2_DEP) >> endif >> # Create a dependency target file from the dependency file. >> # Solution suggested by >> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ >> >> Some comments might be warranted. >> >> I learned a bit about sed expressions when fixing this. :) For those >> who didn't know, sed expressions consists of two parts, an "address" >> and a "command". A typical "s/foo/bar/" is just the command "s" with >> some arguments. The "s" command allows the separator to be changed >> from / to anything else, eg "s!foo!bar!", and without an address, it >> works on all lines. >> >> The problematic line is instead using the "d" (delete), or more >> precisely, the "!d" (not delete) command. The expression in front is >> the "address", which in this case is a regexp. So lines matching the >> regexp would not be deleted (but all others will). Since TOPDIR >> contains slashes, the old expression used make $(subst) to espace >> these slashes, so they wouldn't be interpreted as ending the address >> regexp. A better solution is to use a different character, but for >> the address, this require the regexp to be preceeded by a backslash. >> Hence, e.g. "\|foo| d" would delete all lines matching foo. >> >> After the expression is what solves this bug. It is an uppercase I, >> which is a GNU sed extension to make the regexp case insensitive. >> While it is available in GNU sed only, this is not a problem since >> it's only being used on Windows, where only GNU sed is supported. >> >> The second changed line is strictly not needed to fix the bug, but >> removes the prolific duplication of header files that the .d files >> had on Windows before, drastically reducing them in size. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075054 >> >> /Magnus >> > From erik.joelsson at oracle.com Fri Mar 13 14:08:14 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Mar 2015 15:08:14 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS Message-ID: <5502EF4E.2060006@oracle.com> Hello, While working on the new Hotspot makefiles in build-infra I noticed this problem. When introducing devkits for Solaris, we rely on the variables EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT specific flags into the hotspot build. However, these flags aren't consistently used in the Hotspot build for all the native libraries. This patch adds the variables to all missing compile and link command lines. It also fixes an issue with saproc.so where the debug info was created off one of the object files instead of the library. Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ /Erik From tim.bell at oracle.com Fri Mar 13 15:55:04 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 13 Mar 2015 08:55:04 -0700 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <5502EF4E.2060006@oracle.com> References: <5502EF4E.2060006@oracle.com> Message-ID: <55030858.8020003@oracle.com> Hello Erik: > While working on the new Hotspot makefiles in build-infra I noticed > this problem. When introducing devkits for Solaris, we rely on the > variables EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate > the SYSROOT specific flags into the hotspot build. However, these > flags aren't consistently used in the Hotspot build for all the native > libraries. > > This patch adds the variables to all missing compile and link command > lines. It also fixes an issue with saproc.so where the debug info was > created off one of the object files instead of the library. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 > Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ Looks good to me. Tim From volker.simonis at gmail.com Fri Mar 13 16:14:06 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Mar 2015 17:14:06 +0100 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: References: <545A082D.1000001@oracle.com> <545A173E.8060908@oracle.com> <545A17BF.7090705@oracle.com> <545A1F86.3090301@oracle.com> Message-ID: On Thu, Mar 12, 2015 at 8:48 PM, Magnus Ihse Bursie wrote: > We have had issues before with pattern rules on Windows/cygwin. An older incarnation of Images.gmk used pattern rules extensively, but it hanged or crashed mysteriously. > > Also, in general, we've tried to avoid pattern rules since they make it hard to see what files are actually being processed. > > So I'm not against your fix. :) Great:) > > However, I think it might be possible to generalize it slightly to avoid the duplicate code. > Sure, I'm not against generalizing it :) The question is just do you consider this worth doing? I'm just asking because this will be jdk8u-only change and I'm not sure how complicated it will be to review this and get it in (because it is actually not a downport of an existing jdk9 change). Regards, Volker > /Magnus > >> 12 mar 2015 kl. 15:34 skrev Volker Simonis : >> >> Hi, >> >> I understand that I'm a little late to the game but I just run into >> this problem myself:) >> >> The funny thing is that this problem doesn't occur with MinGW/MSYS but >> just with Cygwin and I can't understand why? >> >> We have a little special setup here at SAP: we do the Windows builds >> with MinGW/MSYS and by default we always build with >> --disable-zip-debug-info. So until now we had no problems. >> >> Now I started to migrate our build to Cygwin (but still with >> --disable-zip-debug-info) and run into the problem. >> >> I think the origin of the dependency on the .map (and .pdb) files is >> clear - it is set right in SetupNativeCompilation if we don't want to >> zip the debug information (i.e. --disable-zip-debug-info): >> >> ifeq ($(ZIP_DEBUGINFO_FILES), true) >> ... >> else >> ifeq ($(OPENJDK_TARGET_OS), windows) >> $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ >> $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb >> >> But we also have the following pattern rule in SetupNativeCompilation >> which should copy the .map and .pdb from OBJECT_DIR to OUTPUT_DIR: >> >> ifneq ($$($1_OUTPUT_DIR),$$($1_OBJECT_DIR)) >> $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/% >> $(CP) $$< $$@ >> endif >> >> This rule works perfectly with MinGW/MSYS but it doesn't get triggered >> with Cygwin. And that's the reason why we get the error "*** No rule >> to make target `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map'" >> which says that it can not make the .map file in the OUTPUT_DIR. But >> notice that the .map file is there in the OBJECT_DIR directory (i.e. >> ../objs/libverify/verify.map), but make under Cygwin somehow doesn't >> recognize that there's a rule to copy it over to the OUTPUT_DIR >> directory. >> >> I tried the workaround proposed by Magnus' but unfortunately it >> doesn't work. I think that's because the problem is not that the .map >> files are not created - the problem is that they are not copied over >> to the OUTPUT_DIR. >> >> So here's what really helped: >> >> ifeq ($(OPENJDK_TARGET_OS), windows) >> $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \ >> $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb >> >> $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map : >> $$($1_OBJECT_DIR)/$$($1_LIBRARY).map >> echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" >> $(CP) $$< $$@ >> $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb : >> $$($1_OBJECT_DIR)/$$($1_LIBRARY).pdb >> echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" >> $(CP) $$< $$@ >> >> And you need the same fix for the PROGRAM build part: >> >> ifeq ($(OPENJDK_TARGET_OS), windows) >> $1 += $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map \ >> $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb >> >> $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map : >> $$($1_OBJECT_DIR)/$$($1_PROGRAM).map >> echo "Copying .map from OBJECT_DIR to OUTPUT_DIR" >> $(CP) $$< $$@ >> $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb : >> $$($1_OBJECT_DIR)/$$($1_PROGRAM).pdb >> echo "Copying .pdb from OBJECT_DIR to OUTPUT_DIR" >> $(CP) $$< $$@ >> >> So for me this works now and I will change our internal build accordingly. >> >> I don't know if there's any interest of bringing this to jdk8u. I just >> though I'll let you know:) >> >> It would also be interesting if somebody has some explanation for why >> the pattern rule for copying the .map files works under MinGW/MSYS but >> not under Cygwin. >> >> Regards, >> Volker >> >>> On Wed, Nov 5, 2014 at 2:00 PM, David Holmes wrote: >>>> On 5/11/2014 10:27 PM, Magnus Ihse Bursie wrote: >>>> >>>>> On 2014-11-05 13:25, Magnus Ihse Bursie wrote: >>>>> >>>>> I even have a vague memory of a fix along these lines in jdk9. If >>>>> that's correct, it's probably due for backporting. I'll see if I can >>>>> locate it. >>>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8025936 >>>> >>>> It might be some work backporting it though, the comments in the bug >>>> says it needed to be substantially rewritten due to changes in JDK9. >>> >>> >>> Thanks Magnus. Seems this is unlikely to be fixed then - which means I can't >>> test what I'm working on for the case where we don't zip the debuginfo files >>> :( >>> >>> David >>> >>>> /Magnus From mandy.chung at oracle.com Fri Mar 13 18:37:36 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2015 11:37:36 -0700 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54FF28A4.9080303@oracle.com> References: <54F7ADCE.50900@oracle.com> <54FF28A4.9080303@oracle.com> Message-ID: <55032E70.1040302@oracle.com> This module contains both pack200 and unpack200 tools although it only contains the native implementation of unpacker. Naming it as jdk.unpack200 would give an impression that it contains the unpacker only which isn't the case. Like the API java.util.jar.Pack200 class, it's about Pack200 format and it has both Pack200.Packer and Pack200.Unpacker nested interfaces jdk.pack200 represents the tools for Pack200 format that sounds fine to me. Mandy On 3/10/2015 10:23 AM, Kumar Srinivasan wrote: > The changes look ok to me, however I am wondering if the module > could be called jdk.unpack200 and not jdk.pack200 ? since it > contains only the unpacker, and the bin utilities are pack200 and > unpack200. > > Kumar > > On 3/4/2015 5:13 PM, Mandy Chung wrote: >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> > From david.holmes at oracle.com Sat Mar 14 00:08:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 14 Mar 2015 10:08:21 +1000 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <5502EF4E.2060006@oracle.com> References: <5502EF4E.2060006@oracle.com> Message-ID: <55037BF5.5010700@oracle.com> Hi Erik, On 14/03/2015 12:08 AM, Erik Joelsson wrote: > Hello, > > While working on the new Hotspot makefiles in build-infra I noticed this > problem. When introducing devkits for Solaris, we rely on the variables > EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT > specific flags into the hotspot build. However, these flags aren't > consistently used in the Hotspot build for all the native libraries. > > This patch adds the variables to all missing compile and link command > lines. It also fixes an issue with saproc.so where the debug info was > created off one of the object files instead of the library. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 > Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ For linux we primarily (only?) use these to pass cross-compilation flags and so everything that is compiled generally needs the same flags. Outside of cross-compilation though that doesn't necessarily hold. If someone uses EXTRA_CFLAGS as a general customization mechanism it might only be intended for the primary VM build not for secondary libraries like jsig, dtrace and SA. So I'm not sure that this is the right thing to do as really these variables are not quite what people might expect them to be. In general local customizations are better handled by local editing of the appropriate build file. David > /Erik From dean.long at oracle.com Sat Mar 14 19:34:17 2015 From: dean.long at oracle.com (Dean Long) Date: Sat, 14 Mar 2015 12:34:17 -0700 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <55037BF5.5010700@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> Message-ID: <55048D39.4030403@oracle.com> On 3/13/2015 5:08 PM, David Holmes wrote: > Hi Erik, > > On 14/03/2015 12:08 AM, Erik Joelsson wrote: >> Hello, >> >> While working on the new Hotspot makefiles in build-infra I noticed this >> problem. When introducing devkits for Solaris, we rely on the variables >> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >> specific flags into the hotspot build. However, these flags aren't >> consistently used in the Hotspot build for all the native libraries. >> >> This patch adds the variables to all missing compile and link command >> lines. It also fixes an issue with saproc.so where the debug info was >> created off one of the object files instead of the library. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ > > For linux we primarily (only?) use these to pass cross-compilation > flags and so everything that is compiled generally needs the same flags. > > Outside of cross-compilation though that doesn't necessarily hold. If > someone uses EXTRA_CFLAGS as a general customization mechanism it > might only be intended for the primary VM build not for secondary > libraries like jsig, dtrace and SA. > > So I'm not sure that this is the right thing to do as really these > variables are not quite what people might expect them to be. In > general local customizations are better handled by local editing of > the appropriate build file. > Related to that, I noticed that cross-compiler sysroot flags are being included in jdk/make/gensrc/GensrcMisc.gmk when BUILD_CC and BUILD_LD are used, apparently because these flags get added to CFLAGS by default. Is there such thing as BUILD_CFLAGS that BUILD_CC should use? dl > David > >> /Erik From weijun.wang at oracle.com Mon Mar 16 03:12:57 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 Mar 2015 11:12:57 +0800 Subject: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5 Message-ID: Hi All Please review the change at http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ Thanks Max From erik.joelsson at oracle.com Mon Mar 16 08:26:52 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2015 09:26:52 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <55037BF5.5010700@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> Message-ID: <550693CC.7050300@oracle.com> On 2015-03-14 01:08, David Holmes wrote: > Hi Erik, > > On 14/03/2015 12:08 AM, Erik Joelsson wrote: >> Hello, >> >> While working on the new Hotspot makefiles in build-infra I noticed this >> problem. When introducing devkits for Solaris, we rely on the variables >> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >> specific flags into the hotspot build. However, these flags aren't >> consistently used in the Hotspot build for all the native libraries. >> >> This patch adds the variables to all missing compile and link command >> lines. It also fixes an issue with saproc.so where the debug info was >> created off one of the object files instead of the library. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ > > For linux we primarily (only?) use these to pass cross-compilation > flags and so everything that is compiled generally needs the same flags. > > Outside of cross-compilation though that doesn't necessarily hold. If > someone uses EXTRA_CFLAGS as a general customization mechanism it > might only be intended for the primary VM build not for secondary > libraries like jsig, dtrace and SA. > > So I'm not sure that this is the right thing to do as really these > variables are not quite what people might expect them to be. In > general local customizations are better handled by local editing of > the appropriate build file. > Well, the devkit/sysroot CFLAGS and LDFLAGS should be considered more or less equal to cross compilation arguments. Everything being compiled for the target platform should use them. If EXTRA_CFLAGS is not a good option for providing these compiler options, then it shouldn't be used for cross compilation on linux either. I figured that since we are already using them that way on linux, extending that usage to Solaris would be the right thing to do. If it isn't, should I define a new set of variables for transporting these options for both platforms instead? I still think using EXTRA_*FLAGS is a viable solution for my usecase and that anyone trying to use these variables and expecting them to only apply selectively is on a slippery slope. /Erik > David > >> /Erik From erik.joelsson at oracle.com Mon Mar 16 08:29:48 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2015 09:29:48 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <55048D39.4030403@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> <55048D39.4030403@oracle.com> Message-ID: <5506947C.6060901@oracle.com> On 2015-03-14 20:34, Dean Long wrote: > > Related to that, I noticed that cross-compiler sysroot flags are being > included in > jdk/make/gensrc/GensrcMisc.gmk when BUILD_CC and BUILD_LD are used, > apparently because these flags get added to CFLAGS by default. Is > there such > thing as BUILD_CFLAGS that BUILD_CC should use? > Yes, this is a problem. We currently have no way of overriding those flags for specific compilations, and I think we should. A workaround is to empty the SYSROOT_*FLAGS variables before calling SetupNativeCompilation when using BUILD_CC. /Erik From erik.joelsson at oracle.com Mon Mar 16 08:31:38 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2015 09:31:38 +0100 Subject: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5 In-Reply-To: References: Message-ID: <550694EA.3060603@oracle.com> Looks good to me. Thanks for fixing warnings! /Erik On 2015-03-16 04:12, Wang Weijun wrote: > Hi All > > Please review the change at > > http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ > > Thanks > Max > From magnus.ihse.bursie at oracle.com Mon Mar 16 14:04:38 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Mar 2015 15:04:38 +0100 Subject: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5 In-Reply-To: References: Message-ID: <5506E2F6.3060005@oracle.com> On 2015-03-16 04:12, Wang Weijun wrote: > Hi All > > Please review the change at > > http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ > > Thanks > Max > Looks good to me. Thanks for fixing this. I'm just curious about the new deprecated-declarations warning. I didn't see it when I excluded the warnings for the library in the first place. Did it show up when you fixed the other warnings, or did you see it all the time? If so, what compiler version are you using? /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 16 14:24:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Mar 2015 15:24:06 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <550693CC.7050300@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> <550693CC.7050300@oracle.com> Message-ID: <5506E786.1000502@oracle.com> On 2015-03-16 09:26, Erik Joelsson wrote: > > On 2015-03-14 01:08, David Holmes wrote: >> Hi Erik, >> >> On 14/03/2015 12:08 AM, Erik Joelsson wrote: >>> Hello, >>> >>> While working on the new Hotspot makefiles in build-infra I noticed >>> this >>> problem. When introducing devkits for Solaris, we rely on the variables >>> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >>> specific flags into the hotspot build. However, these flags aren't >>> consistently used in the Hotspot build for all the native libraries. >>> >>> This patch adds the variables to all missing compile and link command >>> lines. It also fixes an issue with saproc.so where the debug info was >>> created off one of the object files instead of the library. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >>> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ The changes look good to me. >> >> For linux we primarily (only?) use these to pass cross-compilation >> flags and so everything that is compiled generally needs the same flags. >> >> Outside of cross-compilation though that doesn't necessarily hold. If >> someone uses EXTRA_CFLAGS as a general customization mechanism it >> might only be intended for the primary VM build not for secondary >> libraries like jsig, dtrace and SA. >> >> So I'm not sure that this is the right thing to do as really these >> variables are not quite what people might expect them to be. In >> general local customizations are better handled by local editing of >> the appropriate build file. >> > Well, the devkit/sysroot CFLAGS and LDFLAGS should be considered more > or less equal to cross compilation arguments. Everything being > compiled for the target platform should use them. If EXTRA_CFLAGS is > not a good option for providing these compiler options, then it > shouldn't be used for cross compilation on linux either. I figured > that since we are already using them that way on linux, extending that > usage to Solaris would be the right thing to do. If it isn't, should I > define a new set of variables for transporting these options for both > platforms instead? > > I still think using EXTRA_*FLAGS is a viable solution for my usecase > and that anyone trying to use these variables and expecting them to > only apply selectively is on a slippery slope. I agree. Another way to put it is there has been missing functionality on solaris compared to linux, which has just not really been noticed until now. /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 16 14:26:59 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Mar 2015 15:26:59 +0100 Subject: Windows build failure in JDK8 with --disable-zip-debug-info In-Reply-To: References: <545A082D.1000001@oracle.com> <545A173E.8060908@oracle.com> <545A17BF.7090705@oracle.com> <545A1F86.3090301@oracle.com> Message-ID: <5506E833.3080903@oracle.com> On 2015-03-13 17:14, Volker Simonis wrote: > >> However, I think it might be possible to generalize it slightly to avoid the duplicate code. >> > Sure, I'm not against generalizing it :) > > The question is just do you consider this worth doing? > I'm just asking because this will be jdk8u-only change and I'm not > sure how complicated it will be to review this and get it in (because > it is actually not a downport of an existing jdk9 change). Right, I forgot. Yeah, it's probably not worth putting more energy into it then. /Magnus From erik.joelsson at oracle.com Mon Mar 16 14:51:01 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2015 15:51:01 +0100 Subject: RFR: JDK-8075236: Change layout of gcov .gcno files in symbols image Message-ID: <5506EDD5.6040508@oracle.com> Hello, In JDK-8073021 I added support for compiling with gcov support for native code coverage. When trying to use this it was discovered that the file layout in the new symbols image need to exactly match the layout of the .gcno files in the build directory. Otherwise the runtime data files created by gcov will not match properly. I originally tried to tidy up the layout in the symbols file into: symbols/gcov/hotspot/{client,server}/*.gcno symbols/gcov/jdk/$(module)/$(lib)/*.gcno What we actually need is the (internal) layout of the intermediate build results: symbols/gcov/hotspot/linux_amd64_compiler2/product/*.gcno symbols/gcov/support/native/$(module)/$(lib)/*.gcno Our internal layout for intermediate build results is not something we want to export as an API, but in this case, the file layout just has to match the paths that get encoded into the binaries. Bug: https://bugs.openjdk.java.net/browse/JDK-8075236 Webrev: http://cr.openjdk.java.net/~erikj/8075236/webrev.root.01/ /Erik From magnus.ihse.bursie at oracle.com Mon Mar 16 14:56:53 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Mar 2015 15:56:53 +0100 Subject: RFR: JDK-8075236: Change layout of gcov .gcno files in symbols image In-Reply-To: <5506EDD5.6040508@oracle.com> References: <5506EDD5.6040508@oracle.com> Message-ID: <5506EF35.9060400@oracle.com> On 2015-03-16 15:51, Erik Joelsson wrote: > Hello, > > In JDK-8073021 I added support for compiling with gcov support for > native code coverage. When trying to use this it was discovered that > the file layout in the new symbols image need to exactly match the > layout of the .gcno files in the build directory. Otherwise the > runtime data files created by gcov will not match properly. > > I originally tried to tidy up the layout in the symbols file into: > > symbols/gcov/hotspot/{client,server}/*.gcno > symbols/gcov/jdk/$(module)/$(lib)/*.gcno > > What we actually need is the (internal) layout of the intermediate > build results: > > symbols/gcov/hotspot/linux_amd64_compiler2/product/*.gcno > symbols/gcov/support/native/$(module)/$(lib)/*.gcno > > Our internal layout for intermediate build results is not something we > want to export as an API, but in this case, the file layout just has > to match the paths that get encoded into the binaries. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075236 > Webrev: http://cr.openjdk.java.net/~erikj/8075236/webrev.root.01/ Looks good to me. /Magnus From weijun.wang at oracle.com Mon Mar 16 15:19:41 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 Mar 2015 23:19:41 +0800 Subject: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5 In-Reply-To: <5506E2F6.3060005@oracle.com> References: <5506E2F6.3060005@oracle.com> Message-ID: <342E2791-8CC9-44BC-99A9-1DC7365D357C@oracle.com> > On Mar 16, 2015, at 22:04, Magnus Ihse Bursie wrote: > > On 2015-03-16 04:12, Wang Weijun wrote: >> Hi All >> >> Please review the change at >> >> http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ >> >> Thanks >> Max >> > > Looks good to me. Thanks for fixing this. > > I'm just curious about the new deprecated-declarations warning. I didn't see it when I excluded the warnings for the library in the first place. Did it show up when you fixed the other warnings, or did you see it all the time? If so, what compiler version are you using? All the time. It's in /System/Library/Frameworks/Kerberos.framework/Headers/krb5.h. All those "KERBEROS_APPLE_DEPRECATED("use GSS.framework")" words. $ /usr/bin/clang -v Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix --Max > > /Magnus From tim.bell at oracle.com Mon Mar 16 15:43:42 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 16 Mar 2015 08:43:42 -0700 Subject: RFR: JDK-8075236: Change layout of gcov .gcno files in symbols image In-Reply-To: <5506EF35.9060400@oracle.com> References: <5506EDD5.6040508@oracle.com> <5506EF35.9060400@oracle.com> Message-ID: <5506FA2E.50300@oracle.com> Hello Erik On 03/16/15 07:56, Magnus Ihse Bursie wrote: > On 2015-03-16 15:51, Erik Joelsson wrote: >> Hello, >> >> In JDK-8073021 I added support for compiling with gcov support for >> native code coverage. When trying to use this it was discovered that >> the file layout in the new symbols image need to exactly match the >> layout of the .gcno files in the build directory. Otherwise the >> runtime data files created by gcov will not match properly. >> >> I originally tried to tidy up the layout in the symbols file into: >> >> symbols/gcov/hotspot/{client,server}/*.gcno >> symbols/gcov/jdk/$(module)/$(lib)/*.gcno >> >> What we actually need is the (internal) layout of the intermediate >> build results: >> >> symbols/gcov/hotspot/linux_amd64_compiler2/product/*.gcno >> symbols/gcov/support/native/$(module)/$(lib)/*.gcno >> >> Our internal layout for intermediate build results is not something >> we want to export as an API, but in this case, the file layout just >> has to match the paths that get encoded into the binaries. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075236 >> Webrev: http://cr.openjdk.java.net/~erikj/8075236/webrev.root.01/ > > Looks good to me. > > /Magnus Looks good to me as well. Tim From philip.race at oracle.com Mon Mar 16 20:41:24 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Mar 2015 13:41:24 -0700 Subject: RFR: 8075277 : JDK is still building X11 related Java files on OSX Message-ID: <55073FF4.9070606@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8075277 Fix: http://cr.openjdk.java.net/~prr/8075277/ Although a more complete fix would do something like refactor the source files, as that would be less fragile amongst other things, this at least gets us into a better shape with minimal disruption - and solves my immediate problem :-) However, it was not sufficient to modify the build file since NativeFont needs to have an implementation and the unix (aka X11) one just drags in everything else. So I have a stub version, the same as on Windows. And it is not clear to me why there was an unused reference to FontConfigManager in the Mac code. Removing it breaks a link that dragged in X11 related code. I expect the files shipped on OS X to go down as a result of removing these 'dead' ones. I would also have got rid of the Windows L&F but that needs a bit of work on the Swing side first : https://bugs.openjdk.java.net/browse/JDK-8075255 -phil. From Sergey.Bylokhov at oracle.com Mon Mar 16 21:18:26 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Mar 2015 14:18:26 -0700 Subject: RFR: 8075277 : JDK is still building X11 related Java files on OSX In-Reply-To: <55073FF4.9070606@oracle.com> References: <55073FF4.9070606@oracle.com> Message-ID: <550748A2.9020604@oracle.com> Hi, Phil Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" using $(wildcard, or we still using some files on osx from the unix folder? > > Although a more complete fix would do something like refactor the > source files, > as that would be less fragile amongst other things, this at least gets > us into a > better shape with minimal disruption - and solves my immediate problem > :-) There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254 > And it is not clear to me why there was an unused reference to > FontConfigManager in the Mac code. Removing it breaks > a link that dragged in X11 related code. > > I expect the files shipped on OS X to go down as a result of > removing these 'dead' ones. > I would also have got rid of the Windows L&F but that needs > a bit of work on the Swing side first : > https://bugs.openjdk.java.net/browse/JDK-8075255 > > -phil. > -- Best regards, Sergey. From david.dehaven at oracle.com Mon Mar 16 21:33:59 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 16 Mar 2015 14:33:59 -0700 Subject: RFR: 8075277 : JDK is still building X11 related Java files on OSX In-Reply-To: <550748A2.9020604@oracle.com> References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com> Message-ID: Previously, things were too .. "jiggly" to just remove everything listed lest the whole structure collapsed. Nice to see more effort on this front. Yes, OSX is still a cross-breed between "solaris" source and it's own source, hence the overly complicated exclusion patterns. Or was, maybe things changed when I wasn't looking (one can dream). -DrD- > Hi, Phil > Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" using $(wildcard, or we still using some files on osx from the unix folder? > >> >> Although a more complete fix would do something like refactor the source files, >> as that would be less fragile amongst other things, this at least gets us into a >> better shape with minimal disruption - and solves my immediate problem :-) > There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254 >> And it is not clear to me why there was an unused reference to >> FontConfigManager in the Mac code. Removing it breaks >> a link that dragged in X11 related code. >> >> I expect the files shipped on OS X to go down as a result of >> removing these 'dead' ones. >> I would also have got rid of the Windows L&F but that needs >> a bit of work on the Swing side first : https://bugs.openjdk.java.net/browse/JDK-8075255 >> >> -phil. >> > > > -- > Best regards, Sergey. > From philip.race at oracle.com Mon Mar 16 22:05:30 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Mar 2015 15:05:30 -0700 Subject: RFR: 8075277 : JDK is still building X11 related Java files on OSX In-Reply-To: <550748A2.9020604@oracle.com> References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com> Message-ID: <550753AA.4050804@oracle.com> There are some files in sun/print some directories still being used but for the files explicitly listed, then in each case all .java files in those directories are now unused. So yes, I can make this cleaner and less fragile too! http://cr.openjdk.java.net/~prr/8075277.1/ -phil.* * On 3/16/15 2:18 PM, Sergey Bylokhov wrote: > Hi, Phil > Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" > using $(wildcard, or we still using some files on osx from the unix > folder? > >> >> Although a more complete fix would do something like refactor the >> source files, >> as that would be less fragile amongst other things, this at least >> gets us into a >> better shape with minimal disruption - and solves my immediate >> problem :-) > There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254 >> And it is not clear to me why there was an unused reference to >> FontConfigManager in the Mac code. Removing it breaks >> a link that dragged in X11 related code. >> >> I expect the files shipped on OS X to go down as a result of >> removing these 'dead' ones. >> I would also have got rid of the Windows L&F but that needs >> a bit of work on the Swing side first : >> https://bugs.openjdk.java.net/browse/JDK-8075255 >> >> -phil. >> > > > -- > Best regards, Sergey. From philip.race at oracle.com Mon Mar 16 23:05:08 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Mar 2015 16:05:08 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11 related Java files on OSX In-Reply-To: <550753AA.4050804@oracle.com> References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com> <550753AA.4050804@oracle.com> Message-ID: <550761A4.7040001@oracle.com> One more update: http://cr.openjdk.java.net/~prr/8075277.2/ just adds sun/awt/motif/* to the exclude list. I'm deleting that directory in another fix but those without those changes need it excluded too -phil. On 3/16/15 3:05 PM, Phil Race wrote: > There are some files in sun/print some directories still being used > but for the files > explicitly listed, then in each case all .java files in those > directories are now unused. > So yes, I can make this cleaner and less fragile too! > > http://cr.openjdk.java.net/~prr/8075277.1/ > > -phil.* > * > On 3/16/15 2:18 PM, Sergey Bylokhov wrote: >> Hi, Phil >> Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" >> using $(wildcard, or we still using some files on osx from the unix >> folder? >> >>> >>> Although a more complete fix would do something like refactor the >>> source files, >>> as that would be less fragile amongst other things, this at least >>> gets us into a >>> better shape with minimal disruption - and solves my immediate >>> problem :-) >> There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254 >>> And it is not clear to me why there was an unused reference to >>> FontConfigManager in the Mac code. Removing it breaks >>> a link that dragged in X11 related code. >>> >>> I expect the files shipped on OS X to go down as a result of >>> removing these 'dead' ones. >>> I would also have got rid of the Windows L&F but that needs >>> a bit of work on the Swing side first : >>> https://bugs.openjdk.java.net/browse/JDK-8075255 >>> >>> -phil. >>> >> >> >> -- >> Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Tue Mar 17 00:05:46 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Mar 2015 17:05:46 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11 related Java files on OSX In-Reply-To: <550761A4.7040001@oracle.com> References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com> <550753AA.4050804@oracle.com> <550761A4.7040001@oracle.com> Message-ID: <55076FDA.9050009@oracle.com> Hi, Phil. The fix looks fine. btw the change of bootmodules.jimage: old: 56961944 new: 55879357 16.03.15 16:05, Phil Race wrote: > One more update: http://cr.openjdk.java.net/~prr/8075277.2/ > > just adds sun/awt/motif/* to the exclude list. > > I'm deleting that directory in another fix but those without those > changes need it > excluded too > > -phil. > > On 3/16/15 3:05 PM, Phil Race wrote: >> There are some files in sun/print some directories still being used >> but for the files >> explicitly listed, then in each case all .java files in those >> directories are now unused. >> So yes, I can make this cleaner and less fragile too! >> >> http://cr.openjdk.java.net/~prr/8075277.1/ >> >> -phil.* >> * >> On 3/16/15 2:18 PM, Sergey Bylokhov wrote: >>> Hi, Phil >>> Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" >>> using $(wildcard, or we still using some files on osx from the unix >>> folder? >>> >>>> >>>> Although a more complete fix would do something like refactor the >>>> source files, >>>> as that would be less fragile amongst other things, this at least >>>> gets us into a >>>> better shape with minimal disruption - and solves my immediate >>>> problem :-) >>> There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254 >>>> And it is not clear to me why there was an unused reference to >>>> FontConfigManager in the Mac code. Removing it breaks >>>> a link that dragged in X11 related code. >>>> >>>> I expect the files shipped on OS X to go down as a result of >>>> removing these 'dead' ones. >>>> I would also have got rid of the Windows L&F but that needs >>>> a bit of work on the Swing side first : >>>> https://bugs.openjdk.java.net/browse/JDK-8075255 >>>> >>>> -phil. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > -- Best regards, Sergey. From erik.joelsson at oracle.com Tue Mar 17 12:06:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 17 Mar 2015 13:06:41 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11 related Java files on OSX In-Reply-To: <550761A4.7040001@oracle.com> References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com> <550753AA.4050804@oracle.com> <550761A4.7040001@oracle.com> Message-ID: <550818D1.4070607@oracle.com> Hello Phil, A minor style issue. We would appreciate if the java.desktop_EXCLUDES followed the same style as java.desktop_EXCLUDE_FILES, with 4 spaces indent and a line break at the start and end, like this: java.desktop_EXCLUDES += \ sun/awt/X11 \ sun/java2d/x11 \ sun/java2d/jules \ sun/java2d/xr \ com/sun/java/swing/plaf/gtk \ # /Erik On 2015-03-17 00:05, Phil Race wrote: > One more update: http://cr.openjdk.java.net/~prr/8075277.2/ > > just adds sun/awt/motif/* to the exclude list. > > I'm deleting that directory in another fix but those without those > changes need it > excluded too > > -phil. > > On 3/16/15 3:05 PM, Phil Race wrote: >> There are some files in sun/print some directories still being used >> but for the files >> explicitly listed, then in each case all .java files in those >> directories are now unused. >> So yes, I can make this cleaner and less fragile too! >> >> http://cr.openjdk.java.net/~prr/8075277.1/ >> >> -phil.* >> * >> On 3/16/15 2:18 PM, Sergey Bylokhov wrote: >>> Hi, Phil >>> Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" >>> using $(wildcard, or we still using some files on osx from the unix >>> folder? >>> >>>> >>>> Although a more complete fix would do something like refactor the >>>> source files, >>>> as that would be less fragile amongst other things, this at least >>>> gets us into a >>>> better shape with minimal disruption - and solves my immediate >>>> problem :-) >>> There is a CR for this: >>> https://bugs.openjdk.java.net/browse/JDK-8075254 >>>> And it is not clear to me why there was an unused reference to >>>> FontConfigManager in the Mac code. Removing it breaks >>>> a link that dragged in X11 related code. >>>> >>>> I expect the files shipped on OS X to go down as a result of >>>> removing these 'dead' ones. >>>> I would also have got rid of the Windows L&F but that needs >>>> a bit of work on the Swing side first : >>>> https://bugs.openjdk.java.net/browse/JDK-8075255 >>>> >>>> -phil. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > From magnus.ihse.bursie at oracle.com Tue Mar 17 12:58:32 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 17 Mar 2015 13:58:32 +0100 Subject: RFR: JDK-8075176 DISABLED_WARNINGS caused C++ compiler flags to get lost Message-ID: <550824F8.4080502@oracle.com> It turned out that the fix for JDK-8074796 (Disabling warnings on clang triggers compiler bug for libunpack) did not address the core issue. In fact, there was no compiler bug in clang. (Surprise! :-)) Instead, what happened was that the makefile changes that turned on the warning flags, also affected other flags sent to the compiler. This happened on all toolchains, but was first noticed only for clang builds. More precisely, due to the convoluted logic in SetupNativeCompilation, the value of "CFLAGS_release := -DPRODUCT" which was set in libunpack should have been copied by default to CXXFLAGS_release, so it could be used when compiling C++ code. However, if there are additional CXX flags set, then this copy does not happen. Due to the exact placement of the DISABLED_WARINGS flags code in SetupNativeCompilation, the CXX flags turned out to be non-empty when the "if CXX flags not set, then copy C flags by default" was executed. Hence, CFLAGS_release was not transferred to CXXFLAGS_release, and -DPRODUCT was lost when compiling the C++ files. One could certainly argue that our entire handling of C flags vs C++ flags is not ideal. Hopefully, we can address that in the future, and create a more robust model. For now, moving the code in SetupNativeCompilation will solve the problems which was introduced with the new warning option. This will also allow us to re-enable the warning statement for clang. Bug: https://bugs.openjdk.java.net/browse/JDK-8075176 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8075176-disabled-warnings-removed-extra-cflags/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Mar 17 13:15:10 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 17 Mar 2015 14:15:10 +0100 Subject: RFR: JDK-8075176 DISABLED_WARNINGS caused C++ compiler flags to get lost In-Reply-To: <550824F8.4080502@oracle.com> References: <550824F8.4080502@oracle.com> Message-ID: <550828DE.7020508@oracle.com> Looks good. Nice to find the root cause of this. /Erik On 2015-03-17 13:58, Magnus Ihse Bursie wrote: > It turned out that the fix for JDK-8074796 (Disabling warnings on > clang triggers compiler bug for libunpack) did not address the core > issue. > > In fact, there was no compiler bug in clang. (Surprise! :-)) Instead, > what happened was that the makefile changes that turned on the warning > flags, also affected other flags sent to the compiler. This happened > on all toolchains, but was first noticed only for clang builds. > > More precisely, due to the convoluted logic in SetupNativeCompilation, > the value of "CFLAGS_release := -DPRODUCT" which was set in libunpack > should have been copied by default to CXXFLAGS_release, so it could be > used when compiling C++ code. However, if there are additional CXX > flags set, then this copy does not happen. Due to the exact placement > of the DISABLED_WARINGS flags code in SetupNativeCompilation, the CXX > flags turned out to be non-empty when the "if CXX flags not set, then > copy C flags by default" was executed. Hence, CFLAGS_release was not > transferred to CXXFLAGS_release, and -DPRODUCT was lost when compiling > the C++ files. > > One could certainly argue that our entire handling of C flags vs C++ > flags is not ideal. Hopefully, we can address that in the future, and > create a more robust model. > > For now, moving the code in SetupNativeCompilation will solve the > problems which was introduced with the new warning option. This will > also allow us to re-enable the warning statement for clang. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075176 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8075176-disabled-warnings-removed-extra-cflags/webrev.01 > > /Magnus From kumar.x.srinivasan at oracle.com Tue Mar 17 14:10:05 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 17 Mar 2015 07:10:05 -0700 Subject: RFR: JDK-8075176 DISABLED_WARNINGS caused C++ compiler flags to get lost In-Reply-To: <550824F8.4080502@oracle.com> References: <550824F8.4080502@oracle.com> Message-ID: <550835BD.5070607@oracle.com> Hi Magnus, *||****make/common/NativeCompilation.gmk* Typo: s/explicitely/explicitly/ I don't quite understand the changes ;) but Mr ErikJ has done the honors. :-) Thanks Kumar On 3/17/2015 5:58 AM, Magnus Ihse Bursie wrote: > It turned out that the fix for JDK-8074796 (Disabling warnings on > clang triggers compiler bug for libunpack) did not address the core > issue. > > In fact, there was no compiler bug in clang. (Surprise! :-)) Instead, > what happened was that the makefile changes that turned on the warning > flags, also affected other flags sent to the compiler. This happened > on all toolchains, but was first noticed only for clang builds. > > More precisely, due to the convoluted logic in SetupNativeCompilation, > the value of "CFLAGS_release := -DPRODUCT" which was set in libunpack > should have been copied by default to CXXFLAGS_release, so it could be > used when compiling C++ code. However, if there are additional CXX > flags set, then this copy does not happen. Due to the exact placement > of the DISABLED_WARINGS flags code in SetupNativeCompilation, the CXX > flags turned out to be non-empty when the "if CXX flags not set, then > copy C flags by default" was executed. Hence, CFLAGS_release was not > transferred to CXXFLAGS_release, and -DPRODUCT was lost when compiling > the C++ files. > > One could certainly argue that our entire handling of C flags vs C++ > flags is not ideal. Hopefully, we can address that in the future, and > create a more robust model. > > For now, moving the code in SetupNativeCompilation will solve the > problems which was introduced with the new warning option. This will > also allow us to re-enable the warning statement for clang. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075176 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8075176-disabled-warnings-removed-extra-cflags/webrev.01 > > /Magnus From erik.joelsson at oracle.com Tue Mar 17 14:12:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 17 Mar 2015 15:12:53 +0100 Subject: RFR: JDK-8072897: File sawindbg.dll has incorrect file version Message-ID: <55083665.5010801@oracle.com> Hello, Please review this minor fix for sawindbg.dll. It is currently not having version info added (the RC stuff) which all other dlls have. Here is a minimal fix that basically adds the same values as for jvm.dll except for the filename (FNAME) field. (Nmake is confusing) Bug: https://bugs.openjdk.java.net/browse/JDK-8072897 Webrev: http://cr.openjdk.java.net/~erikj/8072897/webrev.hotspot.01/ /Erik From tim.bell at oracle.com Tue Mar 17 14:13:57 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 17 Mar 2015 07:13:57 -0700 Subject: RFR: JDK-8075176 DISABLED_WARNINGS caused C++ compiler flags to get lost In-Reply-To: <550828DE.7020508@oracle.com> References: <550824F8.4080502@oracle.com> <550828DE.7020508@oracle.com> Message-ID: <550836A5.1070709@oracle.com> On 03/17/15 06:15, Erik Joelsson wrote: > Looks good. Nice to find the root cause of this. > > /Erik > > On 2015-03-17 13:58, Magnus Ihse Bursie wrote: >> It turned out that the fix for JDK-8074796 (Disabling warnings on >> clang triggers compiler bug for libunpack) did not address the core >> issue. >> >> In fact, there was no compiler bug in clang. (Surprise! :-)) Instead, >> what happened was that the makefile changes that turned on the >> warning flags, also affected other flags sent to the compiler. This >> happened on all toolchains, but was first noticed only for clang builds. >> >> More precisely, due to the convoluted logic in >> SetupNativeCompilation, the value of "CFLAGS_release := -DPRODUCT" >> which was set in libunpack should have been copied by default to >> CXXFLAGS_release, so it could be used when compiling C++ code. >> However, if there are additional CXX flags set, then this copy does >> not happen. Due to the exact placement of the DISABLED_WARINGS flags >> code in SetupNativeCompilation, the CXX flags turned out to be >> non-empty when the "if CXX flags not set, then copy C flags by >> default" was executed. Hence, CFLAGS_release was not transferred to >> CXXFLAGS_release, and -DPRODUCT was lost when compiling the C++ files. >> >> One could certainly argue that our entire handling of C flags vs C++ >> flags is not ideal. Hopefully, we can address that in the future, and >> create a more robust model. >> >> For now, moving the code in SetupNativeCompilation will solve the >> problems which was introduced with the new warning option. This will >> also allow us to re-enable the warning statement for clang. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075176 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8075176-disabled-warnings-removed-extra-cflags/webrev.01 >> >> /Magnus > From tim.bell at oracle.com Tue Mar 17 14:14:45 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 17 Mar 2015 07:14:45 -0700 Subject: RFR: JDK-8075176 DISABLED_WARNINGS caused C++ compiler flags to get lost In-Reply-To: <550828DE.7020508@oracle.com> References: <550824F8.4080502@oracle.com> <550828DE.7020508@oracle.com> Message-ID: <550836D5.3050102@oracle.com> Magnus: Looks good to me as well. Tim On 03/17/15 06:15, Erik Joelsson wrote: > Looks good. Nice to find the root cause of this. > > /Erik > > On 2015-03-17 13:58, Magnus Ihse Bursie wrote: >> It turned out that the fix for JDK-8074796 (Disabling warnings on >> clang triggers compiler bug for libunpack) did not address the core >> issue. >> >> In fact, there was no compiler bug in clang. (Surprise! :-)) Instead, >> what happened was that the makefile changes that turned on the >> warning flags, also affected other flags sent to the compiler. This >> happened on all toolchains, but was first noticed only for clang builds. >> >> More precisely, due to the convoluted logic in >> SetupNativeCompilation, the value of "CFLAGS_release := -DPRODUCT" >> which was set in libunpack should have been copied by default to >> CXXFLAGS_release, so it could be used when compiling C++ code. >> However, if there are additional CXX flags set, then this copy does >> not happen. Due to the exact placement of the DISABLED_WARINGS flags >> code in SetupNativeCompilation, the CXX flags turned out to be >> non-empty when the "if CXX flags not set, then copy C flags by >> default" was executed. Hence, CFLAGS_release was not transferred to >> CXXFLAGS_release, and -DPRODUCT was lost when compiling the C++ files. >> >> One could certainly argue that our entire handling of C flags vs C++ >> flags is not ideal. Hopefully, we can address that in the future, and >> create a more robust model. >> >> For now, moving the code in SetupNativeCompilation will solve the >> problems which was introduced with the new warning option. This will >> also allow us to re-enable the warning statement for clang. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075176 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8075176-disabled-warnings-removed-extra-cflags/webrev.01 >> >> /Magnus > From tim.bell at oracle.com Tue Mar 17 14:36:05 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 17 Mar 2015 07:36:05 -0700 Subject: RFR: JDK-8072897: File sawindbg.dll has incorrect file version In-Reply-To: <55083665.5010801@oracle.com> References: <55083665.5010801@oracle.com> Message-ID: <55083BD5.9050404@oracle.com> Erik: > Please review this minor fix for sawindbg.dll. It is currently not > having version info added (the RC stuff) which all other dlls have. > Here is a minimal fix that basically adds the same values as for > jvm.dll except for the filename (FNAME) field. > > (Nmake is confusing) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072897 > Webrev: http://cr.openjdk.java.net/~erikj/8072897/webrev.hotspot.01/ Looks good to me, although I am not a 'R'eviewer in hotspot territory... Tim From magnus.ihse.bursie at oracle.com Tue Mar 17 15:22:46 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 17 Mar 2015 16:22:46 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11 related Java files on OSX In-Reply-To: <550818D1.4070607@oracle.com> References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com> <550753AA.4050804@oracle.com> <550761A4.7040001@oracle.com> <550818D1.4070607@oracle.com> Message-ID: <550846C6.2060803@oracle.com> On 2015-03-17 13:06, Erik Joelsson wrote: > Hello Phil, > > A minor style issue. We would appreciate if the java.desktop_EXCLUDES > followed the same style as java.desktop_EXCLUDE_FILES, with 4 spaces > indent and a line break at the start and end, like this: > > java.desktop_EXCLUDES += \ > sun/awt/X11 \ > sun/java2d/x11 \ > sun/java2d/jules \ > sun/java2d/xr \ > com/sun/java/swing/plaf/gtk \ > # Agree on the style fix. Apart from that, looks good to me! /Magnus From david.dehaven at oracle.com Tue Mar 17 22:54:40 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 17 Mar 2015 15:54:40 -0700 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) Message-ID: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> Fairly minor build system bug fix on Mac. In short, the -mmacosx-version-min argument is never being passed to the linker, where it's actually needed to assert the minimum OS version requirement in the final Mach-O binary. This was causing ld to fail when building on 10.10. I've no idea why it's different from 10.9 as I'm using the exact same copy of Xcode between 10.9 and 10.10 and it works fine on 10.9. I also had to modify saproc.make to pass that argument when it builds the SA debugger backend. All changes should only affect Mac, but kicking off a full JPRT test run to be sure. Webrev is against jdk8u-dev but will push through hs-dev if/when approved. This bug impacts 8u only, no backports necessary. JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8075400 Webrev: http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ -DrD- From philip.race at oracle.com Tue Mar 17 23:57:43 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 17 Mar 2015 16:57:43 -0700 Subject: Windows configure error : LZMAPATH Message-ID: <5508BF77.2070905@oracle.com> I'll admit its been a few weeks since I've build JDK on Windows except via jprt but now I can't get past configure and I don't know why its resolving a variable that I didn't set instead of looking on my path .. checking Checking for install src... not found, cannot build installer checking for JUnit... no, deploy tests cannot be run checking for wix... no, needed for installer, set --with-wix=/path/to/wix checking for lzma... configure: The path of LZMAPATH, which resolves as "C:/util s/", is invalid. configure: error: Cannot locate the the path of LZMAPATH configure exiting with result code 1 C:\jdks\jdk9-client>set LZMAPATH Environment variable LZMAPATH not defined C:\jdks\jdk9-client>sh sh-4.1$ which lzma /cygdrive/c/tools/jdkutils/bin/lzma -phil. From david.holmes at oracle.com Wed Mar 18 00:35:29 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 10:35:29 +1000 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> Message-ID: <5508C851.20906@oracle.com> Hi David On 18/03/2015 8:54 AM, David DeHaven wrote: > Fairly minor build system bug fix on Mac. In short, the -mmacosx-version-min argument is never being passed to the linker, where it's actually needed to assert the minimum OS version requirement in the final Mach-O binary. This was causing ld to fail when building on 10.10. I've no idea why it's different from 10.9 as I'm using the exact same copy of Xcode between 10.9 and 10.10 and it works fine on 10.9. I also had to modify saproc.make to pass that argument when it builds the SA debugger backend. All changes should only affect Mac, but kicking off a full JPRT test run to be sure. Webrev is against jdk8u-dev but will push through hs-dev if/when approved. This bug impacts 8u only, no backports necessary. > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8075400 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ + # bring in minimum version argument or we'll fail on OSX 10.10 + SA_LFLAGS = $(LFLAGS) LFLAGS or LDFLAGS ?? David H. > -DrD- > From david.holmes at oracle.com Wed Mar 18 02:04:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 12:04:16 +1000 Subject: RFR: JDK-8072897: File sawindbg.dll has incorrect file version In-Reply-To: <55083BD5.9050404@oracle.com> References: <55083665.5010801@oracle.com> <55083BD5.9050404@oracle.com> Message-ID: <5508DD20.9080105@oracle.com> On 18/03/2015 12:36 AM, Tim Bell wrote: > Erik: > >> Please review this minor fix for sawindbg.dll. It is currently not >> having version info added (the RC stuff) which all other dlls have. >> Here is a minimal fix that basically adds the same values as for >> jvm.dll except for the filename (FNAME) field. >> >> (Nmake is confusing) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072897 >> Webrev: http://cr.openjdk.java.net/~erikj/8072897/webrev.hotspot.01/ > > Looks good to me, although I am not a 'R'eviewer in hotspot territory... I am :) Looks okay to me too. Don't forget to submit via jprt with "-testset hotspot" Thanks, David > Tim > From erik.joelsson at oracle.com Wed Mar 18 08:24:59 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Mar 2015 09:24:59 +0100 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <5508C851.20906@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> Message-ID: <5509365B.2060808@oracle.com> On 2015-03-18 01:35, David Holmes wrote: > Hi David > > On 18/03/2015 8:54 AM, David DeHaven wrote: >> Fairly minor build system bug fix on Mac. In short, the >> -mmacosx-version-min argument is never being passed to the linker, >> where it's actually needed to assert the minimum OS version >> requirement in the final Mach-O binary. This was causing ld to fail >> when building on 10.10. I've no idea why it's different from 10.9 as >> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >> works fine on 10.9. I also had to modify saproc.make to pass that >> argument when it builds the SA debugger backend. All changes should >> only affect Mac, but kicking off a full JPRT test run to be sure. >> Webrev is against jdk8u-dev but will push through hs-dev if/when >> approved. This bug impacts 8u only, no backports necessary. >> >> JBS Issue: >> https://bugs.openjdk.java.net/browse/JDK-8075400 >> >> Webrev: >> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ > Looks good to me. > + # bring in minimum version argument or we'll fail on OSX 10.10 > + SA_LFLAGS = $(LFLAGS) > > LFLAGS or LDFLAGS ?? > The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at all, it's called LFLAGS. /Erik From erik.joelsson at oracle.com Wed Mar 18 09:32:47 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 18 Mar 2015 10:32:47 +0100 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <550693CC.7050300@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> <550693CC.7050300@oracle.com> Message-ID: <5509463F.8020401@oracle.com> David, Are you OK with me pushing this or should I interpret your reply as a need for a different solution? /Erik On 2015-03-16 09:26, Erik Joelsson wrote: > > On 2015-03-14 01:08, David Holmes wrote: >> Hi Erik, >> >> On 14/03/2015 12:08 AM, Erik Joelsson wrote: >>> Hello, >>> >>> While working on the new Hotspot makefiles in build-infra I noticed >>> this >>> problem. When introducing devkits for Solaris, we rely on the variables >>> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >>> specific flags into the hotspot build. However, these flags aren't >>> consistently used in the Hotspot build for all the native libraries. >>> >>> This patch adds the variables to all missing compile and link command >>> lines. It also fixes an issue with saproc.so where the debug info was >>> created off one of the object files instead of the library. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >>> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ >> >> For linux we primarily (only?) use these to pass cross-compilation >> flags and so everything that is compiled generally needs the same flags. >> >> Outside of cross-compilation though that doesn't necessarily hold. If >> someone uses EXTRA_CFLAGS as a general customization mechanism it >> might only be intended for the primary VM build not for secondary >> libraries like jsig, dtrace and SA. >> >> So I'm not sure that this is the right thing to do as really these >> variables are not quite what people might expect them to be. In >> general local customizations are better handled by local editing of >> the appropriate build file. >> > Well, the devkit/sysroot CFLAGS and LDFLAGS should be considered more > or less equal to cross compilation arguments. Everything being > compiled for the target platform should use them. If EXTRA_CFLAGS is > not a good option for providing these compiler options, then it > shouldn't be used for cross compilation on linux either. I figured > that since we are already using them that way on linux, extending that > usage to Solaris would be the right thing to do. If it isn't, should I > define a new set of variables for transporting these options for both > platforms instead? > > I still think using EXTRA_*FLAGS is a viable solution for my usecase > and that anyone trying to use these variables and expecting them to > only apply selectively is on a slippery slope. > > /Erik >> David >> >>> /Erik > From david.holmes at oracle.com Wed Mar 18 10:55:05 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 20:55:05 +1000 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <5509365B.2060808@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> <5509365B.2060808@oracle.com> Message-ID: <55095989.5050105@oracle.com> On 18/03/2015 6:24 PM, Erik Joelsson wrote: > > On 2015-03-18 01:35, David Holmes wrote: >> Hi David >> >> On 18/03/2015 8:54 AM, David DeHaven wrote: >>> Fairly minor build system bug fix on Mac. In short, the >>> -mmacosx-version-min argument is never being passed to the linker, >>> where it's actually needed to assert the minimum OS version >>> requirement in the final Mach-O binary. This was causing ld to fail >>> when building on 10.10. I've no idea why it's different from 10.9 as >>> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >>> works fine on 10.9. I also had to modify saproc.make to pass that >>> argument when it builds the SA debugger backend. All changes should >>> only affect Mac, but kicking off a full JPRT test run to be sure. >>> Webrev is against jdk8u-dev but will push through hs-dev if/when >>> approved. This bug impacts 8u only, no backports necessary. >>> >>> JBS Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8075400 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ >> > Looks good to me. >> + # bring in minimum version argument or we'll fail on OSX 10.10 >> + SA_LFLAGS = $(LFLAGS) >> >> LFLAGS or LDFLAGS ?? >> > The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at > all, it's called LFLAGS. Ah! I failed to spot that the change in gcc.make was from LDFLAGS to LFLAGS. Thanks, David H. > /Erik From david.holmes at oracle.com Wed Mar 18 10:58:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 20:58:27 +1000 Subject: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS In-Reply-To: <5509463F.8020401@oracle.com> References: <5502EF4E.2060006@oracle.com> <55037BF5.5010700@oracle.com> <550693CC.7050300@oracle.com> <5509463F.8020401@oracle.com> Message-ID: <55095A53.9030305@oracle.com> On 18/03/2015 7:32 PM, Erik Joelsson wrote: > David, > > Are you OK with me pushing this or should I interpret your reply as a > need for a different solution? It's okay to push. The flag management is quite messy and I don't think there is any simple solution to cover the various kinds of flags that might need to be applied en-masse versus selectively. Anyone messing with these variables is going to need to be very careful to check that it has the desired affect. David > /Erik > > On 2015-03-16 09:26, Erik Joelsson wrote: >> >> On 2015-03-14 01:08, David Holmes wrote: >>> Hi Erik, >>> >>> On 14/03/2015 12:08 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> While working on the new Hotspot makefiles in build-infra I noticed >>>> this >>>> problem. When introducing devkits for Solaris, we rely on the variables >>>> EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS to propagate the SYSROOT >>>> specific flags into the hotspot build. However, these flags aren't >>>> consistently used in the Hotspot build for all the native libraries. >>>> >>>> This patch adds the variables to all missing compile and link command >>>> lines. It also fixes an issue with saproc.so where the debug info was >>>> created off one of the object files instead of the library. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075140 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8075140/webrev.hotspot.01/ >>> >>> For linux we primarily (only?) use these to pass cross-compilation >>> flags and so everything that is compiled generally needs the same flags. >>> >>> Outside of cross-compilation though that doesn't necessarily hold. If >>> someone uses EXTRA_CFLAGS as a general customization mechanism it >>> might only be intended for the primary VM build not for secondary >>> libraries like jsig, dtrace and SA. >>> >>> So I'm not sure that this is the right thing to do as really these >>> variables are not quite what people might expect them to be. In >>> general local customizations are better handled by local editing of >>> the appropriate build file. >>> >> Well, the devkit/sysroot CFLAGS and LDFLAGS should be considered more >> or less equal to cross compilation arguments. Everything being >> compiled for the target platform should use them. If EXTRA_CFLAGS is >> not a good option for providing these compiler options, then it >> shouldn't be used for cross compilation on linux either. I figured >> that since we are already using them that way on linux, extending that >> usage to Solaris would be the right thing to do. If it isn't, should I >> define a new set of variables for transporting these options for both >> platforms instead? >> >> I still think using EXTRA_*FLAGS is a viable solution for my usecase >> and that anyone trying to use these variables and expecting them to >> only apply selectively is on a slippery slope. >> >> /Erik >>> David >>> >>>> /Erik >> > From david.dehaven at oracle.com Wed Mar 18 17:20:46 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 18 Mar 2015 10:20:46 -0700 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <55095989.5050105@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> <5509365B.2060808@oracle.com> <55095989.5050105@oracle.com> Message-ID: <0023AAD5-A65A-4399-865E-04F17DC7F428@oracle.com> >>> Hi David >>> >>> On 18/03/2015 8:54 AM, David DeHaven wrote: >>>> Fairly minor build system bug fix on Mac. In short, the >>>> -mmacosx-version-min argument is never being passed to the linker, >>>> where it's actually needed to assert the minimum OS version >>>> requirement in the final Mach-O binary. This was causing ld to fail >>>> when building on 10.10. I've no idea why it's different from 10.9 as >>>> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >>>> works fine on 10.9. I also had to modify saproc.make to pass that >>>> argument when it builds the SA debugger backend. All changes should >>>> only affect Mac, but kicking off a full JPRT test run to be sure. >>>> Webrev is against jdk8u-dev but will push through hs-dev if/when >>>> approved. This bug impacts 8u only, no backports necessary. >>>> >>>> JBS Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8075400 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ >>> >> Looks good to me. >>> + # bring in minimum version argument or we'll fail on OSX 10.10 >>> + SA_LFLAGS = $(LFLAGS) >>> >>> LFLAGS or LDFLAGS ?? >>> >> The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at >> all, it's called LFLAGS. > > Ah! I failed to spot that the change in gcc.make was from LDFLAGS to LFLAGS. Correct, that's why vm.make wasn't picking up the -mmacosx-version-min argument when linking. JPRT run was clean. Can I take this as approval? -DrD- From david.holmes at oracle.com Wed Mar 18 21:34:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Mar 2015 07:34:12 +1000 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <0023AAD5-A65A-4399-865E-04F17DC7F428@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> <5509365B.2060808@oracle.com> <55095989.5050105@oracle.com> <0023AAD5-A65A-4399-865E-04F17DC7F428@oracle.com> Message-ID: <5509EF54.1020502@oracle.com> On 19/03/2015 3:20 AM, David DeHaven wrote: > >>>> Hi David >>>> >>>> On 18/03/2015 8:54 AM, David DeHaven wrote: >>>>> Fairly minor build system bug fix on Mac. In short, the >>>>> -mmacosx-version-min argument is never being passed to the linker, >>>>> where it's actually needed to assert the minimum OS version >>>>> requirement in the final Mach-O binary. This was causing ld to fail >>>>> when building on 10.10. I've no idea why it's different from 10.9 as >>>>> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >>>>> works fine on 10.9. I also had to modify saproc.make to pass that >>>>> argument when it builds the SA debugger backend. All changes should >>>>> only affect Mac, but kicking off a full JPRT test run to be sure. >>>>> Webrev is against jdk8u-dev but will push through hs-dev if/when >>>>> approved. This bug impacts 8u only, no backports necessary. >>>>> >>>>> JBS Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8075400 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ >>>> >>> Looks good to me. >>>> + # bring in minimum version argument or we'll fail on OSX 10.10 >>>> + SA_LFLAGS = $(LFLAGS) >>>> >>>> LFLAGS or LDFLAGS ?? >>>> >>> The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at >>> all, it's called LFLAGS. >> >> Ah! I failed to spot that the change in gcc.make was from LDFLAGS to LFLAGS. > > Correct, that's why vm.make wasn't picking up the -mmacosx-version-min argument when linking. > > JPRT run was clean. > > Can I take this as approval? Yes. Thanks, David > -DrD- > From david.dehaven at oracle.com Thu Mar 19 01:06:12 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 18 Mar 2015 18:06:12 -0700 Subject: [8u-dev] RFR: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) In-Reply-To: <5509EF54.1020502@oracle.com> References: <12F86AD8-ADDE-4245-A3E1-5B4F4656AAEB@oracle.com> <5508C851.20906@oracle.com> <5509365B.2060808@oracle.com> <55095989.5050105@oracle.com> <0023AAD5-A65A-4399-865E-04F17DC7F428@oracle.com> <5509EF54.1020502@oracle.com> Message-ID: <171DDF0E-CF1D-4310-9982-242D2EEC27EC@oracle.com> >>>>> Hi David >>>>> >>>>> On 18/03/2015 8:54 AM, David DeHaven wrote: >>>>>> Fairly minor build system bug fix on Mac. In short, the >>>>>> -mmacosx-version-min argument is never being passed to the linker, >>>>>> where it's actually needed to assert the minimum OS version >>>>>> requirement in the final Mach-O binary. This was causing ld to fail >>>>>> when building on 10.10. I've no idea why it's different from 10.9 as >>>>>> I'm using the exact same copy of Xcode between 10.9 and 10.10 and it >>>>>> works fine on 10.9. I also had to modify saproc.make to pass that >>>>>> argument when it builds the SA debugger backend. All changes should >>>>>> only affect Mac, but kicking off a full JPRT test run to be sure. >>>>>> Webrev is against jdk8u-dev but will push through hs-dev if/when >>>>>> approved. This bug impacts 8u only, no backports necessary. >>>>>> >>>>>> JBS Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8075400 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ddehaven/8075400/hotspot.0/ >>>>> >>>> Looks good to me. >>>>> + # bring in minimum version argument or we'll fail on OSX 10.10 >>>>> + SA_LFLAGS = $(LFLAGS) >>>>> >>>>> LFLAGS or LDFLAGS ?? >>>>> >>>> The hotspot makefiles in 8u don't seem to use the variable LDFLAGS at >>>> all, it's called LFLAGS. >>> >>> Ah! I failed to spot that the change in gcc.make was from LDFLAGS to LFLAGS. >> >> Correct, that's why vm.make wasn't picking up the -mmacosx-version-min argument when linking. >> >> JPRT run was clean. >> >> Can I take this as approval? > > Yes. Great, thanks! -DrD- From erik.joelsson at oracle.com Thu Mar 19 09:56:32 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Mar 2015 10:56:32 +0100 Subject: RFR: JDK-8075495: Update jtreg bin location in configure Message-ID: <550A9D50.6070509@oracle.com> Jtreg removed the platform specific bin directories. Configure still picks up the jtreg launcher from win32/bin. This needs to be fixed. This patch is for jdk9. The same patch applies to jdk8u-dev and I would like to fix it there too. Bug: https://bugs.openjdk.java.net/browse/JDK-8075495 Patch: diff -r 3d44432e07d3 common/autoconf/toolchain.m4 --- a/common/autoconf/toolchain.m4 +++ b/common/autoconf/toolchain.m4 @@ -763,7 +763,7 @@ BASIC_FIXUP_PATH([JT_HOME]) # jtreg win32 script works for everybody - JTREGEXE="$JT_HOME/win32/bin/jtreg" + JTREGEXE="$JT_HOME/bin/jtreg" if test ! -f "$JTREGEXE"; then AC_MSG_ERROR([JTReg executable does not exist: $JTREGEXE]) /Erik From Alan.Bateman at oracle.com Thu Mar 19 10:06:07 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Mar 2015 10:06:07 +0000 Subject: RFR: JDK-8075495: Update jtreg bin location in configure In-Reply-To: <550A9D50.6070509@oracle.com> References: <550A9D50.6070509@oracle.com> Message-ID: <550A9F8F.5060604@oracle.com> On 19/03/2015 09:56, Erik Joelsson wrote: > Jtreg removed the platform specific bin directories. Configure still > picks up the jtreg launcher from win32/bin. This needs to be fixed. > This patch is for jdk9. The same patch applies to jdk8u-dev and I > would like to fix it there too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075495 > Patch: > diff -r 3d44432e07d3 common/autoconf/toolchain.m4 > --- a/common/autoconf/toolchain.m4 > +++ b/common/autoconf/toolchain.m4 > @@ -763,7 +763,7 @@ > BASIC_FIXUP_PATH([JT_HOME]) > > # jtreg win32 script works for everybody > - JTREGEXE="$JT_HOME/win32/bin/jtreg" > + JTREGEXE="$JT_HOME/bin/jtreg" > Looks okay to me. -Alan From mikael.gerdin at oracle.com Thu Mar 19 13:56:12 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 19 Mar 2015 14:56:12 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build Message-ID: <550AD57C.1030708@oracle.com> Hi, I recently ran into a compiler warning which is enabled by default in Solaris Studio, since HotSpot builds with warnings-as-errors this failed the build only when I got to the Solaris build. To catch this issue earlier for me (and a lot of others who use Linux as their preferred development platform) I suggest that we enable the equivalent warning for GCC. The patch to implement the change is inined below: diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make --- a/make/linux/makefiles/gcc.make +++ b/make/linux/makefiles/gcc.make @@ -207,7 +207,7 @@ WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body endif -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual ifeq ($(USE_CLANG),) # Since GCC 4.3, -Wconversion has changed its meanings to warn these implicit I've verified the change by building on all linux platforms through JPRT. /Mikael From mikael.gerdin at oracle.com Thu Mar 19 13:58:29 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 19 Mar 2015 14:58:29 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: <550AD57C.1030708@oracle.com> References: <550AD57C.1030708@oracle.com> Message-ID: <550AD605.2030706@oracle.com> Oh, and the bug id is 8075511 https://bugs.openjdk.java.net/browse/JDK-8075511 /Mikael On 2015-03-19 14:56, Mikael Gerdin wrote: > Hi, > > I recently ran into a compiler warning which is enabled by default in > Solaris Studio, since HotSpot builds with warnings-as-errors this failed > the build only when I got to the Solaris build. > To catch this issue earlier for me (and a lot of others who use Linux as > their preferred development platform) I suggest that we enable the > equivalent warning for GCC. > > The patch to implement the change is inined below: > > diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make > --- a/make/linux/makefiles/gcc.make > +++ b/make/linux/makefiles/gcc.make > @@ -207,7 +207,7 @@ > WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body > endif > > -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef > -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type > +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef > -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type > -Woverloaded-virtual > > ifeq ($(USE_CLANG),) > # Since GCC 4.3, -Wconversion has changed its meanings to warn these > implicit > > I've verified the change by building on all linux platforms through JPRT. > > /Mikael From magnus.ihse.bursie at oracle.com Thu Mar 19 14:04:54 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 19 Mar 2015 15:04:54 +0100 Subject: RFR: JDK-8075495: Update jtreg bin location in configure In-Reply-To: <550A9D50.6070509@oracle.com> References: <550A9D50.6070509@oracle.com> Message-ID: <550AD786.5040500@oracle.com> The comment above is not needed anymore. How does this work with different versions of JTReg? Do we need to support older versions with the win32 directory still in place? /Magnus On 2015-03-19 10:56, Erik Joelsson wrote: > Jtreg removed the platform specific bin directories. Configure still > picks up the jtreg launcher from win32/bin. This needs to be fixed. > This patch is for jdk9. The same patch applies to jdk8u-dev and I > would like to fix it there too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075495 > Patch: > diff -r 3d44432e07d3 common/autoconf/toolchain.m4 > --- a/common/autoconf/toolchain.m4 > +++ b/common/autoconf/toolchain.m4 > @@ -763,7 +763,7 @@ > BASIC_FIXUP_PATH([JT_HOME]) > > # jtreg win32 script works for everybody > - JTREGEXE="$JT_HOME/win32/bin/jtreg" > + JTREGEXE="$JT_HOME/bin/jtreg" > > if test ! -f "$JTREGEXE"; then > AC_MSG_ERROR([JTReg executable does not exist: $JTREGEXE]) > > /Erik From Alan.Bateman at oracle.com Thu Mar 19 14:12:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Mar 2015 14:12:10 +0000 Subject: RFR: JDK-8075495: Update jtreg bin location in configure In-Reply-To: <550AD786.5040500@oracle.com> References: <550A9D50.6070509@oracle.com> <550AD786.5040500@oracle.com> Message-ID: <550AD93A.4090108@oracle.com> On 19/03/2015 14:04, Magnus Ihse Bursie wrote: > The comment above is not needed anymore. > > How does this work with different versions of JTReg? Do we need to > support older versions with the win32 directory still in place? > Older versions of jtreg can't be used to run some of the tests today. We hope to do a bulk update of the tests soon to add @modules and declare the test dependences so this means even more tests needing the latest jtreg. -Alan. From volker.simonis at gmail.com Thu Mar 19 14:17:22 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 19 Mar 2015 15:17:22 +0100 Subject: RFR(XS): 8075515: AIX: cleanup xlc options and use -bernotok to detect missing symbols at build time Message-ID: Hi, can somebody please review and sponsor this change (because it requires re-generation of generated-configure.sh): http://cr.openjdk.java.net/~simonis/webrevs/2015/8075515/ https://bugs.openjdk.java.net/browse/JDK-8075515 This change adds -bernotok (which is xlc's equivalent for gcc's '-z defs') to the jdk build to detect missing symbols already at compile time (for the hotspot build this was already done by change "8067923 AIX: link libjvm.so with -bernotok to detect missing symbols at build time..."). It also removes '-q64' from the CC, CXX and LD flags in flags.m4 because '-q64' is already set by PLATFORM_SET_COMPILER_TARGET_BITS_FLAGS in platform.m4. Thank you and best regards, Volker From erik.joelsson at oracle.com Thu Mar 19 14:18:16 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Mar 2015 15:18:16 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: <550AD605.2030706@oracle.com> References: <550AD57C.1030708@oracle.com> <550AD605.2030706@oracle.com> Message-ID: <550ADAA8.3090900@oracle.com> Looks good to me. /Erik On 2015-03-19 14:58, Mikael Gerdin wrote: > Oh, and the bug id is 8075511 > https://bugs.openjdk.java.net/browse/JDK-8075511 > > /Mikael > > On 2015-03-19 14:56, Mikael Gerdin wrote: >> Hi, >> >> I recently ran into a compiler warning which is enabled by default in >> Solaris Studio, since HotSpot builds with warnings-as-errors this failed >> the build only when I got to the Solaris build. >> To catch this issue earlier for me (and a lot of others who use Linux as >> their preferred development platform) I suggest that we enable the >> equivalent warning for GCC. >> >> The patch to implement the change is inined below: >> >> diff --git a/make/linux/makefiles/gcc.make >> b/make/linux/makefiles/gcc.make >> --- a/make/linux/makefiles/gcc.make >> +++ b/make/linux/makefiles/gcc.make >> @@ -207,7 +207,7 @@ >> WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body >> endif >> >> -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef >> -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type >> +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef >> -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type >> -Woverloaded-virtual >> >> ifeq ($(USE_CLANG),) >> # Since GCC 4.3, -Wconversion has changed its meanings to warn these >> implicit >> >> I've verified the change by building on all linux platforms through >> JPRT. >> >> /Mikael From erik.joelsson at oracle.com Thu Mar 19 14:20:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Mar 2015 15:20:57 +0100 Subject: RFR(XS): 8075515: AIX: cleanup xlc options and use -bernotok to detect missing symbols at build time In-Reply-To: References: Message-ID: <550ADB49.6020509@oracle.com> Looks good to me. I can push it. /Erik On 2015-03-19 15:17, Volker Simonis wrote: > Hi, > > can somebody please review and sponsor this change (because it > requires re-generation of generated-configure.sh): > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8075515/ > https://bugs.openjdk.java.net/browse/JDK-8075515 > > This change adds -bernotok (which is xlc's equivalent for gcc's '-z > defs') to the jdk build to detect missing symbols already at compile > time (for the hotspot build this was already done by change "8067923 > AIX: link libjvm.so with -bernotok to detect missing symbols at build > time..."). > > It also removes '-q64' from the CC, CXX and LD flags in flags.m4 > because '-q64' is already set by > PLATFORM_SET_COMPILER_TARGET_BITS_FLAGS in platform.m4. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Thu Mar 19 14:26:20 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 19 Mar 2015 15:26:20 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: <550AD57C.1030708@oracle.com> References: <550AD57C.1030708@oracle.com> Message-ID: Hi Mikael, the change looks good (and I think it is really reasonable to have this warning). I've also checked that our ancient gcc 4.1.2 already supports this option:) Regards, Volker On Thu, Mar 19, 2015 at 2:56 PM, Mikael Gerdin wrote: > Hi, > > I recently ran into a compiler warning which is enabled by default in > Solaris Studio, since HotSpot builds with warnings-as-errors this failed the > build only when I got to the Solaris build. > To catch this issue earlier for me (and a lot of others who use Linux as > their preferred development platform) I suggest that we enable the > equivalent warning for GCC. > > The patch to implement the change is inined below: > > diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make > --- a/make/linux/makefiles/gcc.make > +++ b/make/linux/makefiles/gcc.make > @@ -207,7 +207,7 @@ > WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body > endif > > -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -Wformat=2 -Wreturn-type > +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual > > ifeq ($(USE_CLANG),) > # Since GCC 4.3, -Wconversion has changed its meanings to warn these > implicit > > I've verified the change by building on all linux platforms through JPRT. > > /Mikael From peter.brunet at oracle.com Sat Mar 21 04:33:00 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 20 Mar 2015 23:33:00 -0500 Subject: RfR JDK-8055831 Open Source Java Access Bridge Message-ID: <550CF47C.4050306@oracle.com> Please review the following patch which will add the code of the Java Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. This code is used by Assistive Technology such as screen readers and screen magnifiers used by those who are blind or have low vision. AT use the JAB native API and the JAB in turn uses the Java Accessibility API (JAAPI). For more information on JAAPI see the javax.accessibility package. This is a Windows accessibility solution. http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.00/ Pete From erik.joelsson at oracle.com Mon Mar 23 10:06:49 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Mar 2015 11:06:49 +0100 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <550CF47C.4050306@oracle.com> References: <550CF47C.4050306@oracle.com> Message-ID: <550FE5B9.3040706@oracle.com> Hello Pete, In general this looks good. However, to better fit with our intended source code file layout, I would prefer if the source was organized by the names of the libraries being built, and this would be a good time to get it done properly. Something like this: jdk.accessibility/windows/native/libjavaaccessbridge/ AccessBridgeATInstance.cpp AccessBridgeJavaEntryPoints.cpp JavaAccessBridge.cpp jdk.accessibility/windows/native/libwindowsaccessbridge/ AccessBridgeJavaVMInstance.cpp AccessBridgeMessageQueue.cpp AccessBridgeWindowsEntryPoints.cpp WinAccessBridge.cpp AccessBridgeEventHandler.cpp jdk.accessibility/windows/native/common AccessBridgeDebug.cpp AccessBridgeMessages.cpp jdk.accessibility/windows/native/libjabsysinfo/ AccessBridgeSysInfo.cpp The header files needed for more than one lib would also go in common, otherwise in the specific lib dir. The SetupNativeCompilation calls would then not need to list explicit files but would only need to list the necessary directories. There are a number of extra .cpp files in the libaccessbridge dir that aren't used in any of the libraries. What is the purpose of those? Keeping source code around that is not being built seems strange to me. There are also extra .rc files and a bunch of .DEF files. Are the .DEF files used for anything? If all these files really need to be included in our source base, perhaps sort them out into a jdk.accessibility/windows/native/misc dir or something so that it's clear what is needed to build the product and what is not? /Erik On 2015-03-21 05:33, Pete Brunet wrote: > Please review the following patch which will add the code of the Java > Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. > > This code is used by Assistive Technology such as screen readers and > screen magnifiers used by those who are blind or have low vision. AT > use the JAB native API and the JAB in turn uses the Java Accessibility > API (JAAPI). For more information on JAAPI see the javax.accessibility > package. This is a Windows accessibility solution. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.00/ > > Pete From magnus.ihse.bursie at oracle.com Mon Mar 23 13:11:52 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 23 Mar 2015 14:11:52 +0100 Subject: RFR: JDK-8075717 Replace INTERNAL_BUILD with DEBUG in awt Message-ID: <55101118.7020909@oracle.com> The current define INTERNAL_BUILD has a value that is dependent on the milestone part of the version string. This is not ideal, and should be replaced with a simple dependency on DEBUG. Bug: https://bugs.openjdk.java.net/browse/JDK-8075717 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8075717-remove-INTERNAL_BUILD/webrev.01 /Magnus From Sergey.Bylokhov at oracle.com Mon Mar 23 13:31:23 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Mar 2015 16:31:23 +0300 Subject: RFR: JDK-8075717 Replace INTERNAL_BUILD with DEBUG in awt In-Reply-To: <55101118.7020909@oracle.com> References: <55101118.7020909@oracle.com> Message-ID: <551015AB.5070207@oracle.com> The fix looks fine. 23.03.15 16:11, Magnus Ihse Bursie wrote: > The current define INTERNAL_BUILD has a value that is dependent on the > milestone part of the version string. This is not ideal, and should be > replaced with a simple dependency on DEBUG. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075717 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8075717-remove-INTERNAL_BUILD/webrev.01 > > /Magnus -- Best regards, Sergey. From erik.joelsson at oracle.com Mon Mar 23 13:36:49 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Mar 2015 14:36:49 +0100 Subject: RFR: JDK-8075725: Remove /jre subdir in hotspot dist dir Message-ID: <551016F1.1070809@oracle.com> Hello, In JDK 9, the /jre sub directory in the jdk image has been removed. We should also remove this in the hotspot dist output directory and the corresponding import logic in the jdk build. There are still references to /jre in hotspot.script and build.sh, but since I don't know how or if these files are used, I don't dare changing them. Bug: https://bugs.openjdk.java.net/browse/JDK-8075725 Webrev: http://cr.openjdk.java.net/~erikj/8075725/webrev.01/ /Erik From tim.bell at oracle.com Mon Mar 23 15:49:05 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 23 Mar 2015 08:49:05 -0700 Subject: RFR: JDK-8075725: Remove /jre subdir in hotspot dist dir In-Reply-To: <551016F1.1070809@oracle.com> References: <551016F1.1070809@oracle.com> Message-ID: <551035F1.4040800@oracle.com> Erik: > In JDK 9, the /jre sub directory in the jdk image has been removed. We > should also remove this in the hotspot dist output directory and the > corresponding import logic in the jdk build. > > There are still references to /jre in hotspot.script and build.sh, but > since I don't know how or if these files are used, I don't dare > changing them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075725 > Webrev: http://cr.openjdk.java.net/~erikj/8075725/webrev.01/ Looks good to me, although I am not a 'R'eviewer in hotspot territory... Tim From peter.brunet at oracle.com Mon Mar 23 17:31:08 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 23 Mar 2015 12:31:08 -0500 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <550FE5B9.3040706@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> Message-ID: <55104DDC.903@oracle.com> Hi Erik, I tried the restructuring about 2 weeks ago and the build failed trying to find an h file in the common directory. I used two directories on the SRC := setting for SetupNativeCompilation but the build failed not finding an h file located in the second (common) directory. On 3/23/15 5:06 AM, Erik Joelsson wrote: > Hello Pete, > > In general this looks good. However, to better fit with our intended > source code file layout, I would prefer if the source was organized by > the names of the libraries being built, and this would be a good time > to get it done properly. Something like this: > > jdk.accessibility/windows/native/libjavaaccessbridge/ > AccessBridgeATInstance.cpp > AccessBridgeJavaEntryPoints.cpp > JavaAccessBridge.cpp > > jdk.accessibility/windows/native/libwindowsaccessbridge/ > AccessBridgeJavaVMInstance.cpp > AccessBridgeMessageQueue.cpp > AccessBridgeWindowsEntryPoints.cpp > WinAccessBridge.cpp > AccessBridgeEventHandler.cpp > > jdk.accessibility/windows/native/common > AccessBridgeDebug.cpp > AccessBridgeMessages.cpp > > jdk.accessibility/windows/native/libjabsysinfo/ > AccessBridgeSysInfo.cpp > > The header files needed for more than one lib would also go in common, > otherwise in the specific lib dir. The SetupNativeCompilation calls > would then not need to list explicit files but would only need to list > the necessary directories. Maybe that will fix the issue I encountered. I'll try that. > > There are a number of extra .cpp files in the libaccessbridge dir that > aren't used in any of the libraries. What is the purpose of those? > Keeping source code around that is not being built seems strange to > me. There are also extra .rc files and a bunch of .DEF files. Are the > .DEF files used for anything? If all these files really need to be > included in our source base, perhaps sort them out into a > jdk.accessibility/windows/native/misc dir or something so that it's > clear what is needed to build the product and what is not? The Ferret and Monkey tools need to be built and added to the JDK image. This is JDK-8056925. That covers 2 CPP and the 3 RC files plus AccessInfo.cpp. Do you want me to remove those now and add them back in later? JavaAccessBridge.DEF is pretty empty. I'll see if the build will work without it. WinAccessBridge.DEF seems like it might be needed. What do you think? Pete > > /Erik > > On 2015-03-21 05:33, Pete Brunet wrote: >> Please review the following patch which will add the code of the Java >> Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. >> >> This code is used by Assistive Technology such as screen readers and >> screen magnifiers used by those who are blind or have low vision. AT >> use the JAB native API and the JAB in turn uses the Java Accessibility >> API (JAAPI). For more information on JAAPI see the javax.accessibility >> package. This is a Windows accessibility solution. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.00/ >> >> Pete > From aaron.styx at baesystems.com Mon Mar 23 18:47:45 2015 From: aaron.styx at baesystems.com (Styx, Aaron (US SSA)) Date: Mon, 23 Mar 2015 18:47:45 +0000 Subject: IcedTea Build Failures using self as book JDK Message-ID: I'm working on porting Java 7 (using IcedTea 2.5.4) to a new OS. I've completed the build once, but when I install what was built to use as the bootstrap JDK and start a fresh build , it fails with a seg fault when it gets into openjdk/jdk/make/com/sun/jmx running openjdk.build/bin/java. Log file points to problematic frame of ~BufferBlob::flush_icache_stub So my question is: should you be able to build IcedTea 2.5.4 using IcedTea 2.5.4 as the bootstrap JDK? I'm just trying to figure out if it's a problem I introduced in the port (or our OS), or if I'm trying to do something with it that it was never meant to do. Just for reference, the first build of IcedTea seems to work and run just fine. All the demos and test programs work great. The only thing I haven't been able to with it is build itself. Thanks, Aaron From martinrb at google.com Mon Mar 23 18:54:09 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 Mar 2015 11:54:09 -0700 Subject: IcedTea Build Failures using self as book JDK In-Reply-To: <20150323184824.B19CDE3B4A@aojmv0009> References: <20150323184824.B19CDE3B4A@aojmv0009> Message-ID: [+distro-pkg-dev] On Mon, Mar 23, 2015 at 11:47 AM, Styx, Aaron (US SSA) < aaron.styx at baesystems.com> wrote: > I'm working on porting Java 7 (using IcedTea 2.5.4) to a new OS. I've > completed the build once, but when I install what was built to use as the > bootstrap JDK and start a fresh build , it fails with a seg fault when it > gets into openjdk/jdk/make/com/sun/jmx running openjdk.build/bin/java. Log > file points to problematic frame of ~BufferBlob::flush_icache_stub > > So my question is: should you be able to build IcedTea 2.5.4 using IcedTea > 2.5.4 as the bootstrap JDK? I'm just trying to figure out if it's a problem > I introduced in the port (or our OS), or if I'm trying to do something with > it that it was never meant to do. > > Just for reference, the first build of IcedTea seems to work and run just > fine. All the demos and test programs work great. The only thing I haven't > been able to with it is build itself. > > Thanks, > Aaron > > From aph at redhat.com Mon Mar 23 19:35:14 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 Mar 2015 19:35:14 +0000 Subject: IcedTea Build Failures using self as book JDK In-Reply-To: <20150323184824.B19CDE3B4A@aojmv0009> References: <20150323184824.B19CDE3B4A@aojmv0009> Message-ID: <55106AF2.5050801@redhat.com> On 03/23/2015 06:47 PM, Styx, Aaron (US SSA) wrote: > I'm working on porting Java 7 (using IcedTea 2.5.4) to a new > OS. I've completed the build once, but when I install what was built > to use as the bootstrap JDK and start a fresh build , it fails with > a seg fault when it gets into openjdk/jdk/make/com/sun/jmx running > openjdk.build/bin/java. Log file points to problematic frame of > ~BufferBlob::flush_icache_stub > > So my question is: should you be able to build IcedTea 2.5.4 using > IcedTea 2.5.4 as the bootstrap JDK? I'm just trying to figure out if > it's a problem I introduced in the port (or our OS), or if I'm > trying to do something with it that it was never meant to do. > > Just for reference, the first build of IcedTea seems to work and run > just fine. All the demos and test programs work great. The only > thing I haven't been able to with it is build itself. I'd look at the C++ compiler. It seems that HotSpot has been miscompiled, or that there is a latent bug. Andrew. From mikael.gerdin at oracle.com Tue Mar 24 11:09:14 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 24 Mar 2015 12:09:14 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: References: <550AD57C.1030708@oracle.com> Message-ID: <551145DA.4050208@oracle.com> Hi Volker, On 2015-03-19 15:26, Volker Simonis wrote: > Hi Mikael, > > the change looks good (and I think it is really reasonable to have > this warning). > I've also checked that our ancient gcc 4.1.2 already supports this option:) Thanks! Any more takers from HotSpot land? /Mikael > > Regards, > Volker > > > On Thu, Mar 19, 2015 at 2:56 PM, Mikael Gerdin wrote: >> Hi, >> >> I recently ran into a compiler warning which is enabled by default in >> Solaris Studio, since HotSpot builds with warnings-as-errors this failed the >> build only when I got to the Solaris build. >> To catch this issue earlier for me (and a lot of others who use Linux as >> their preferred development platform) I suggest that we enable the >> equivalent warning for GCC. >> >> The patch to implement the change is inined below: >> >> diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make >> --- a/make/linux/makefiles/gcc.make >> +++ b/make/linux/makefiles/gcc.make >> @@ -207,7 +207,7 @@ >> WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body >> endif >> >> -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function >> -Wunused-value -Wformat=2 -Wreturn-type >> +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function >> -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual >> >> ifeq ($(USE_CLANG),) >> # Since GCC 4.3, -Wconversion has changed its meanings to warn these >> implicit >> >> I've verified the change by building on all linux platforms through JPRT. >> >> /Mikael From erik.helin at oracle.com Tue Mar 24 12:48:31 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 24 Mar 2015 13:48:31 +0100 Subject: RFR (XS) Enable -Woverloaded-virtual for GCC in the HotSpot build In-Reply-To: <551145DA.4050208@oracle.com> References: <550AD57C.1030708@oracle.com> <551145DA.4050208@oracle.com> Message-ID: <20150324124831.GM20878@ehelin.jrpg.bea.com> On 2015-03-24, Mikael Gerdin wrote: > Hi Volker, > > On 2015-03-19 15:26, Volker Simonis wrote: > >Hi Mikael, > > > >the change looks good (and I think it is really reasonable to have > >this warning). > >I've also checked that our ancient gcc 4.1.2 already supports this option:) > > Thanks! > > Any more takers from HotSpot land? Looks good, Reviewed. Thanks, Erik > /Mikael > > > > >Regards, > >Volker > > > > > >On Thu, Mar 19, 2015 at 2:56 PM, Mikael Gerdin wrote: > >>Hi, > >> > >>I recently ran into a compiler warning which is enabled by default in > >>Solaris Studio, since HotSpot builds with warnings-as-errors this failed the > >>build only when I got to the Solaris build. > >>To catch this issue earlier for me (and a lot of others who use Linux as > >>their preferred development platform) I suggest that we enable the > >>equivalent warning for GCC. > >> > >>The patch to implement the change is inined below: > >> > >>diff --git a/make/linux/makefiles/gcc.make b/make/linux/makefiles/gcc.make > >>--- a/make/linux/makefiles/gcc.make > >>+++ b/make/linux/makefiles/gcc.make > >>@@ -207,7 +207,7 @@ > >> WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body > >> endif > >> > >>-WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > >>-Wunused-value -Wformat=2 -Wreturn-type > >>+WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > >>-Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual > >> > >> ifeq ($(USE_CLANG),) > >> # Since GCC 4.3, -Wconversion has changed its meanings to warn these > >>implicit > >> > >>I've verified the change by building on all linux platforms through JPRT. > >> > >>/Mikael From magnus.ihse.bursie at oracle.com Tue Mar 24 13:08:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Mar 2015 14:08:01 +0100 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <55104DDC.903@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> Message-ID: <551161B1.6060907@oracle.com> On 2015-03-23 18:31, Pete Brunet wrote: > Hi Erik, > > I tried the restructuring about 2 weeks ago and the build failed trying > to find an h file in the common directory. I used two directories on > the SRC := setting for SetupNativeCompilation but the build failed not > finding an h file located in the second (common) directory. For .h files, you need to also set the -I flag correctly. This is not done automatically from SRC. (Maybe it should.) We have a pattern that you can copy to get this behavior. E.g. LIBINSTRUMENT_SRC := $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument \ # LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ -Isomewhere-else \ # > >> There are a number of extra .cpp files in the libaccessbridge dir that >> aren't used in any of the libraries. What is the purpose of those? >> Keeping source code around that is not being built seems strange to >> me. There are also extra .rc files and a bunch of .DEF files. Are the >> .DEF files used for anything? If all these files really need to be >> included in our source base, perhaps sort them out into a >> jdk.accessibility/windows/native/misc dir or something so that it's >> clear what is needed to build the product and what is not? > The Ferret and Monkey tools need to be built and added to the JDK > image. This is JDK-8056925. That covers 2 CPP and the 3 RC files plus > AccessInfo.cpp. Do you want me to remove those now and add them back in > later? I would prefer that. It is generally better to make each change coherent, unless there is much work in making some changes that will very shortly be undone. This is not the case here. This change should only add the files that are needed for these dll:s to compile. > > JavaAccessBridge.DEF is pretty empty. I'll see if the build will work > without it. > > WinAccessBridge.DEF seems like it might be needed. What do you think? Is it accessed by the compiler? Unless it is given as input to the compiler or linker command line, it is not used in the build. Unless the microsoft compiler does some magic trick and picks up files unasked based on filename, that is. (Unlikely but not impossible, but I'd like to see that proved.) /Magnus From magnus.ihse.bursie at oracle.com Tue Mar 24 13:14:54 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Mar 2015 14:14:54 +0100 Subject: RFR: JDK-8075725: Remove /jre subdir in hotspot dist dir In-Reply-To: <551016F1.1070809@oracle.com> References: <551016F1.1070809@oracle.com> Message-ID: <5511634E.9070703@oracle.com> On 2015-03-23 14:36, Erik Joelsson wrote: > Hello, > > In JDK 9, the /jre sub directory in the jdk image has been removed. We > should also remove this in the hotspot dist output directory and the > corresponding import logic in the jdk build. > > There are still references to /jre in hotspot.script and build.sh, but > since I don't know how or if these files are used, I don't dare > changing them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075725 > Webrev: http://cr.openjdk.java.net/~erikj/8075725/webrev.01/ As far as I can tell, it looks good. Was the reason you renamed EXPORT_JRE_BIN_DIR et al to EXPORT_BIN_DIR to get them to better match the new layout? That also triggered a lot of code changes that would not have been needed otherwise. As I interpret the fix, you only changed the actual path in a few places, and the rest of the changes was just variable renames. If anything, I'd be slightly inclined to think that the variable names, while somewhat misleading, could have stayed, to minimize the impact of the change. /Magnus From erik.joelsson at oracle.com Tue Mar 24 14:55:16 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Mar 2015 15:55:16 +0100 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <551161B1.6060907@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> Message-ID: <55117AD4.9050305@oracle.com> On 2015-03-24 14:08, Magnus Ihse Bursie wrote: > >> >> JavaAccessBridge.DEF is pretty empty. I'll see if the build will work >> without it. >> >> WinAccessBridge.DEF seems like it might be needed. What do you think? > > Is it accessed by the compiler? Unless it is given as input to the > compiler or linker command line, it is not used in the build. Unless > the microsoft compiler does some magic trick and picks up files > unasked based on filename, that is. (Unlikely but not impossible, but > I'd like to see that proved.) > The .DEF file is not used unless the linker is called with '-def file.def'. AFAIK, we never did that in the jdk build. More info can be found here: https://msdn.microsoft.com/en-us/library/28d6s79h.aspx /Erik From erik.joelsson at oracle.com Tue Mar 24 14:56:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Mar 2015 15:56:57 +0100 Subject: RFR: JDK-8075725: Remove /jre subdir in hotspot dist dir In-Reply-To: <5511634E.9070703@oracle.com> References: <551016F1.1070809@oracle.com> <5511634E.9070703@oracle.com> Message-ID: <55117B39.6010302@oracle.com> On 2015-03-24 14:14, Magnus Ihse Bursie wrote: > On 2015-03-23 14:36, Erik Joelsson wrote: >> Hello, >> >> In JDK 9, the /jre sub directory in the jdk image has been removed. >> We should also remove this in the hotspot dist output directory and >> the corresponding import logic in the jdk build. >> >> There are still references to /jre in hotspot.script and build.sh, >> but since I don't know how or if these files are used, I don't dare >> changing them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075725 >> Webrev: http://cr.openjdk.java.net/~erikj/8075725/webrev.01/ > > As far as I can tell, it looks good. > > Was the reason you renamed EXPORT_JRE_BIN_DIR et al to EXPORT_BIN_DIR > to get them to better match the new layout? That also triggered a lot > of code changes that would not have been needed otherwise. As I > interpret the fix, you only changed the actual path in a few places, > and the rest of the changes was just variable renames. If anything, > I'd be slightly inclined to think that the variable names, while > somewhat misleading, could have stayed, to minimize the impact of the > change. > The variable names could have stayed yes, but I figured them conceptually wrong in the new world without /jre and for that reason confusing for future readers of these files. /Erik From erik.joelsson at oracle.com Tue Mar 24 16:36:54 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Mar 2015 17:36:54 +0100 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <55117AD4.9050305@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <55117AD4.9050305@oracle.com> Message-ID: <551192A6.30900@oracle.com> Actually, I just noticed that we are indeed setting -def: to the linker. Please leave the .def files in the patch. /Erik On 2015-03-24 15:55, Erik Joelsson wrote: > > On 2015-03-24 14:08, Magnus Ihse Bursie wrote: >> >>> >>> JavaAccessBridge.DEF is pretty empty. I'll see if the build will work >>> without it. >>> >>> WinAccessBridge.DEF seems like it might be needed. What do you think? >> >> Is it accessed by the compiler? Unless it is given as input to the >> compiler or linker command line, it is not used in the build. Unless >> the microsoft compiler does some magic trick and picks up files >> unasked based on filename, that is. (Unlikely but not impossible, but >> I'd like to see that proved.) >> > The .DEF file is not used unless the linker is called with '-def > file.def'. AFAIK, we never did that in the jdk build. More info can be > found here: > https://msdn.microsoft.com/en-us/library/28d6s79h.aspx > > /Erik > From Sergey.Bylokhov at oracle.com Tue Mar 24 18:18:37 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Mar 2015 21:18:37 +0300 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <550CF47C.4050306@oracle.com> References: <550CF47C.4050306@oracle.com> Message-ID: <5511AA7D.2080702@oracle.com> Hi,Pete. Do I understand correctly that the code itself were not changed except files location? 21.03.15 7:33, Pete Brunet wrote: > Please review the following patch which will add the code of the Java > Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. > > This code is used by Assistive Technology such as screen readers and > screen magnifiers used by those who are blind or have low vision. AT > use the JAB native API and the JAB in turn uses the Java Accessibility > API (JAAPI). For more information on JAAPI see the javax.accessibility > package. This is a Windows accessibility solution. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.00/ > > Pete -- Best regards, Sergey. From peter.brunet at oracle.com Tue Mar 24 20:23:12 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 24 Mar 2015 15:23:12 -0500 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5511AA7D.2080702@oracle.com> References: <550CF47C.4050306@oracle.com> <5511AA7D.2080702@oracle.com> Message-ID: <5511C7B0.9010607@oracle.com> Hi Sergey, That's pretty much the case. I just went through the code and found these differences: - merged in JDK-8055173 (merge jawt.dll into javaaccessbridge.dll) which was recently pushed. - removed some dead code - cleaned up up comments/documentation - cleaned up some code indentation issues - in package-private EventQueueMonitor.addTopLevelWindow the return value was not used so I changed the return from boolean to void If anyone knows if that last one is a compatibility issue I will change it back. Pete On 3/24/15 1:18 PM, Sergey Bylokhov wrote: > Hi,Pete. > Do I understand correctly that the code itself were not changed except > files location? > > 21.03.15 7:33, Pete Brunet wrote: >> Please review the following patch which will add the code of the Java >> Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. >> >> This code is used by Assistive Technology such as screen readers and >> screen magnifiers used by those who are blind or have low vision. AT >> use the JAB native API and the JAB in turn uses the Java Accessibility >> API (JAAPI). For more information on JAAPI see the javax.accessibility >> package. This is a Windows accessibility solution. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.00/ >> >> Pete > > From peter.brunet at oracle.com Tue Mar 24 21:36:54 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 24 Mar 2015 16:36:54 -0500 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <551161B1.6060907@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> Message-ID: <5511D8F6.5090808@oracle.com> Here's the latest patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ The changes are: - restructured the native libraries from one directory to several directories on a per DLL/EXE basis - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk - removed the source for the Ferret and Monkey test tools which will be the subject of a later patch - removed the DEF files; although they were used in the build, there are no build or runtime problems after their removal On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: > On 2015-03-23 18:31, Pete Brunet wrote: >> Hi Erik, >> >> I tried the restructuring about 2 weeks ago and the build failed trying >> to find an h file in the common directory. I used two directories on >> the SRC := setting for SetupNativeCompilation but the build failed not >> finding an h file located in the second (common) directory. > > For .h files, you need to also set the -I flag correctly. This is not > done automatically from SRC. (Maybe it should.) > > We have a pattern that you can copy to get this behavior. E.g. > > LIBINSTRUMENT_SRC := > $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ > $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument > \ > # > LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ > $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ > -Isomewhere-else \ > # > >> >>> There are a number of extra .cpp files in the libaccessbridge dir that >>> aren't used in any of the libraries. What is the purpose of those? >>> Keeping source code around that is not being built seems strange to >>> me. There are also extra .rc files and a bunch of .DEF files. Are the >>> .DEF files used for anything? If all these files really need to be >>> included in our source base, perhaps sort them out into a >>> jdk.accessibility/windows/native/misc dir or something so that it's >>> clear what is needed to build the product and what is not? >> The Ferret and Monkey tools need to be built and added to the JDK >> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files plus >> AccessInfo.cpp. Do you want me to remove those now and add them back in >> later? > I would prefer that. It is generally better to make each change > coherent, unless there is much work in making some changes that will > very shortly be undone. This is not the case here. This change should > only add the files that are needed for these dll:s to compile. > >> >> JavaAccessBridge.DEF is pretty empty. I'll see if the build will work >> without it. >> >> WinAccessBridge.DEF seems like it might be needed. What do you think? > > Is it accessed by the compiler? Unless it is given as input to the > compiler or linker command line, it is not used in the build. Unless > the microsoft compiler does some magic trick and picks up files > unasked based on filename, that is. (Unlikely but not impossible, but > I'd like to see that proved.) > > /Magnus From alexander.zvegintsev at oracle.com Mon Mar 23 14:47:35 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 23 Mar 2015 17:47:35 +0300 Subject: RFR: JDK-8075717 Replace INTERNAL_BUILD with DEBUG in awt In-Reply-To: <551015AB.5070207@oracle.com> References: <55101118.7020909@oracle.com> <551015AB.5070207@oracle.com> Message-ID: <55102787.7090007@oracle.com> Looks fine to me too. Thanks, Alexander. On 03/23/2015 04:31 PM, Sergey Bylokhov wrote: > The fix looks fine. > > 23.03.15 16:11, Magnus Ihse Bursie wrote: >> The current define INTERNAL_BUILD has a value that is dependent on >> the milestone part of the version string. This is not ideal, and >> should be replaced with a simple dependency on DEBUG. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075717 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8075717-remove-INTERNAL_BUILD/webrev.01 >> >> /Magnus > > From gnu.andrew at redhat.com Wed Mar 25 01:39:10 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 24 Mar 2015 21:39:10 -0400 (EDT) Subject: IcedTea Build Failures using self as book JDK In-Reply-To: References: <20150323184824.B19CDE3B4A@aojmv0009> Message-ID: <1737274334.3184298.1427247550120.JavaMail.zimbra@redhat.com> ----- Original Message ----- > [+distro-pkg-dev] > > On Mon, Mar 23, 2015 at 11:47 AM, Styx, Aaron (US SSA) < > aaron.styx at baesystems.com> wrote: > > > I'm working on porting Java 7 (using IcedTea 2.5.4) to a new OS. I've > > completed the build once, but when I install what was built to use as the > > bootstrap JDK and start a fresh build , it fails with a seg fault when it > > gets into openjdk/jdk/make/com/sun/jmx running openjdk.build/bin/java. Log > > file points to problematic frame of ~BufferBlob::flush_icache_stub > > > > So my question is: should you be able to build IcedTea 2.5.4 using IcedTea > > 2.5.4 as the bootstrap JDK? I'm just trying to figure out if it's a problem > > I introduced in the port (or our OS), or if I'm trying to do something with > > it that it was never meant to do. Yes, in fact, it's part of the build unless you explicitly turn it off. > > > > Just for reference, the first build of IcedTea seems to work and run just > > fine. All the demos and test programs work great. The only thing I haven't > > been able to with it is build itself. In my experience, building the JDK with itself is one of the best tests there is. We've had builds that pass the TCK before, but aren't able to build themselves. > > > > Thanks, > > Aaron > > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Wed Mar 25 03:43:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Mar 2015 13:43:46 +1000 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo Message-ID: <55122EF2.5010205@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ Simple fix, contributed by Dean Long, that allows the jvm.cfg file to be located in the "closed" location. The arm and ppc jvm.cfg files can then be moved to that "closed" location. Thanks, David From tim.bell at oracle.com Wed Mar 25 04:13:34 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 24 Mar 2015 21:13:34 -0700 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <55122EF2.5010205@oracle.com> References: <55122EF2.5010205@oracle.com> Message-ID: <551235EE.8010108@oracle.com> David, Dean: > bug: https://bugs.openjdk.java.net/browse/JDK-8072740 > > webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ > > Simple fix, contributed by Dean Long, that allows the jvm.cfg file to > be located in the "closed" location. The arm and ppc jvm.cfg files can > then be moved to that "closed" location. Looks good to me. Tim From david.holmes at oracle.com Wed Mar 25 04:21:15 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Mar 2015 14:21:15 +1000 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <551235EE.8010108@oracle.com> References: <55122EF2.5010205@oracle.com> <551235EE.8010108@oracle.com> Message-ID: <551237BB.9030507@oracle.com> Thanks Tim! David On 25/03/2015 2:13 PM, Tim Bell wrote: > David, Dean: > >> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ >> >> Simple fix, contributed by Dean Long, that allows the jvm.cfg file to >> be located in the "closed" location. The arm and ppc jvm.cfg files can >> then be moved to that "closed" location. > > Looks good to me. > > Tim > From erik.joelsson at oracle.com Wed Mar 25 08:01:29 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 25 Mar 2015 09:01:29 +0100 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5511D8F6.5090808@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> Message-ID: <55126B59.5030605@oracle.com> Hello Peter, The new source layout and Lib-jdk.accessibility.gmk look much better. Thanks! Regarding the .def files, I was mistaken and missed that they were referenced in the LDFLAGS, they were indeed used in the build so no reason to remove them. /Erik On 2015-03-24 22:36, Pete Brunet wrote: > Here's the latest patch: > http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ > > The changes are: > - restructured the native libraries from one directory to several > directories on a per DLL/EXE basis > - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk > - removed the source for the Ferret and Monkey test tools which will be > the subject of a later patch > - removed the DEF files; although they were used in the build, there are > no build or runtime problems after their removal > > On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: >> On 2015-03-23 18:31, Pete Brunet wrote: >>> Hi Erik, >>> >>> I tried the restructuring about 2 weeks ago and the build failed trying >>> to find an h file in the common directory. I used two directories on >>> the SRC := setting for SetupNativeCompilation but the build failed not >>> finding an h file located in the second (common) directory. >> For .h files, you need to also set the -I flag correctly. This is not >> done automatically from SRC. (Maybe it should.) >> >> We have a pattern that you can copy to get this behavior. E.g. >> >> LIBINSTRUMENT_SRC := >> $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ >> $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument >> \ >> # >> LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ >> $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ >> -Isomewhere-else \ >> # >> >>>> There are a number of extra .cpp files in the libaccessbridge dir that >>>> aren't used in any of the libraries. What is the purpose of those? >>>> Keeping source code around that is not being built seems strange to >>>> me. There are also extra .rc files and a bunch of .DEF files. Are the >>>> .DEF files used for anything? If all these files really need to be >>>> included in our source base, perhaps sort them out into a >>>> jdk.accessibility/windows/native/misc dir or something so that it's >>>> clear what is needed to build the product and what is not? >>> The Ferret and Monkey tools need to be built and added to the JDK >>> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files plus >>> AccessInfo.cpp. Do you want me to remove those now and add them back in >>> later? >> I would prefer that. It is generally better to make each change >> coherent, unless there is much work in making some changes that will >> very shortly be undone. This is not the case here. This change should >> only add the files that are needed for these dll:s to compile. >> >>> JavaAccessBridge.DEF is pretty empty. I'll see if the build will work >>> without it. >>> >>> WinAccessBridge.DEF seems like it might be needed. What do you think? >> Is it accessed by the compiler? Unless it is given as input to the >> compiler or linker command line, it is not used in the build. Unless >> the microsoft compiler does some magic trick and picks up files >> unasked based on filename, that is. (Unlikely but not impossible, but >> I'd like to see that proved.) >> >> /Magnus From david.holmes at oracle.com Wed Mar 25 09:08:28 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Mar 2015 19:08:28 +1000 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <55122EF2.5010205@oracle.com> References: <55122EF2.5010205@oracle.com> Message-ID: <55127B0C.2050909@oracle.com> I've been asked to make a change so a new webrev will be firthcoming. Thanks, David On 25/03/2015 1:43 PM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8072740 > > webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ > > Simple fix, contributed by Dean Long, that allows the jvm.cfg file to be > located in the "closed" location. The arm and ppc jvm.cfg files can then > be moved to that "closed" location. > > Thanks, > David From peter.brunet at oracle.com Wed Mar 25 13:28:14 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 25 Mar 2015 08:28:14 -0500 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5511C7B0.9010607@oracle.com> References: <550CF47C.4050306@oracle.com> <5511AA7D.2080702@oracle.com> <5511C7B0.9010607@oracle.com> Message-ID: <5512B7EE.2000801@oracle.com> On 3/24/15 3:23 PM, Pete Brunet wrote: > Hi Sergey, That's pretty much the case. I just went through the code > and found these differences: > - merged in JDK-8055173 (merge jawt.dll into javaaccessbridge.dll) which > was recently pushed. That should have been jawtaccessbridge.dll (not jawt.dll). > - removed some dead code > - cleaned up up comments/documentation > - cleaned up some code indentation issues > - in package-private EventQueueMonitor.addTopLevelWindow the return > value was not used so I changed the return from boolean to void > > If anyone knows if that last one is a compatibility issue I will change > it back. > > Pete > > On 3/24/15 1:18 PM, Sergey Bylokhov wrote: >> Hi,Pete. >> Do I understand correctly that the code itself were not changed except >> files location? >> >> 21.03.15 7:33, Pete Brunet wrote: >>> Please review the following patch which will add the code of the Java >>> Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK. >>> >>> This code is used by Assistive Technology such as screen readers and >>> screen magnifiers used by those who are blind or have low vision. AT >>> use the JAB native API and the JAB in turn uses the Java Accessibility >>> API (JAAPI). For more information on JAAPI see the javax.accessibility >>> package. This is a Windows accessibility solution. >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.00/ >>> >>> Pete >> From peter.brunet at oracle.com Wed Mar 25 14:44:53 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 25 Mar 2015 09:44:53 -0500 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <55126B59.5030605@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> <55126B59.5030605@oracle.com> Message-ID: <5512C9E5.8090307@oracle.com> On 3/25/15 3:01 AM, Erik Joelsson wrote: > Hello Peter, > > The new source layout and Lib-jdk.accessibility.gmk look much better. > Thanks! > > Regarding the .def files, I was mistaken and missed that they were > referenced in the LDFLAGS, they were indeed used in the build so no > reason to remove them. Thanks Erik, My build and tests ran OK so apparently they are no longer needed. To all: My hope is to push this patch into 9 tomorrow (Thursday) so please let me know if there are any additional issues as soon as you can. Pete > > /Erik > > On 2015-03-24 22:36, Pete Brunet wrote: >> Here's the latest patch: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ >> >> The changes are: >> - restructured the native libraries from one directory to several >> directories on a per DLL/EXE basis >> - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk >> - removed the source for the Ferret and Monkey test tools which will be >> the subject of a later patch >> - removed the DEF files; although they were used in the build, there are >> no build or runtime problems after their removal >> >> On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: >>> On 2015-03-23 18:31, Pete Brunet wrote: >>>> Hi Erik, >>>> >>>> I tried the restructuring about 2 weeks ago and the build failed >>>> trying >>>> to find an h file in the common directory. I used two directories on >>>> the SRC := setting for SetupNativeCompilation but the build failed not >>>> finding an h file located in the second (common) directory. >>> For .h files, you need to also set the -I flag correctly. This is not >>> done automatically from SRC. (Maybe it should.) >>> >>> We have a pattern that you can copy to get this behavior. E.g. >>> >>> LIBINSTRUMENT_SRC := >>> $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ >>> $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument >>> >>> \ >>> # >>> LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ >>> $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ >>> -Isomewhere-else \ >>> # >>> >>>>> There are a number of extra .cpp files in the libaccessbridge dir >>>>> that >>>>> aren't used in any of the libraries. What is the purpose of those? >>>>> Keeping source code around that is not being built seems strange to >>>>> me. There are also extra .rc files and a bunch of .DEF files. Are the >>>>> .DEF files used for anything? If all these files really need to be >>>>> included in our source base, perhaps sort them out into a >>>>> jdk.accessibility/windows/native/misc dir or something so that it's >>>>> clear what is needed to build the product and what is not? >>>> The Ferret and Monkey tools need to be built and added to the JDK >>>> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files >>>> plus >>>> AccessInfo.cpp. Do you want me to remove those now and add them >>>> back in >>>> later? >>> I would prefer that. It is generally better to make each change >>> coherent, unless there is much work in making some changes that will >>> very shortly be undone. This is not the case here. This change should >>> only add the files that are needed for these dll:s to compile. >>> >>>> JavaAccessBridge.DEF is pretty empty. I'll see if the build will work >>>> without it. >>>> >>>> WinAccessBridge.DEF seems like it might be needed. What do you think? >>> Is it accessed by the compiler? Unless it is given as input to the >>> compiler or linker command line, it is not used in the build. Unless >>> the microsoft compiler does some magic trick and picks up files >>> unasked based on filename, that is. (Unlikely but not impossible, but >>> I'd like to see that proved.) >>> >>> /Magnus > From Sergey.Bylokhov at oracle.com Wed Mar 25 15:16:53 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Mar 2015 18:16:53 +0300 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5512C9E5.8090307@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> <55126B59.5030605@oracle.com> <5512C9E5.8090307@oracle.com> Message-ID: <5512D165.2050402@oracle.com> The fix looks fine. But it is interesting, do we have an option to remove all deprecated methods during this opening? or can we do it later? or we cannot? 25.03.15 17:44, Pete Brunet wrote: > > On 3/25/15 3:01 AM, Erik Joelsson wrote: >> Hello Peter, >> >> The new source layout and Lib-jdk.accessibility.gmk look much better. >> Thanks! >> >> Regarding the .def files, I was mistaken and missed that they were >> referenced in the LDFLAGS, they were indeed used in the build so no >> reason to remove them. > Thanks Erik, My build and tests ran OK so apparently they are no longer > needed. > > To all: My hope is to push this patch into 9 tomorrow (Thursday) so > please let me know if there are any additional issues as soon as you can. > > Pete >> /Erik >> >> On 2015-03-24 22:36, Pete Brunet wrote: >>> Here's the latest patch: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ >>> >>> The changes are: >>> - restructured the native libraries from one directory to several >>> directories on a per DLL/EXE basis >>> - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk >>> - removed the source for the Ferret and Monkey test tools which will be >>> the subject of a later patch >>> - removed the DEF files; although they were used in the build, there are >>> no build or runtime problems after their removal >>> >>> On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: >>>> On 2015-03-23 18:31, Pete Brunet wrote: >>>>> Hi Erik, >>>>> >>>>> I tried the restructuring about 2 weeks ago and the build failed >>>>> trying >>>>> to find an h file in the common directory. I used two directories on >>>>> the SRC := setting for SetupNativeCompilation but the build failed not >>>>> finding an h file located in the second (common) directory. >>>> For .h files, you need to also set the -I flag correctly. This is not >>>> done automatically from SRC. (Maybe it should.) >>>> >>>> We have a pattern that you can copy to get this behavior. E.g. >>>> >>>> LIBINSTRUMENT_SRC := >>>> $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ >>>> $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument >>>> >>>> \ >>>> # >>>> LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ >>>> $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ >>>> -Isomewhere-else \ >>>> # >>>> >>>>>> There are a number of extra .cpp files in the libaccessbridge dir >>>>>> that >>>>>> aren't used in any of the libraries. What is the purpose of those? >>>>>> Keeping source code around that is not being built seems strange to >>>>>> me. There are also extra .rc files and a bunch of .DEF files. Are the >>>>>> .DEF files used for anything? If all these files really need to be >>>>>> included in our source base, perhaps sort them out into a >>>>>> jdk.accessibility/windows/native/misc dir or something so that it's >>>>>> clear what is needed to build the product and what is not? >>>>> The Ferret and Monkey tools need to be built and added to the JDK >>>>> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files >>>>> plus >>>>> AccessInfo.cpp. Do you want me to remove those now and add them >>>>> back in >>>>> later? >>>> I would prefer that. It is generally better to make each change >>>> coherent, unless there is much work in making some changes that will >>>> very shortly be undone. This is not the case here. This change should >>>> only add the files that are needed for these dll:s to compile. >>>> >>>>> JavaAccessBridge.DEF is pretty empty. I'll see if the build will work >>>>> without it. >>>>> >>>>> WinAccessBridge.DEF seems like it might be needed. What do you think? >>>> Is it accessed by the compiler? Unless it is given as input to the >>>> compiler or linker command line, it is not used in the build. Unless >>>> the microsoft compiler does some magic trick and picks up files >>>> unasked based on filename, that is. (Unlikely but not impossible, but >>>> I'd like to see that proved.) >>>> >>>> /Magnus -- Best regards, Sergey. From peter.brunet at oracle.com Wed Mar 25 15:55:05 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 25 Mar 2015 10:55:05 -0500 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5512D165.2050402@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> <55126B59.5030605@oracle.com> <5512C9E5.8090307@oracle.com> <5512D165.2050402@oracle.com> Message-ID: <5512DA59.2090208@oracle.com> Hi Sergey, Which methods are you referring to? -Pete On 3/25/15 10:16 AM, Sergey Bylokhov wrote: > The fix looks fine. > But it is interesting, do we have an option to remove all deprecated > methods during this opening? or can we do it later? or we cannot? > > 25.03.15 17:44, Pete Brunet wrote: >> >> On 3/25/15 3:01 AM, Erik Joelsson wrote: >>> Hello Peter, >>> >>> The new source layout and Lib-jdk.accessibility.gmk look much better. >>> Thanks! >>> >>> Regarding the .def files, I was mistaken and missed that they were >>> referenced in the LDFLAGS, they were indeed used in the build so no >>> reason to remove them. >> Thanks Erik, My build and tests ran OK so apparently they are no longer >> needed. >> >> To all: My hope is to push this patch into 9 tomorrow (Thursday) so >> please let me know if there are any additional issues as soon as you >> can. >> >> Pete >>> /Erik >>> >>> On 2015-03-24 22:36, Pete Brunet wrote: >>>> Here's the latest patch: >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ >>>> >>>> The changes are: >>>> - restructured the native libraries from one directory to several >>>> directories on a per DLL/EXE basis >>>> - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk >>>> - removed the source for the Ferret and Monkey test tools which >>>> will be >>>> the subject of a later patch >>>> - removed the DEF files; although they were used in the build, >>>> there are >>>> no build or runtime problems after their removal >>>> >>>> On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: >>>>> On 2015-03-23 18:31, Pete Brunet wrote: >>>>>> Hi Erik, >>>>>> >>>>>> I tried the restructuring about 2 weeks ago and the build failed >>>>>> trying >>>>>> to find an h file in the common directory. I used two >>>>>> directories on >>>>>> the SRC := setting for SetupNativeCompilation but the build >>>>>> failed not >>>>>> finding an h file located in the second (common) directory. >>>>> For .h files, you need to also set the -I flag correctly. This is not >>>>> done automatically from SRC. (Maybe it should.) >>>>> >>>>> We have a pattern that you can copy to get this behavior. E.g. >>>>> >>>>> LIBINSTRUMENT_SRC := >>>>> $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ >>>>> $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument >>>>> >>>>> >>>>> \ >>>>> # >>>>> LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ >>>>> $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ >>>>> -Isomewhere-else \ >>>>> # >>>>> >>>>>>> There are a number of extra .cpp files in the libaccessbridge dir >>>>>>> that >>>>>>> aren't used in any of the libraries. What is the purpose of those? >>>>>>> Keeping source code around that is not being built seems strange to >>>>>>> me. There are also extra .rc files and a bunch of .DEF files. >>>>>>> Are the >>>>>>> .DEF files used for anything? If all these files really need to be >>>>>>> included in our source base, perhaps sort them out into a >>>>>>> jdk.accessibility/windows/native/misc dir or something so that it's >>>>>>> clear what is needed to build the product and what is not? >>>>>> The Ferret and Monkey tools need to be built and added to the JDK >>>>>> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files >>>>>> plus >>>>>> AccessInfo.cpp. Do you want me to remove those now and add them >>>>>> back in >>>>>> later? >>>>> I would prefer that. It is generally better to make each change >>>>> coherent, unless there is much work in making some changes that will >>>>> very shortly be undone. This is not the case here. This change should >>>>> only add the files that are needed for these dll:s to compile. >>>>> >>>>>> JavaAccessBridge.DEF is pretty empty. I'll see if the build will >>>>>> work >>>>>> without it. >>>>>> >>>>>> WinAccessBridge.DEF seems like it might be needed. What do you >>>>>> think? >>>>> Is it accessed by the compiler? Unless it is given as input to the >>>>> compiler or linker command line, it is not used in the build. Unless >>>>> the microsoft compiler does some magic trick and picks up files >>>>> unasked based on filename, that is. (Unlikely but not impossible, but >>>>> I'd like to see that proved.) >>>>> >>>>> /Magnus > > From mandy.chung at oracle.com Wed Mar 25 16:12:34 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Mar 2015 09:12:34 -0700 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5511D8F6.5090808@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> Message-ID: <5512DE72.9020907@oracle.com> On 3/24/2015 2:36 PM, Pete Brunet wrote: > Here's the latest patch: > http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ The modules.xml change looks fine. Mandy From philip.race at oracle.com Wed Mar 25 16:26:23 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 25 Mar 2015 09:26:23 -0700 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5512DA59.2090208@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> <55126B59.5030605@oracle.com> <5512C9E5.8090307@oracle.com> <5512D165.2050402@oracle.com> <5512DA59.2090208@oracle.com> Message-ID: <5512E1AF.9010304@oracle.com> AWTEventMonitor.java has a bunch of deprecated methods. If you don't have time now (I expect you don't) then it can be revisited later. Open sourcing is different than binary compatibility. The change jdk/make/copy/Copy-java.gmk suggests that accessbridge is the only reason the closed version of the java.policy file exists. However these files are not otherwise identical. And also implies there'd be a corresponding closed review to remove that file. I am not sure this is exactly right. I see one other difference - that looks a bit like someone else overlooked the closed file. Clearly no one looking only at the open code can ever know that its safe to remove that copy for closed builds anyway I think the safe thing to do is undo that change in Copy-java.gmk and leave the closed file in place and discuss off-line with the security team why the files differ .. -phil. On 3/25/2015 8:55 AM, Pete Brunet wrote: > Hi Sergey, Which methods are you referring to? -Pete > > On 3/25/15 10:16 AM, Sergey Bylokhov wrote: >> The fix looks fine. >> But it is interesting, do we have an option to remove all deprecated >> methods during this opening? or can we do it later? or we cannot? >> >> 25.03.15 17:44, Pete Brunet wrote: >>> On 3/25/15 3:01 AM, Erik Joelsson wrote: >>>> Hello Peter, >>>> >>>> The new source layout and Lib-jdk.accessibility.gmk look much better. >>>> Thanks! >>>> >>>> Regarding the .def files, I was mistaken and missed that they were >>>> referenced in the LDFLAGS, they were indeed used in the build so no >>>> reason to remove them. >>> Thanks Erik, My build and tests ran OK so apparently they are no longer >>> needed. >>> >>> To all: My hope is to push this patch into 9 tomorrow (Thursday) so >>> please let me know if there are any additional issues as soon as you >>> can. >>> >>> Pete >>>> /Erik >>>> >>>> On 2015-03-24 22:36, Pete Brunet wrote: >>>>> Here's the latest patch: >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ >>>>> >>>>> The changes are: >>>>> - restructured the native libraries from one directory to several >>>>> directories on a per DLL/EXE basis >>>>> - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk >>>>> - removed the source for the Ferret and Monkey test tools which >>>>> will be >>>>> the subject of a later patch >>>>> - removed the DEF files; although they were used in the build, >>>>> there are >>>>> no build or runtime problems after their removal >>>>> >>>>> On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: >>>>>> On 2015-03-23 18:31, Pete Brunet wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> I tried the restructuring about 2 weeks ago and the build failed >>>>>>> trying >>>>>>> to find an h file in the common directory. I used two >>>>>>> directories on >>>>>>> the SRC := setting for SetupNativeCompilation but the build >>>>>>> failed not >>>>>>> finding an h file located in the second (common) directory. >>>>>> For .h files, you need to also set the -I flag correctly. This is not >>>>>> done automatically from SRC. (Maybe it should.) >>>>>> >>>>>> We have a pattern that you can copy to get this behavior. E.g. >>>>>> >>>>>> LIBINSTRUMENT_SRC := >>>>>> $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ >>>>>> $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument >>>>>> >>>>>> >>>>>> \ >>>>>> # >>>>>> LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ >>>>>> $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ >>>>>> -Isomewhere-else \ >>>>>> # >>>>>> >>>>>>>> There are a number of extra .cpp files in the libaccessbridge dir >>>>>>>> that >>>>>>>> aren't used in any of the libraries. What is the purpose of those? >>>>>>>> Keeping source code around that is not being built seems strange to >>>>>>>> me. There are also extra .rc files and a bunch of .DEF files. >>>>>>>> Are the >>>>>>>> .DEF files used for anything? If all these files really need to be >>>>>>>> included in our source base, perhaps sort them out into a >>>>>>>> jdk.accessibility/windows/native/misc dir or something so that it's >>>>>>>> clear what is needed to build the product and what is not? >>>>>>> The Ferret and Monkey tools need to be built and added to the JDK >>>>>>> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files >>>>>>> plus >>>>>>> AccessInfo.cpp. Do you want me to remove those now and add them >>>>>>> back in >>>>>>> later? >>>>>> I would prefer that. It is generally better to make each change >>>>>> coherent, unless there is much work in making some changes that will >>>>>> very shortly be undone. This is not the case here. This change should >>>>>> only add the files that are needed for these dll:s to compile. >>>>>> >>>>>>> JavaAccessBridge.DEF is pretty empty. I'll see if the build will >>>>>>> work >>>>>>> without it. >>>>>>> >>>>>>> WinAccessBridge.DEF seems like it might be needed. What do you >>>>>>> think? >>>>>> Is it accessed by the compiler? Unless it is given as input to the >>>>>> compiler or linker command line, it is not used in the build. Unless >>>>>> the microsoft compiler does some magic trick and picks up files >>>>>> unasked based on filename, that is. (Unlikely but not impossible, but >>>>>> I'd like to see that proved.) >>>>>> >>>>>> /Magnus >> From peter.brunet at oracle.com Wed Mar 25 17:58:07 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 25 Mar 2015 12:58:07 -0500 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5512E1AF.9010304@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> <55126B59.5030605@oracle.com> <5512C9E5.8090307@oracle.com> <5512D165.2050402@oracle.com> <5512DA59.2090208@oracle.com> <5512E1AF.9010304@oracle.com> Message-ID: <5512F72F.8000304@oracle.com> Thanks Phil, On 3/25/15 11:26 AM, Phil Race wrote: > AWTEventMonitor.java has a bunch of deprecated methods. > If you don't have time now (I expect you don't) then it can be > revisited later. Open sourcing is different than binary compatibility. These were deprecated via CCC 8007499. > > The change jdk/make/copy/Copy-java.gmk suggests that accessbridge > is the only reason the closed version of the java.policy file exists. > However these files are not otherwise identical. And also implies > there'd be a corresponding closed review to remove that file. The full (open/closed) webrev has been under review since Feb 17. > > I am not sure this is exactly right. I see one other difference - that > looks a bit like someone else overlooked the closed file. Please elaborate. > > Clearly no one looking only at the open code can ever know that its safe > to remove that copy for closed builds anyway > > I think the safe thing to do is undo that change in Copy-java.gmk > and leave the closed file in place and discuss off-line with the > security team why the files differ .. I'll start a discussion on this. > > -phil. > > > On 3/25/2015 8:55 AM, Pete Brunet wrote: >> Hi Sergey, Which methods are you referring to? -Pete >> >> On 3/25/15 10:16 AM, Sergey Bylokhov wrote: >>> The fix looks fine. >>> But it is interesting, do we have an option to remove all deprecated >>> methods during this opening? or can we do it later? or we cannot? >>> >>> 25.03.15 17:44, Pete Brunet wrote: >>>> On 3/25/15 3:01 AM, Erik Joelsson wrote: >>>>> Hello Peter, >>>>> >>>>> The new source layout and Lib-jdk.accessibility.gmk look much better. >>>>> Thanks! >>>>> >>>>> Regarding the .def files, I was mistaken and missed that they were >>>>> referenced in the LDFLAGS, they were indeed used in the build so no >>>>> reason to remove them. >>>> Thanks Erik, My build and tests ran OK so apparently they are no >>>> longer >>>> needed. >>>> >>>> To all: My hope is to push this patch into 9 tomorrow (Thursday) so >>>> please let me know if there are any additional issues as soon as you >>>> can. >>>> >>>> Pete >>>>> /Erik >>>>> >>>>> On 2015-03-24 22:36, Pete Brunet wrote: >>>>>> Here's the latest patch: >>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ >>>>>> >>>>>> The changes are: >>>>>> - restructured the native libraries from one directory to several >>>>>> directories on a per DLL/EXE basis >>>>>> - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk >>>>>> - removed the source for the Ferret and Monkey test tools which >>>>>> will be >>>>>> the subject of a later patch >>>>>> - removed the DEF files; although they were used in the build, >>>>>> there are >>>>>> no build or runtime problems after their removal >>>>>> >>>>>> On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-03-23 18:31, Pete Brunet wrote: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>> I tried the restructuring about 2 weeks ago and the build failed >>>>>>>> trying >>>>>>>> to find an h file in the common directory. I used two >>>>>>>> directories on >>>>>>>> the SRC := setting for SetupNativeCompilation but the build >>>>>>>> failed not >>>>>>>> finding an h file located in the second (common) directory. >>>>>>> For .h files, you need to also set the -I flag correctly. This >>>>>>> is not >>>>>>> done automatically from SRC. (Maybe it should.) >>>>>>> >>>>>>> We have a pattern that you can copy to get this behavior. E.g. >>>>>>> >>>>>>> LIBINSTRUMENT_SRC := >>>>>>> $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ >>>>>>> $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument >>>>>>> >>>>>>> >>>>>>> >>>>>>> \ >>>>>>> # >>>>>>> LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ >>>>>>> $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ >>>>>>> -Isomewhere-else \ >>>>>>> # >>>>>>> >>>>>>>>> There are a number of extra .cpp files in the libaccessbridge dir >>>>>>>>> that >>>>>>>>> aren't used in any of the libraries. What is the purpose of >>>>>>>>> those? >>>>>>>>> Keeping source code around that is not being built seems >>>>>>>>> strange to >>>>>>>>> me. There are also extra .rc files and a bunch of .DEF files. >>>>>>>>> Are the >>>>>>>>> .DEF files used for anything? If all these files really need >>>>>>>>> to be >>>>>>>>> included in our source base, perhaps sort them out into a >>>>>>>>> jdk.accessibility/windows/native/misc dir or something so that >>>>>>>>> it's >>>>>>>>> clear what is needed to build the product and what is not? >>>>>>>> The Ferret and Monkey tools need to be built and added to the JDK >>>>>>>> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files >>>>>>>> plus >>>>>>>> AccessInfo.cpp. Do you want me to remove those now and add them >>>>>>>> back in >>>>>>>> later? >>>>>>> I would prefer that. It is generally better to make each change >>>>>>> coherent, unless there is much work in making some changes that >>>>>>> will >>>>>>> very shortly be undone. This is not the case here. This change >>>>>>> should >>>>>>> only add the files that are needed for these dll:s to compile. >>>>>>> >>>>>>>> JavaAccessBridge.DEF is pretty empty. I'll see if the build will >>>>>>>> work >>>>>>>> without it. >>>>>>>> >>>>>>>> WinAccessBridge.DEF seems like it might be needed. What do you >>>>>>>> think? >>>>>>> Is it accessed by the compiler? Unless it is given as input to the >>>>>>> compiler or linker command line, it is not used in the build. >>>>>>> Unless >>>>>>> the microsoft compiler does some magic trick and picks up files >>>>>>> unasked based on filename, that is. (Unlikely but not >>>>>>> impossible, but >>>>>>> I'd like to see that proved.) >>>>>>> >>>>>>> /Magnus >>> > From philip.race at oracle.com Wed Mar 25 18:38:28 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 25 Mar 2015 11:38:28 -0700 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5512F72F.8000304@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> <55126B59.5030605@oracle.com> <5512C9E5.8090307@oracle.com> <5512D165.2050402@oracle.com> <5512DA59.2090208@oracle.com> <5512E1AF.9010304@oracle.com> <5512F72F.8000304@oracle.com> Message-ID: <551300A4.3070402@oracle.com> On 3/25/2015 10:58 AM, Pete Brunet wrote: > Thanks Phil, > > On 3/25/15 11:26 AM, Phil Race wrote: >> AWTEventMonitor.java has a bunch of deprecated methods. >> If you don't have time now (I expect you don't) then it can be >> revisited later. Open sourcing is different than binary compatibility. > These were deprecated via CCC 8007499. >> The change jdk/make/copy/Copy-java.gmk suggests that accessbridge >> is the only reason the closed version of the java.policy file exists. >> However these files are not otherwise identical. And also implies >> there'd be a corresponding closed review to remove that file. I realise now that the list is additive, so having looked again I think this is OK. I have no further comments on the open part of the review. Looks fine to me. -phil. From david.holmes at oracle.com Wed Mar 25 22:42:36 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 08:42:36 +1000 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <55127B0C.2050909@oracle.com> References: <55122EF2.5010205@oracle.com> <55127B0C.2050909@oracle.com> Message-ID: <551339DC.5080607@oracle.com> New webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev.v2/ This doesn't define the ALT_JVMCFG_SRC in the open file - which makes more sense for the clean up. I was unsure if $(wildcard xxx) would behave okay if xxx was an undefined variable, but it seems to handle it okay. Thanks, David On 25/03/2015 7:08 PM, David Holmes wrote: > I've been asked to make a change so a new webrev will be firthcoming. > > Thanks, > David > > On 25/03/2015 1:43 PM, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ >> >> Simple fix, contributed by Dean Long, that allows the jvm.cfg file to be >> located in the "closed" location. The arm and ppc jvm.cfg files can then >> be moved to that "closed" location. >> >> Thanks, >> David From david.holmes at oracle.com Thu Mar 26 05:24:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 15:24:26 +1000 Subject: [8u60] RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <55122EF2.5010205@oracle.com> References: <55122EF2.5010205@oracle.com> Message-ID: <5513980A.7060703@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev.8u/ Simple fix, contributed by Dean Long, that allows the jvm.cfg file to be located in the "closed" location. The arm and ppc jvm.cfg files can then be moved to that "closed" location. The backport is slightly different to the JDK 9 fix as the inclusion of the "custom" file at the end, rather than the beginning, precludes defining the ALT_JVMCFG_SRC variable there. I intend to push this to hs-dev rather than jdk8u-dev as there is other work going into hs-dev that is waiting for this. Thanks, David From dean.long at oracle.com Thu Mar 26 06:38:57 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 25 Mar 2015 23:38:57 -0700 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <551339DC.5080607@oracle.com> References: <55122EF2.5010205@oracle.com> <55127B0C.2050909@oracle.com> <551339DC.5080607@oracle.com> Message-ID: <5513A981.2040601@oracle.com> On 3/25/2015 3:42 PM, David Holmes wrote: > New webrev: > > http://cr.openjdk.java.net/~dholmes/8072740/webrev.v2/ > > This doesn't define the ALT_JVMCFG_SRC in the open file - which makes > more sense for the clean up. > > I was unsure if $(wildcard xxx) would behave okay if xxx was an > undefined variable, but it seems to handle it okay. > That feels like we're depending on undefined behavior, so it could possibly behave differently in different versions of gcc. How about something like this instead: // Override with ALT_JVMCFG_SRC if defined. // ALT_JVMCFG_SRC must either be set to a file that exists or be undefined. ifdef ALT_JVMCFG_SRC JVMCFG_SRC := $(ALT_JVMCFG_SRC) endif dl > Thanks, > David > > On 25/03/2015 7:08 PM, David Holmes wrote: >> I've been asked to make a change so a new webrev will be firthcoming. >> >> Thanks, >> David >> >> On 25/03/2015 1:43 PM, David Holmes wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ >>> >>> Simple fix, contributed by Dean Long, that allows the jvm.cfg file >>> to be >>> located in the "closed" location. The arm and ppc jvm.cfg files can >>> then >>> be moved to that "closed" location. >>> >>> Thanks, >>> David From david.holmes at oracle.com Thu Mar 26 06:57:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 16:57:13 +1000 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <5513A981.2040601@oracle.com> References: <55122EF2.5010205@oracle.com> <55127B0C.2050909@oracle.com> <551339DC.5080607@oracle.com> <5513A981.2040601@oracle.com> Message-ID: <5513ADC9.1070100@oracle.com> On 26/03/2015 4:38 PM, Dean Long wrote: > On 3/25/2015 3:42 PM, David Holmes wrote: >> New webrev: >> >> http://cr.openjdk.java.net/~dholmes/8072740/webrev.v2/ >> >> This doesn't define the ALT_JVMCFG_SRC in the open file - which makes >> more sense for the clean up. >> >> I was unsure if $(wildcard xxx) would behave okay if xxx was an >> undefined variable, but it seems to handle it okay. >> > > That feels like we're depending on undefined behavior, so it could No it means I don't know how it is defined to behave but it seems to be working. :) Hopefully one of the build folk can chime in here with something definitive. As far as I can tell an empty pattern matches nothing - which is what we want. > possibly behave differently in different versions of gcc. How about This is make not gcc :) > something like this instead: > > // Override with ALT_JVMCFG_SRC if defined. > // ALT_JVMCFG_SRC must either be set to a file that exists or be undefined. > ifdef ALT_JVMCFG_SRC > JVMCFG_SRC := $(ALT_JVMCFG_SRC) > endif I thought about doing something like this but it has a side-effect on the "alternative" side - you would have to set ALT_JVMCFG_SRC only for those cases where the alternative file exists (or else add another existence check on the open side). I went for the combined minimal solution that seems to work. Thanks, David > dl > >> Thanks, >> David >> >> On 25/03/2015 7:08 PM, David Holmes wrote: >>> I've been asked to make a change so a new webrev will be firthcoming. >>> >>> Thanks, >>> David >>> >>> On 25/03/2015 1:43 PM, David Holmes wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ >>>> >>>> Simple fix, contributed by Dean Long, that allows the jvm.cfg file >>>> to be >>>> located in the "closed" location. The arm and ppc jvm.cfg files can >>>> then >>>> be moved to that "closed" location. >>>> >>>> Thanks, >>>> David > From erik.joelsson at oracle.com Thu Mar 26 07:57:32 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Mar 2015 08:57:32 +0100 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <5513ADC9.1070100@oracle.com> References: <55122EF2.5010205@oracle.com> <55127B0C.2050909@oracle.com> <551339DC.5080607@oracle.com> <5513A981.2040601@oracle.com> <5513ADC9.1070100@oracle.com> Message-ID: <5513BBEC.1040301@oracle.com> Hello David, This version looks good to me. Regarding wildcard, AFAIK, your usage of the function is correct. It will just go through the list of strings, expand them and see if the files exist. For each file that does exist, it will add it to the return list. If given an empty list, it will just return an empty list, which is what we want. /Erik On 2015-03-26 07:57, David Holmes wrote: > On 26/03/2015 4:38 PM, Dean Long wrote: >> On 3/25/2015 3:42 PM, David Holmes wrote: >>> New webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8072740/webrev.v2/ >>> >>> This doesn't define the ALT_JVMCFG_SRC in the open file - which makes >>> more sense for the clean up. >>> >>> I was unsure if $(wildcard xxx) would behave okay if xxx was an >>> undefined variable, but it seems to handle it okay. >>> >> >> That feels like we're depending on undefined behavior, so it could > > No it means I don't know how it is defined to behave but it seems to > be working. :) Hopefully one of the build folk can chime in here with > something definitive. As far as I can tell an empty pattern matches > nothing - which is what we want. > >> possibly behave differently in different versions of gcc. How about > > This is make not gcc :) > >> something like this instead: >> >> // Override with ALT_JVMCFG_SRC if defined. >> // ALT_JVMCFG_SRC must either be set to a file that exists or be >> undefined. >> ifdef ALT_JVMCFG_SRC >> JVMCFG_SRC := $(ALT_JVMCFG_SRC) >> endif > > I thought about doing something like this but it has a side-effect on > the "alternative" side - you would have to set ALT_JVMCFG_SRC only for > those cases where the alternative file exists (or else add another > existence check on the open side). > > I went for the combined minimal solution that seems to work. > > Thanks, > David > >> dl >> >>> Thanks, >>> David >>> >>> On 25/03/2015 7:08 PM, David Holmes wrote: >>>> I've been asked to make a change so a new webrev will be firthcoming. >>>> >>>> Thanks, >>>> David >>>> >>>> On 25/03/2015 1:43 PM, David Holmes wrote: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ >>>>> >>>>> Simple fix, contributed by Dean Long, that allows the jvm.cfg file >>>>> to be >>>>> located in the "closed" location. The arm and ppc jvm.cfg files can >>>>> then >>>>> be moved to that "closed" location. >>>>> >>>>> Thanks, >>>>> David >> From erik.joelsson at oracle.com Thu Mar 26 08:00:10 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Mar 2015 09:00:10 +0100 Subject: [8u60] RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <5513980A.7060703@oracle.com> References: <55122EF2.5010205@oracle.com> <5513980A.7060703@oracle.com> Message-ID: <5513BC8A.3040301@oracle.com> Looks good to me. /Erik On 2015-03-26 06:24, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8072740 > > webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev.8u/ > > Simple fix, contributed by Dean Long, that allows the jvm.cfg file to > be located in the "closed" location. The arm and ppc jvm.cfg files can > then be moved to that "closed" location. > > The backport is slightly different to the JDK 9 fix as the inclusion > of the "custom" file at the end, rather than the beginning, precludes > defining the ALT_JVMCFG_SRC variable there. > > I intend to push this to hs-dev rather than jdk8u-dev as there is > other work going into hs-dev that is waiting for this. > > Thanks, > David > > From david.holmes at oracle.com Thu Mar 26 10:19:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 20:19:16 +1000 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <5513BBEC.1040301@oracle.com> References: <55122EF2.5010205@oracle.com> <55127B0C.2050909@oracle.com> <551339DC.5080607@oracle.com> <5513A981.2040601@oracle.com> <5513ADC9.1070100@oracle.com> <5513BBEC.1040301@oracle.com> Message-ID: <5513DD24.90600@oracle.com> On 26/03/2015 5:57 PM, Erik Joelsson wrote: > Hello David, > > This version looks good to me. Regarding wildcard, AFAIK, your usage of > the function is correct. It will just go through the list of strings, > expand them and see if the files exist. For each file that does exist, > it will add it to the return list. If given an empty list, it will just > return an empty list, which is what we want. Terrific! Thanks Erik. David > /Erik > > On 2015-03-26 07:57, David Holmes wrote: >> On 26/03/2015 4:38 PM, Dean Long wrote: >>> On 3/25/2015 3:42 PM, David Holmes wrote: >>>> New webrev: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8072740/webrev.v2/ >>>> >>>> This doesn't define the ALT_JVMCFG_SRC in the open file - which makes >>>> more sense for the clean up. >>>> >>>> I was unsure if $(wildcard xxx) would behave okay if xxx was an >>>> undefined variable, but it seems to handle it okay. >>>> >>> >>> That feels like we're depending on undefined behavior, so it could >> >> No it means I don't know how it is defined to behave but it seems to >> be working. :) Hopefully one of the build folk can chime in here with >> something definitive. As far as I can tell an empty pattern matches >> nothing - which is what we want. >> >>> possibly behave differently in different versions of gcc. How about >> >> This is make not gcc :) >> >>> something like this instead: >>> >>> // Override with ALT_JVMCFG_SRC if defined. >>> // ALT_JVMCFG_SRC must either be set to a file that exists or be >>> undefined. >>> ifdef ALT_JVMCFG_SRC >>> JVMCFG_SRC := $(ALT_JVMCFG_SRC) >>> endif >> >> I thought about doing something like this but it has a side-effect on >> the "alternative" side - you would have to set ALT_JVMCFG_SRC only for >> those cases where the alternative file exists (or else add another >> existence check on the open side). >> >> I went for the combined minimal solution that seems to work. >> >> Thanks, >> David >> >>> dl >>> >>>> Thanks, >>>> David >>>> >>>> On 25/03/2015 7:08 PM, David Holmes wrote: >>>>> I've been asked to make a change so a new webrev will be firthcoming. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 25/03/2015 1:43 PM, David Holmes wrote: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ >>>>>> >>>>>> Simple fix, contributed by Dean Long, that allows the jvm.cfg file >>>>>> to be >>>>>> located in the "closed" location. The arm and ppc jvm.cfg files can >>>>>> then >>>>>> be moved to that "closed" location. >>>>>> >>>>>> Thanks, >>>>>> David >>> > From david.holmes at oracle.com Thu Mar 26 10:19:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 20:19:30 +1000 Subject: [8u60] RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <5513BC8A.3040301@oracle.com> References: <55122EF2.5010205@oracle.com> <5513980A.7060703@oracle.com> <5513BC8A.3040301@oracle.com> Message-ID: <5513DD32.7050803@oracle.com> Thanks Erik! David On 26/03/2015 6:00 PM, Erik Joelsson wrote: > Looks good to me. > > /Erik > > On 2015-03-26 06:24, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev.8u/ >> >> Simple fix, contributed by Dean Long, that allows the jvm.cfg file to >> be located in the "closed" location. The arm and ppc jvm.cfg files can >> then be moved to that "closed" location. >> >> The backport is slightly different to the JDK 9 fix as the inclusion >> of the "custom" file at the end, rather than the beginning, precludes >> defining the ALT_JVMCFG_SRC variable there. >> >> I intend to push this to hs-dev rather than jdk8u-dev as there is >> other work going into hs-dev that is waiting for this. >> >> Thanks, >> David >> >> > From magnus.ihse.bursie at oracle.com Thu Mar 26 10:54:36 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Mar 2015 11:54:36 +0100 Subject: RFR: JDK-8076060 Improve make bootstrap process Message-ID: <5513E56C.9080609@oracle.com> The process of actually starting to build the proper targets in Main.gmk is not straightforward. Somewhat similar to how configure prepares the ground for make, the initial part of the make logic needs to handle the make process "bootstrapping". Unfortunately, this logic has been spread out in multiple places, and not very clear. This makes it fragile and hard to improve. This patch collects all bootstrapping logic into a new Init.gmk, with hopefully a clear flow showing how the system is initialized. It also improves handling of outdated spec files by a new CHECK_CONF control variable, along with various other small fixes to issues typically related to make bootstrapping. For instance, bash completion support for make targets is sped up considerably. A few slightly unrelated spring cleaning fixes are also included, for good measure. One of the ideas behind this patch is that the top-level Makefile should be a thin wrapper, so all actual build logic is in the make directory. In the end, it turned out to be best to have some sanity checking on make itself in that file. Going forward, I'd like to see an even better way of gathering the real make targets and modules, rather than polling Main.gmk. But now at least we're prepared for such a step. Bug: https://bugs.openjdk.java.net/browse/JDK-8076060 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8076060-improve-make-bootstrap/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 26 11:46:38 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Mar 2015 12:46:38 +0100 Subject: RFR: 8072740: move closed jvm.cfg files out of open repo In-Reply-To: <551339DC.5080607@oracle.com> References: <55122EF2.5010205@oracle.com> <55127B0C.2050909@oracle.com> <551339DC.5080607@oracle.com> Message-ID: <5513F19E.7030807@oracle.com> On 2015-03-25 23:42, David Holmes wrote: > New webrev: > > http://cr.openjdk.java.net/~dholmes/8072740/webrev.v2/ > > This doesn't define the ALT_JVMCFG_SRC in the open file - which makes > more sense for the clean up. > > I was unsure if $(wildcard xxx) would behave okay if xxx was an > undefined variable, but it seems to handle it okay. Looks good to me. Make evaluates undefined variables as the empty string. So it's perfectly safe. In newer GNU make versions, there is a flag available for warning for the use of uninitialized variables. While it would be good to turn it on, we have too many instances where we assume that an undefined variables is okay to read from. :-( /Magnus > > Thanks, > David > > On 25/03/2015 7:08 PM, David Holmes wrote: >> I've been asked to make a change so a new webrev will be firthcoming. >> >> Thanks, >> David >> >> On 25/03/2015 1:43 PM, David Holmes wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8072740 >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ >>> >>> Simple fix, contributed by Dean Long, that allows the jvm.cfg file >>> to be >>> located in the "closed" location. The arm and ppc jvm.cfg files can >>> then >>> be moved to that "closed" location. >>> >>> Thanks, >>> David From magnus.ihse.bursie at oracle.com Thu Mar 26 11:51:21 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Mar 2015 12:51:21 +0100 Subject: RfR JDK-8055831 Open Source Java Access Bridge In-Reply-To: <5512C9E5.8090307@oracle.com> References: <550CF47C.4050306@oracle.com> <550FE5B9.3040706@oracle.com> <55104DDC.903@oracle.com> <551161B1.6060907@oracle.com> <5511D8F6.5090808@oracle.com> <55126B59.5030605@oracle.com> <5512C9E5.8090307@oracle.com> Message-ID: <5513F2B9.5090800@oracle.com> On 2015-03-25 15:44, Pete Brunet wrote: > > On 3/25/15 3:01 AM, Erik Joelsson wrote: >> Hello Peter, >> >> The new source layout and Lib-jdk.accessibility.gmk look much better. >> Thanks! >> >> Regarding the .def files, I was mistaken and missed that they were >> referenced in the LDFLAGS, they were indeed used in the build so no >> reason to remove them. > Thanks Erik, My build and tests ran OK so apparently they are no longer > needed. > > To all: My hope is to push this patch into 9 tomorrow (Thursday) so > please let me know if there are any additional issues as soon as you can. New version looks good to me too. /Magnus > > Pete >> /Erik >> >> On 2015-03-24 22:36, Pete Brunet wrote: >>> Here's the latest patch: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/ >>> >>> The changes are: >>> - restructured the native libraries from one directory to several >>> directories on a per DLL/EXE basis >>> - that impacted jdk/make/lib/Lib-jdk.accessibility.gmk >>> - removed the source for the Ferret and Monkey test tools which will be >>> the subject of a later patch >>> - removed the DEF files; although they were used in the build, there are >>> no build or runtime problems after their removal >>> >>> On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote: >>>> On 2015-03-23 18:31, Pete Brunet wrote: >>>>> Hi Erik, >>>>> >>>>> I tried the restructuring about 2 weeks ago and the build failed >>>>> trying >>>>> to find an h file in the common directory. I used two directories on >>>>> the SRC := setting for SetupNativeCompilation but the build failed not >>>>> finding an h file located in the second (common) directory. >>>> For .h files, you need to also set the -I flag correctly. This is not >>>> done automatically from SRC. (Maybe it should.) >>>> >>>> We have a pattern that you can copy to get this behavior. E.g. >>>> >>>> LIBINSTRUMENT_SRC := >>>> $(JDK_TOPDIR)/src/java.instrument/share/native/libinstrument \ >>>> $(JDK_TOPDIR)/src/java.instrument/$(OPENJDK_TARGET_OS_TYPE)/native/libinstrument >>>> >>>> \ >>>> # >>>> LIBINSTRUMENT_CFLAGS := $(CFLAGS_JDKLIB) \ >>>> $(addprefix -I, $(LIBINSTRUMENT_SRC)) \ >>>> -Isomewhere-else \ >>>> # >>>> >>>>>> There are a number of extra .cpp files in the libaccessbridge dir >>>>>> that >>>>>> aren't used in any of the libraries. What is the purpose of those? >>>>>> Keeping source code around that is not being built seems strange to >>>>>> me. There are also extra .rc files and a bunch of .DEF files. Are the >>>>>> .DEF files used for anything? If all these files really need to be >>>>>> included in our source base, perhaps sort them out into a >>>>>> jdk.accessibility/windows/native/misc dir or something so that it's >>>>>> clear what is needed to build the product and what is not? >>>>> The Ferret and Monkey tools need to be built and added to the JDK >>>>> image. This is JDK-8056925. That covers 2 CPP and the 3 RC files >>>>> plus >>>>> AccessInfo.cpp. Do you want me to remove those now and add them >>>>> back in >>>>> later? >>>> I would prefer that. It is generally better to make each change >>>> coherent, unless there is much work in making some changes that will >>>> very shortly be undone. This is not the case here. This change should >>>> only add the files that are needed for these dll:s to compile. >>>> >>>>> JavaAccessBridge.DEF is pretty empty. I'll see if the build will work >>>>> without it. >>>>> >>>>> WinAccessBridge.DEF seems like it might be needed. What do you think? >>>> Is it accessed by the compiler? Unless it is given as input to the >>>> compiler or linker command line, it is not used in the build. Unless >>>> the microsoft compiler does some magic trick and picks up files >>>> unasked based on filename, that is. (Unlikely but not impossible, but >>>> I'd like to see that proved.) >>>> >>>> /Magnus From erik.joelsson at oracle.com Thu Mar 26 14:21:22 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Mar 2015 15:21:22 +0100 Subject: RFR: JDK-8076060 Improve make bootstrap process In-Reply-To: <5513E56C.9080609@oracle.com> References: <5513E56C.9080609@oracle.com> Message-ID: <551415E2.3070002@oracle.com> Hello, This looks like a nice cleanup. A couple of questions and notes. Init.gmk 40: When would topdir not be set? 56, 59, 188, 215: Please break lines if possible 63: What kind of error messages? 192: Why does MAKEOVERRIDES need to be reset? Is it automatically propagated to submake and we prefer to use USER_MAKE_VARS instead? 194: Should we have "$(INIT_TARGETS): main-init" InitSupport.gmk 57: I agree this should be moved somewhere else. We need to split MakeBase into one file with very basic functions like this. Can be done later I suppose. 291: Please break line spec.gmk.in 62: Please break line /Erik On 2015-03-26 11:54, Magnus Ihse Bursie wrote: > The process of actually starting to build the proper targets in > Main.gmk is not straightforward. Somewhat similar to how configure > prepares the ground for make, the initial part of the make logic needs > to handle the make process "bootstrapping". > > Unfortunately, this logic has been spread out in multiple places, and > not very clear. This makes it fragile and hard to improve. > > This patch collects all bootstrapping logic into a new Init.gmk, with > hopefully a clear flow showing how the system is initialized. > > It also improves handling of outdated spec files by a new CHECK_CONF > control variable, along with various other small fixes to issues > typically related to make bootstrapping. For instance, bash completion > support for make targets is sped up considerably. A few slightly > unrelated spring cleaning fixes are also included, for good measure. > > One of the ideas behind this patch is that the top-level Makefile > should be a thin wrapper, so all actual build logic is in the make > directory. In the end, it turned out to be best to have some sanity > checking on make itself in that file. > > Going forward, I'd like to see an even better way of gathering the > real make targets and modules, rather than polling Main.gmk. But now > at least we're prepared for such a step. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076060 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8076060-improve-make-bootstrap/webrev.01 > > /Magnus > From magnus.ihse.bursie at oracle.com Thu Mar 26 15:11:44 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Mar 2015 16:11:44 +0100 Subject: RFR: JDK-8076060 Improve make bootstrap process In-Reply-To: <551415E2.3070002@oracle.com> References: <5513E56C.9080609@oracle.com> <551415E2.3070002@oracle.com> Message-ID: <551421B0.1010702@oracle.com> On 2015-03-26 15:21, Erik Joelsson wrote: > Hello, > > This looks like a nice cleanup. Thanks! :-) New webrev that hopefully addresses all issues below is here: http://cr.openjdk.java.net/~ihse/JDK-8076060-improve-make-bootstrap/webrev.02 Comments inline. > > Init.gmk > 40: When would topdir not be set? Answered by a comment now: # If included from the top-level Makefile then topdir is set, but not when # recursively calling ourself with a spec. > > 56, 59, 188, 215: Please break lines if possible Done. > > 63: What kind of error messages? If we have no configuration at all, we warn the user that this is the case. For this to work, though, we must not *first* get caught by make claiming that there is no such target. That is, withouth this code, we would get "No such target" as response to e.g. "make all", instead of the message "No configuration found, please run configure". However, I've changed this now (to your off-list suggestion, thanks!) to allow whatever the user entered as a target, instead of an arbitrary list. I also improved the comment: # Without at least a single valid configuration, we cannot extract any real # targets. To provide a helpful error message about the missing configuration # later on, accept whatever targets the user has provided for now. ALL_MAIN_TARGETS := $(if $(MAKECMDGOALS), $(MAKECMDGOALS), default) > 192: Why does MAKEOVERRIDES need to be reset? Is it automatically > propagated to submake and we prefer to use USER_MAKE_VARS instead? MAKEOVERRIDES is a special GNU Make variable which contains all the "FOO=bar" variables set on the command line. Unless cleared, it is automatically passed down to all further Make calls. In this case, we don't want to do that since we have a lot of Init.gmk-internal variables. All relevant user-passed variables are in USER_MAKE_VARS. I updated the comment to: # MAKEOVERRIDES is automatically set and propagated by Make to sub-Make calls. # We need to clear it of the init-specific variables. The user-specified # variables are explicitely propagated using $(USER_MAKE_VARS). > 194: Should we have "$(INIT_TARGETS): main-init" No, since we don't want to rotate logs before running reconfigure. However, I changed the main dependencies thus: main: $(INIT_TARGETS) main-init so reconfigure will be run ahead of rotating the logs (this works due to .NOTPARALLEL:). Seems slightly more logical. > > InitSupport.gmk > 57: I agree this should be moved somewhere else. We need to split > MakeBase into one file with very basic functions like this. Can be > done later I suppose. Yes, we definitely need to split MakeBase, and yes, it definitely is a separate issue. :-) > > 291: Please break line > > spec.gmk.in > 62: Please break line Done and done. :) /Magnus From erik.joelsson at oracle.com Thu Mar 26 15:15:17 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Mar 2015 16:15:17 +0100 Subject: RFR: JDK-8076060 Improve make bootstrap process In-Reply-To: <551421B0.1010702@oracle.com> References: <5513E56C.9080609@oracle.com> <551415E2.3070002@oracle.com> <551421B0.1010702@oracle.com> Message-ID: <55142285.1040609@oracle.com> Thanks, looks good to me now. /Erik On 2015-03-26 16:11, Magnus Ihse Bursie wrote: > On 2015-03-26 15:21, Erik Joelsson wrote: >> Hello, >> >> This looks like a nice cleanup. > > Thanks! :-) > > New webrev that hopefully addresses all issues below is here: > > http://cr.openjdk.java.net/~ihse/JDK-8076060-improve-make-bootstrap/webrev.02 > > > Comments inline. > >> >> Init.gmk >> 40: When would topdir not be set? > Answered by a comment now: > # If included from the top-level Makefile then topdir is set, but not > when > # recursively calling ourself with a spec. > >> >> 56, 59, 188, 215: Please break lines if possible > Done. >> >> 63: What kind of error messages? > > If we have no configuration at all, we warn the user that this is the > case. For this to work, though, we must not *first* get caught by make > claiming that there is no such target. That is, withouth this code, we > would get "No such target" as response to e.g. "make all", instead of > the message "No configuration found, please run configure". However, > I've changed this now (to your off-list suggestion, thanks!) to allow > whatever the user entered as a target, instead of an arbitrary list. I > also improved the comment: > > # Without at least a single valid configuration, we cannot extract > any real > # targets. To provide a helpful error message about the missing > configuration > # later on, accept whatever targets the user has provided for now. > ALL_MAIN_TARGETS := $(if $(MAKECMDGOALS), $(MAKECMDGOALS), default) > >> 192: Why does MAKEOVERRIDES need to be reset? Is it automatically >> propagated to submake and we prefer to use USER_MAKE_VARS instead? > MAKEOVERRIDES is a special GNU Make variable which contains all the > "FOO=bar" variables set on the command line. Unless cleared, it is > automatically passed down to all further Make calls. In this case, we > don't want to do that since we have a lot of Init.gmk-internal > variables. All relevant user-passed variables are in USER_MAKE_VARS. I > updated the comment to: > > # MAKEOVERRIDES is automatically set and propagated by Make to > sub-Make calls. > # We need to clear it of the init-specific variables. The > user-specified > # variables are explicitely propagated using $(USER_MAKE_VARS). > > >> 194: Should we have "$(INIT_TARGETS): main-init" > No, since we don't want to rotate logs before running reconfigure. > > However, I changed the main dependencies thus: > main: $(INIT_TARGETS) main-init > so reconfigure will be run ahead of rotating the logs (this works due > to .NOTPARALLEL:). Seems slightly more logical. > >> >> InitSupport.gmk >> 57: I agree this should be moved somewhere else. We need to split >> MakeBase into one file with very basic functions like this. Can be >> done later I suppose. > Yes, we definitely need to split MakeBase, and yes, it definitely is a > separate issue. :-) > >> >> 291: Please break line >> >> spec.gmk.in >> 62: Please break line > Done and done. :) > > /Magnus > From erik.joelsson at oracle.com Fri Mar 27 11:46:55 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 27 Mar 2015 12:46:55 +0100 Subject: RFR: JDK-8076123: 9-dev build fail: make/Init.gmk:142: *** multiple target patterns. Stop. Message-ID: <5515432F.6010700@oracle.com> Hello, There are a number of issues caused by JDK-8076060: 1. A completely new configuration fails when running make the first time. Second attempt succeeds. That's what failing in the bug description. 2. Bootcycle-images is broken as the current working dir in Main.gmk has changed from TOPDIR/make to TOPDIR. 3. The sanity check that spec.gmk is actually a spec for the current source tree fails if the source root has a symlink somewhere in the path, or if it's in a special cygwin directory like /home/something/jdk9-dev. This patch addresses all of these. 1. was caused by the build output of module-deps.gmk ending up in the ALL_MAIN_TARGETS. The problem was that the check for if module-deps.gmk needed to be built only checked for the directory "make-support" instead of "make-support/module-deps.gmk". The directory make-support currently exists from just running configure. 2. Changed the make call for bootcycle-images to use an absolute path to Main.gmk so that current working directory becomes irrelevant. 3. This sanity check is new. To get it to work better, I changed configure to save two extra versions of the TOPDIR since the "topdir" calculated by make doesn't always match what we found in configure. Then in the sanity check I compare to all 3 different versions of TOPDIR. This seems to cover the cases reported so far. Ideally a path comparison shouldn't be done just by comparing strings, but we also need this to run fast at build time, so no shell execution if it can be avoided. Bug: https://bugs.openjdk.java.net/browse/JDK-8076123 Webrev: http://cr.openjdk.java.net/~erikj/8076123/webrev.top.01/ /Erik From magnus.ihse.bursie at oracle.com Fri Mar 27 12:06:17 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 27 Mar 2015 13:06:17 +0100 Subject: RFR: JDK-8076123: 9-dev build fail: make/Init.gmk:142: *** multiple target patterns. Stop. In-Reply-To: <5515432F.6010700@oracle.com> References: <5515432F.6010700@oracle.com> Message-ID: <8D015A9F-3BFD-4E90-A772-FE830960D7CD@oracle.com> Looks good to me. Thank you for fixing this. /Magnus > 27 mar 2015 kl. 12:46 skrev Erik Joelsson : > > Hello, > > There are a number of issues caused by JDK-8076060: > > 1. A completely new configuration fails when running make the first time. Second attempt succeeds. That's what failing in the bug description. > 2. Bootcycle-images is broken as the current working dir in Main.gmk has changed from TOPDIR/make to TOPDIR. > 3. The sanity check that spec.gmk is actually a spec for the current source tree fails if the source root has a symlink somewhere in the path, or if it's in a special cygwin directory like /home/something/jdk9-dev. > > This patch addresses all of these. > > 1. was caused by the build output of module-deps.gmk ending up in the ALL_MAIN_TARGETS. The problem was that the check for if module-deps.gmk needed to be built only checked for the directory "make-support" instead of "make-support/module-deps.gmk". The directory make-support currently exists from just running configure. > > 2. Changed the make call for bootcycle-images to use an absolute path to Main.gmk so that current working directory becomes irrelevant. > > 3. This sanity check is new. To get it to work better, I changed configure to save two extra versions of the TOPDIR since the "topdir" calculated by make doesn't always match what we found in configure. Then in the sanity check I compare to all 3 different versions of TOPDIR. This seems to cover the cases reported so far. Ideally a path comparison shouldn't be done just by comparing strings, but we also need this to run fast at build time, so no shell execution if it can be avoided. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076123 > Webrev: http://cr.openjdk.java.net/~erikj/8076123/webrev.top.01/ > > /Erik