From david.holmes at oracle.com  Tue May  2 01:02:28 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 2 May 2017 11:02:28 +1000
Subject: objcopy issues on Solaris
In-Reply-To: <22929188ecbf43c8b4a15cfeaa22a582@sap.com>
References: <ea7d76968db24cbcaf02b7dd7f0b3e05@sap.com>
 <5d2b0feb-910c-e80a-aaba-05a7fa835284@oracle.com>
 <390fa253c3854c51b1a930d66c54ecf4@sap.com>
 <d1e28d22-510c-4e73-4689-bcbd27ed7fda@oracle.com>
 <22929188ecbf43c8b4a15cfeaa22a582@sap.com>
Message-ID: <b2ec4815-f161-d8df-856c-55cbf27c51d7@oracle.com>

On 29/04/2017 2:00 AM, Reingruber, Richard wrote:
> Hi Erik,
>
> I noticed this workaround, but apparently it was removed again from the hotspot build with http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/8c76e844a7f9.
>
> This confused me, nevertheless I tried it.
>
>   fix_empty_sec_hdr_flags libjvm.so
>   objcopy --only-keep-debug libjvm.so libjvm.debuginfo     # here I got the "Not enough room for program headers, try linking with -N"
>   add_gnu_debuglink libjvm.debuginfo libjvm.so
>
> Succeeds: now I got a libjvm.debuginfo, but it seems to be corrupted:
>
>   $ elfdump libjvm.debuginfo > dump.txt
>   Segmentation Fault (core dumped)
>
> I assume the workaround was removed because of this corruption(that's what the bugs JDK-8034005 and JDK-8033602 suggest), but why was it kept for the jdk build then? Do you know?

Magnus cleaned it all up in 9 under:

http://hg.openjdk.java.net/jdk9/dev/rev/f105fbc01fd7

but there was no backport to 8u.

> I was hoping that Oracle's binutils 2.21.1 contains fixes for the issues which are not yet pushed upstream. This would explain my problems with binutils 2.28 from gnu.org

I have no idea what the policy was regarding pushing anything upstream 
in this area, but 2.21.1 was certainly addressing some solaris specific 
issues. I don't think the bug system these numbers refer to still exists:

7004268 update binutils to 2.21.1
7157682 gobjcopy sets .SUNW_cap section attributes to 0
7165526 gobjcopy corrupts SUNW_dof section in libjvm.so and breaks dtrace

David

> Cheers, Richard.
>
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> Sent: Freitag, 28. April 2017 15:34
> To: Baesken, Matthias <matthias.baesken at sap.com>; David Holmes <david.holmes at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' <magnus.ihse.bursie at oracle.com>
> Cc: Simonis, Volker <volker.simonis at sap.com>; Reingruber, Richard <richard.reingruber at sap.com>
> Subject: Re: objcopy issues on Solaris
>
> Hello,
>
> In jdk8u we still have this workaround for broken gobjcopy in
> NativeCompilation.gmk:
>
> # gobjcopy crashes on "empty" section headers with the SHF_ALLOC flag set.
> # Use $(FIX_EMPTY_SEC_HDR_FLAGS) to clear the SHF_ALLOC flag (if set) from
> # empty section headers until a fixed $(OBJCOPY) is available.
> # An empty section header has sh_addr == 0 and sh_size == 0.
> # This problem has only been seen on Solaris X64, but we call this tool
> # on all Solaris builds just in case.
> #
> # $(OBJCOPY) --add-gnu-debuglink=... corrupts SUNW_* sections.
> # Use $(ADD_GNU_DEBUGLINK) until a fixed $(OBJCOPY) is available.
> $$($1_OBJECT_DIR)/$$(LIBRARY_PREFIX)$$($1_LIBRARY).debuginfo :
> $$($1_TARGET) \
>                  $(FIX_EMPTY_SEC_HDR_FLAGS) $(ADD_GNU_DEBUGLINK)
>          $(RM) $$@
>          $(FIX_EMPTY_SEC_HDR_FLAGS) $(LOG_INFO) $$<
>          $(OBJCOPY) --only-keep-debug $$< $$@
>          $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) $(LOG_INFO) $$(@F) $$<
>
> I don't know if this is related to your problem. We were able to remove
> the above in JDK 9 because gobjcopy in Solaris 11 is not exhibiting this
> problem for us. The introduction of this workaround is from before my
> time so I don't know the details. The tools FIX_EMPTY_SEC_HDR_FLAGS and
> ADD_GNU_DEBUGLINK are in the jdk8u src.
>
> I checked a build machine for jdk8u and it reports "GNU objcopy 2.15"
> and this seems to be from the default OS package (Solaris 10). We have
> had problems with bugs in gobjcopy in the past though. (Example
> https://bugs.openjdk.java.net/browse/JDK-8034021) So try to get all the
> latest patches for it.
>
> /Erik
>
> On 2017-04-28 14:20, Baesken, Matthias wrote:
>>> GNU objcopy (GNU Binutils) 2.21.1
>>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>> This is a Solaris 11u1 package.
>>
>> Hi David, thanks for the info.
>> But what about  Solaris 10 ?
>>
>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>>
>> mentions 10u6  supported for JDK8 .
>>
>> And  does  the  11u1 package   developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>    Contain special objcopy patches ?
>>
>> Best regards, Matthias
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Freitag, 28. April 2017 13:24
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; Erik Joelsson (erik.joelsson at oracle.com) <erik.joelsson at oracle.com>; 'magnus.ihse.bursie at oracle.com' <magnus.ihse.bursie at oracle.com>
>> Cc: Simonis, Volker <volker.simonis at sap.com>; Reingruber, Richard <richard.reingruber at sap.com>
>> Subject: Re: objcopy issues on Solaris
>>
>> Hi Matthias,
>>
>> On 28/04/2017 7:21 PM, Baesken, Matthias wrote:
>>> Hello, we are facing problems with gobjcopy on Solaris 10 x86_64.
>>> When processing libjvm.so (product build) with FDS and separated debug-infos we are getting :
>>>
>>> objcopy: libjvm.debuginfo: Not enough room for program headers, try linking with -N
>>>
>>> It looks like we are running into this (or a similar) problems :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-7165598
>>>
>>> As recommended in those bugs :
>>>
>>>    x86
>>>    https://bugs.openjdk.java.net/browse/JDK-8034005
>>>
>>>    (and similar Sparc issue)
>>>    https://bugs.openjdk.java.net/browse/JDK-8033602
>>>
>>> We are using objcopy from binutils-2.28 (downloaded and built ourselves from standard binutils gnu.org page)
>>> and still get the mentioned error.
>>>
>>> In the OpenJDK version checks, 2.21 seems to be needed minimum,
>>> the comments in version check says "objcopy prior to 2.21.1 on solaris is broken and is not usable.".
>>>
>>> Could you tell us the exact version of  objcopy / gobjcopy  you are using in 8 and 9 on Solaris  to
>>> process the debuginfo ?
>>> And where do you get the gobjcopy from?
>> GNU objcopy (GNU Binutils) 2.21.1
>>
>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>
>> This is a Solaris 11u1 package.
>>
>> David
>> -----
>>
>>> Thanks, Richard and Matthias
>>>
>


From david.holmes at oracle.com  Tue May  2 03:26:09 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 2 May 2017 13:26:09 +1000
Subject: objcopy issues on Solaris
In-Reply-To: <b2ec4815-f161-d8df-856c-55cbf27c51d7@oracle.com>
References: <ea7d76968db24cbcaf02b7dd7f0b3e05@sap.com>
 <5d2b0feb-910c-e80a-aaba-05a7fa835284@oracle.com>
 <390fa253c3854c51b1a930d66c54ecf4@sap.com>
 <d1e28d22-510c-4e73-4689-bcbd27ed7fda@oracle.com>
 <22929188ecbf43c8b4a15cfeaa22a582@sap.com>
 <b2ec4815-f161-d8df-856c-55cbf27c51d7@oracle.com>
Message-ID: <2325c693-3c6f-86d4-ab93-70ceaab0e4a0@oracle.com>

I should clarify that while 2.21.1 fixed these Solaris issues I have not 
found anything to suggest that this was anything other than the 
"regular" binutils 2.21.1 as obtained from GNU.

http://ftp.gnu.org/gnu/binutils/

David

On 2/05/2017 11:02 AM, David Holmes wrote:
> On 29/04/2017 2:00 AM, Reingruber, Richard wrote:
>> Hi Erik,
>>
>> I noticed this workaround, but apparently it was removed again from
>> the hotspot build with
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/8c76e844a7f9.
>>
>> This confused me, nevertheless I tried it.
>>
>>   fix_empty_sec_hdr_flags libjvm.so
>>   objcopy --only-keep-debug libjvm.so libjvm.debuginfo     # here I
>> got the "Not enough room for program headers, try linking with -N"
>>   add_gnu_debuglink libjvm.debuginfo libjvm.so
>>
>> Succeeds: now I got a libjvm.debuginfo, but it seems to be corrupted:
>>
>>   $ elfdump libjvm.debuginfo > dump.txt
>>   Segmentation Fault (core dumped)
>>
>> I assume the workaround was removed because of this corruption(that's
>> what the bugs JDK-8034005 and JDK-8033602 suggest), but why was it
>> kept for the jdk build then? Do you know?
>
> Magnus cleaned it all up in 9 under:
>
> http://hg.openjdk.java.net/jdk9/dev/rev/f105fbc01fd7
>
> but there was no backport to 8u.
>
>> I was hoping that Oracle's binutils 2.21.1 contains fixes for the
>> issues which are not yet pushed upstream. This would explain my
>> problems with binutils 2.28 from gnu.org
>
> I have no idea what the policy was regarding pushing anything upstream
> in this area, but 2.21.1 was certainly addressing some solaris specific
> issues. I don't think the bug system these numbers refer to still exists:
>
> 7004268 update binutils to 2.21.1
> 7157682 gobjcopy sets .SUNW_cap section attributes to 0
> 7165526 gobjcopy corrupts SUNW_dof section in libjvm.so and breaks dtrace
>
> David
>
>> Cheers, Richard.
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Freitag, 28. April 2017 15:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; David Holmes
>> <david.holmes at oracle.com>; 'build-dev at openjdk.java.net'
>> <build-dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com'
>> <magnus.ihse.bursie at oracle.com>
>> Cc: Simonis, Volker <volker.simonis at sap.com>; Reingruber, Richard
>> <richard.reingruber at sap.com>
>> Subject: Re: objcopy issues on Solaris
>>
>> Hello,
>>
>> In jdk8u we still have this workaround for broken gobjcopy in
>> NativeCompilation.gmk:
>>
>> # gobjcopy crashes on "empty" section headers with the SHF_ALLOC flag
>> set.
>> # Use $(FIX_EMPTY_SEC_HDR_FLAGS) to clear the SHF_ALLOC flag (if set)
>> from
>> # empty section headers until a fixed $(OBJCOPY) is available.
>> # An empty section header has sh_addr == 0 and sh_size == 0.
>> # This problem has only been seen on Solaris X64, but we call this tool
>> # on all Solaris builds just in case.
>> #
>> # $(OBJCOPY) --add-gnu-debuglink=... corrupts SUNW_* sections.
>> # Use $(ADD_GNU_DEBUGLINK) until a fixed $(OBJCOPY) is available.
>> $$($1_OBJECT_DIR)/$$(LIBRARY_PREFIX)$$($1_LIBRARY).debuginfo :
>> $$($1_TARGET) \
>>                  $(FIX_EMPTY_SEC_HDR_FLAGS) $(ADD_GNU_DEBUGLINK)
>>          $(RM) $$@
>>          $(FIX_EMPTY_SEC_HDR_FLAGS) $(LOG_INFO) $$<
>>          $(OBJCOPY) --only-keep-debug $$< $$@
>>          $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) $(LOG_INFO) $$(@F) $$<
>>
>> I don't know if this is related to your problem. We were able to remove
>> the above in JDK 9 because gobjcopy in Solaris 11 is not exhibiting this
>> problem for us. The introduction of this workaround is from before my
>> time so I don't know the details. The tools FIX_EMPTY_SEC_HDR_FLAGS and
>> ADD_GNU_DEBUGLINK are in the jdk8u src.
>>
>> I checked a build machine for jdk8u and it reports "GNU objcopy 2.15"
>> and this seems to be from the default OS package (Solaris 10). We have
>> had problems with bugs in gobjcopy in the past though. (Example
>> https://bugs.openjdk.java.net/browse/JDK-8034021) So try to get all the
>> latest patches for it.
>>
>> /Erik
>>
>> On 2017-04-28 14:20, Baesken, Matthias wrote:
>>>> GNU objcopy (GNU Binutils) 2.21.1
>>>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>>> This is a Solaris 11u1 package.
>>>
>>> Hi David, thanks for the info.
>>> But what about  Solaris 10 ?
>>>
>>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>>>
>>> mentions 10u6  supported for JDK8 .
>>>
>>> And  does  the  11u1 package
>>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>>    Contain special objcopy patches ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Freitag, 28. April 2017 13:24
>>> To: Baesken, Matthias <matthias.baesken at sap.com>;
>>> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; Erik
>>> Joelsson (erik.joelsson at oracle.com) <erik.joelsson at oracle.com>;
>>> 'magnus.ihse.bursie at oracle.com' <magnus.ihse.bursie at oracle.com>
>>> Cc: Simonis, Volker <volker.simonis at sap.com>; Reingruber, Richard
>>> <richard.reingruber at sap.com>
>>> Subject: Re: objcopy issues on Solaris
>>>
>>> Hi Matthias,
>>>
>>> On 28/04/2017 7:21 PM, Baesken, Matthias wrote:
>>>> Hello, we are facing problems with gobjcopy on Solaris 10 x86_64.
>>>> When processing libjvm.so (product build) with FDS and separated
>>>> debug-infos we are getting :
>>>>
>>>> objcopy: libjvm.debuginfo: Not enough room for program headers, try
>>>> linking with -N
>>>>
>>>> It looks like we are running into this (or a similar) problems :
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-7165598
>>>>
>>>> As recommended in those bugs :
>>>>
>>>>    x86
>>>>    https://bugs.openjdk.java.net/browse/JDK-8034005
>>>>
>>>>    (and similar Sparc issue)
>>>>    https://bugs.openjdk.java.net/browse/JDK-8033602
>>>>
>>>> We are using objcopy from binutils-2.28 (downloaded and built
>>>> ourselves from standard binutils gnu.org page)
>>>> and still get the mentioned error.
>>>>
>>>> In the OpenJDK version checks, 2.21 seems to be needed minimum,
>>>> the comments in version check says "objcopy prior to 2.21.1 on
>>>> solaris is broken and is not usable.".
>>>>
>>>> Could you tell us the exact version of  objcopy / gobjcopy  you are
>>>> using in 8 and 9 on Solaris  to
>>>> process the debuginfo ?
>>>> And where do you get the gobjcopy from?
>>> GNU objcopy (GNU Binutils) 2.21.1
>>>
>>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>>
>>> This is a Solaris 11u1 package.
>>>
>>> David
>>> -----
>>>
>>>> Thanks, Richard and Matthias
>>>>
>>


From richard.reingruber at sap.com  Tue May  2 07:21:39 2017
From: richard.reingruber at sap.com (Reingruber, Richard)
Date: Tue, 2 May 2017 07:21:39 +0000
Subject: objcopy issues on Solaris
In-Reply-To: <2325c693-3c6f-86d4-ab93-70ceaab0e4a0@oracle.com>
References: <ea7d76968db24cbcaf02b7dd7f0b3e05@sap.com>
 <5d2b0feb-910c-e80a-aaba-05a7fa835284@oracle.com>
 <390fa253c3854c51b1a930d66c54ecf4@sap.com>
 <d1e28d22-510c-4e73-4689-bcbd27ed7fda@oracle.com>
 <22929188ecbf43c8b4a15cfeaa22a582@sap.com>
 <b2ec4815-f161-d8df-856c-55cbf27c51d7@oracle.com>
 <2325c693-3c6f-86d4-ab93-70ceaab0e4a0@oracle.com>
Message-ID: <bee8d07b58de4f9ead80874f0457fde0@sap.com>

Hi David,

Thanks for the information.

The issue could be caused as well by the ld we use on our build server. With a newer one I don't see the "Not enough room for program headers" message.

Thanks,
Richard.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 2. Mai 2017 05:26
To: Reingruber, Richard <richard.reingruber at sap.com>; Erik Joelsson <erik.joelsson at oracle.com>; Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' <magnus.ihse.bursie at oracle.com>
Cc: Simonis, Volker <volker.simonis at sap.com>
Subject: Re: objcopy issues on Solaris

I should clarify that while 2.21.1 fixed these Solaris issues I have not 
found anything to suggest that this was anything other than the 
"regular" binutils 2.21.1 as obtained from GNU.

http://ftp.gnu.org/gnu/binutils/

David

On 2/05/2017 11:02 AM, David Holmes wrote:
> On 29/04/2017 2:00 AM, Reingruber, Richard wrote:
>> Hi Erik,
>>
>> I noticed this workaround, but apparently it was removed again from
>> the hotspot build with
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/8c76e844a7f9.
>>
>> This confused me, nevertheless I tried it.
>>
>>   fix_empty_sec_hdr_flags libjvm.so
>>   objcopy --only-keep-debug libjvm.so libjvm.debuginfo     # here I
>> got the "Not enough room for program headers, try linking with -N"
>>   add_gnu_debuglink libjvm.debuginfo libjvm.so
>>
>> Succeeds: now I got a libjvm.debuginfo, but it seems to be corrupted:
>>
>>   $ elfdump libjvm.debuginfo > dump.txt
>>   Segmentation Fault (core dumped)
>>
>> I assume the workaround was removed because of this corruption(that's
>> what the bugs JDK-8034005 and JDK-8033602 suggest), but why was it
>> kept for the jdk build then? Do you know?
>
> Magnus cleaned it all up in 9 under:
>
> http://hg.openjdk.java.net/jdk9/dev/rev/f105fbc01fd7
>
> but there was no backport to 8u.
>
>> I was hoping that Oracle's binutils 2.21.1 contains fixes for the
>> issues which are not yet pushed upstream. This would explain my
>> problems with binutils 2.28 from gnu.org
>
> I have no idea what the policy was regarding pushing anything upstream
> in this area, but 2.21.1 was certainly addressing some solaris specific
> issues. I don't think the bug system these numbers refer to still exists:
>
> 7004268 update binutils to 2.21.1
> 7157682 gobjcopy sets .SUNW_cap section attributes to 0
> 7165526 gobjcopy corrupts SUNW_dof section in libjvm.so and breaks dtrace
>
> David
>
>> Cheers, Richard.
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Freitag, 28. April 2017 15:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; David Holmes
>> <david.holmes at oracle.com>; 'build-dev at openjdk.java.net'
>> <build-dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com'
>> <magnus.ihse.bursie at oracle.com>
>> Cc: Simonis, Volker <volker.simonis at sap.com>; Reingruber, Richard
>> <richard.reingruber at sap.com>
>> Subject: Re: objcopy issues on Solaris
>>
>> Hello,
>>
>> In jdk8u we still have this workaround for broken gobjcopy in
>> NativeCompilation.gmk:
>>
>> # gobjcopy crashes on "empty" section headers with the SHF_ALLOC flag
>> set.
>> # Use $(FIX_EMPTY_SEC_HDR_FLAGS) to clear the SHF_ALLOC flag (if set)
>> from
>> # empty section headers until a fixed $(OBJCOPY) is available.
>> # An empty section header has sh_addr == 0 and sh_size == 0.
>> # This problem has only been seen on Solaris X64, but we call this tool
>> # on all Solaris builds just in case.
>> #
>> # $(OBJCOPY) --add-gnu-debuglink=... corrupts SUNW_* sections.
>> # Use $(ADD_GNU_DEBUGLINK) until a fixed $(OBJCOPY) is available.
>> $$($1_OBJECT_DIR)/$$(LIBRARY_PREFIX)$$($1_LIBRARY).debuginfo :
>> $$($1_TARGET) \
>>                  $(FIX_EMPTY_SEC_HDR_FLAGS) $(ADD_GNU_DEBUGLINK)
>>          $(RM) $$@
>>          $(FIX_EMPTY_SEC_HDR_FLAGS) $(LOG_INFO) $$<
>>          $(OBJCOPY) --only-keep-debug $$< $$@
>>          $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) $(LOG_INFO) $$(@F) $$<
>>
>> I don't know if this is related to your problem. We were able to remove
>> the above in JDK 9 because gobjcopy in Solaris 11 is not exhibiting this
>> problem for us. The introduction of this workaround is from before my
>> time so I don't know the details. The tools FIX_EMPTY_SEC_HDR_FLAGS and
>> ADD_GNU_DEBUGLINK are in the jdk8u src.
>>
>> I checked a build machine for jdk8u and it reports "GNU objcopy 2.15"
>> and this seems to be from the default OS package (Solaris 10). We have
>> had problems with bugs in gobjcopy in the past though. (Example
>> https://bugs.openjdk.java.net/browse/JDK-8034021) So try to get all the
>> latest patches for it.
>>
>> /Erik
>>
>> On 2017-04-28 14:20, Baesken, Matthias wrote:
>>>> GNU objcopy (GNU Binutils) 2.21.1
>>>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>>> This is a Solaris 11u1 package.
>>>
>>> Hi David, thanks for the info.
>>> But what about  Solaris 10 ?
>>>
>>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>>>
>>> mentions 10u6  supported for JDK8 .
>>>
>>> And  does  the  11u1 package
>>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>>    Contain special objcopy patches ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Freitag, 28. April 2017 13:24
>>> To: Baesken, Matthias <matthias.baesken at sap.com>;
>>> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; Erik
>>> Joelsson (erik.joelsson at oracle.com) <erik.joelsson at oracle.com>;
>>> 'magnus.ihse.bursie at oracle.com' <magnus.ihse.bursie at oracle.com>
>>> Cc: Simonis, Volker <volker.simonis at sap.com>; Reingruber, Richard
>>> <richard.reingruber at sap.com>
>>> Subject: Re: objcopy issues on Solaris
>>>
>>> Hi Matthias,
>>>
>>> On 28/04/2017 7:21 PM, Baesken, Matthias wrote:
>>>> Hello, we are facing problems with gobjcopy on Solaris 10 x86_64.
>>>> When processing libjvm.so (product build) with FDS and separated
>>>> debug-infos we are getting :
>>>>
>>>> objcopy: libjvm.debuginfo: Not enough room for program headers, try
>>>> linking with -N
>>>>
>>>> It looks like we are running into this (or a similar) problems :
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-7165598
>>>>
>>>> As recommended in those bugs :
>>>>
>>>>    x86
>>>>    https://bugs.openjdk.java.net/browse/JDK-8034005
>>>>
>>>>    (and similar Sparc issue)
>>>>    https://bugs.openjdk.java.net/browse/JDK-8033602
>>>>
>>>> We are using objcopy from binutils-2.28 (downloaded and built
>>>> ourselves from standard binutils gnu.org page)
>>>> and still get the mentioned error.
>>>>
>>>> In the OpenJDK version checks, 2.21 seems to be needed minimum,
>>>> the comments in version check says "objcopy prior to 2.21.1 on
>>>> solaris is broken and is not usable.".
>>>>
>>>> Could you tell us the exact version of  objcopy / gobjcopy  you are
>>>> using in 8 and 9 on Solaris  to
>>>> process the debuginfo ?
>>>> And where do you get the gobjcopy from?
>>> GNU objcopy (GNU Binutils) 2.21.1
>>>
>>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>>
>>> This is a Solaris 11u1 package.
>>>
>>> David
>>> -----
>>>
>>>> Thanks, Richard and Matthias
>>>>
>>


From erik.joelsson at oracle.com  Tue May  2 18:32:12 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 2 May 2017 20:32:12 +0200
Subject: RFR: JDK-8179453 Add a proper SetupProcessMarkdown
In-Reply-To: <04db6bd8-3141-5b06-3391-b4e90641c013@oracle.com>
References: <04db6bd8-3141-5b06-3391-b4e90641c013@oracle.com>
Message-ID: <4fbf498c-2481-ddb8-9949-ea4db5628d6a@oracle.com>

Hello,

Looks good. For efficiency reasons, I would recommend the following change:

Assign $1_$2_OPTIONS using just = for lazy evaluation so that we only do 
the shell call if executing the recipe. Also remove it from VARDEPS 
because the contents of OPTIONS only depends on the source file anyway 
and the rule already depends on the source file.

/Erik


On 2017-04-28 21:52, Magnus Ihse Bursie wrote:
> To cover the coming needs of the added markdown specifications, a more 
> proper function for setting up markdown processing is needed.
>
> The CSS file is intented as a first approach/placeholder. It needs to 
> be updated later on.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179453
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179453-add-process-markdown/webrev.01
>
> /Magnus



From list at xenhideout.nl  Tue May  2 21:09:49 2017
From: list at xenhideout.nl (Xen)
Date: Tue, 02 May 2017 23:09:49 +0200
Subject: getting toolchain to be used
Message-ID: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>

I understand that the build environment has changed since 1.7 but I am 
trying to build 1.7 for an older Synology device.

I first succeeded in building it using OE but since the compiler and/or 
libc used was too high for the platform I am now trying to do it using 
the platform's toolchain.

Unfortunately it seems it is using my own host g++ instead of the 
toolchain g++ when it ought to be using that one.

I have copied many options from those used by OE. The biggest difference 
is that I am either using an older toolchain or I am not using -e.

But when currently I use -e it fails immediately due to probably some 
variables being unset.

What is the best way to ensure it is using my proper toolchain?

here are some of the values I have defined:

export ALT_OBJCOPY=${TOOLDIR}/${prefix}objcopy
export ALT_STRIP=${TOOLDIR}/${prefix}strip
export ALT_CPP=${TOOLDIR}/${prefix}cpp
export ALT_GCC="${TOOLDIR}/${prefix}gcc -march=armv5e -marm 
--sysroot=$SYSROOT"
export ALT_LD="$ALT_GCC"
export ALT_CXX="${TOOLDIR}/${prefix}g++ -march=armv5e -marm 
--sysroot=$SYSROOT"
export ALT_CPP_FLAGS=-lstdc++
export ALT_CXX_FLAGS=-lstdc++
export BUILD_CC="$ALT_GCC"
export BUILD_LD="$ALT_GCC"
export BUILD_GCC="$ALT_GCC"
export BUILD_CXX="$ALT_CXX"
export HOST_CC=gcc
export CC_FOR_BUILD=$HOST_CC

with TOOLDIR being something like arm-none-linux-gnueabi/bin
and prefix being arm-none-linux-gnueabi-

The point is that it first gives some hpp errors with ints not being 
long ints, and then later an error referencing a crt1.o file on my main 
system.

which clearly indicates that my main g++ is being used.

I am using the same bootstrap as OE, which is 1.6.0.

I am not using the same PATH although that wouldn't matter in this sense 
I believe.

This is because the "hosttools" are also in the path, just last.

And their directory of "native" tools doesn't contain any compilers.

So everything seems to be quite equivalent.

I added variables CC and CCC and CXX to that list now...

Now it does do something different! And appears to halt on conversion 
errors (float to double, int to long, int to float, ...)

and I can't get it to honour any compiler flags...

Well with these changed CC/CCC/CXX values it just outputs more warnings, 
ultimately I got the same errors, I fixed the first ones, now I get 
again.

I used the wrong LD...

But it's still not using my own g++. Help?


From erik.joelsson at oracle.com  Tue May  2 22:00:46 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 2 May 2017 15:00:46 -0700
Subject: RFR: JDK-8179438: Incremental builds broken on Windows
Message-ID: <a8589243-8d16-bb77-030c-65444571edf7@oracle.com>

This is the same fix as I already din in JDK 10 in JDK-8179079. The 
problem was annoying enough that we need it fixed in 9 too. The patch is 
exactly the same.

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

diff -r 143d4c87bc1e make/common/NativeCompilation.gmk
--- a/make/common/NativeCompilation.gmk Fri Apr 28 15:40:49 2017 +0200
+++ b/make/common/NativeCompilation.gmk Tue May 02 23:54:24 2017 +0200
@@ -165,6 +165,7 @@
  WINDOWS_SHOWINCLUDE_SED_PATTERN := \
      -e '/^Note: including file:/!d' \
      -e 's|Note: including file: *||' \
+    -e 's|\r||g' \
      -e 's|\\|/|g' \
      -e 's|^\([a-zA-Z]\):|$(UNIX_PATH_PREFIX)/\1|g' \
      -e '\|$(TOPDIR)|I !d' \



From tim.bell at oracle.com  Tue May  2 22:37:49 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 02 May 2017 15:37:49 -0700
Subject: RFR: JDK-8179438: Incremental builds broken on Windows
In-Reply-To: <a8589243-8d16-bb77-030c-65444571edf7@oracle.com>
References: <a8589243-8d16-bb77-030c-65444571edf7@oracle.com>
Message-ID: <59090A3D.8090405@oracle.com>

Erik:

> This is the same fix as I already din in JDK 10 in JDK-8179079. The
> problem was annoying enough that we need it fixed in 9 too. The patch is
> exactly the same.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179438
>
> diff -r 143d4c87bc1e make/common/NativeCompilation.gmk
> --- a/make/common/NativeCompilation.gmk Fri Apr 28 15:40:49 2017 +0200
> +++ b/make/common/NativeCompilation.gmk Tue May 02 23:54:24 2017 +0200
> @@ -165,6 +165,7 @@
>   WINDOWS_SHOWINCLUDE_SED_PATTERN := \
>       -e '/^Note: including file:/!d' \
>       -e 's|Note: including file: *||' \
> +    -e 's|\r||g' \
>       -e 's|\\|/|g' \
>       -e 's|^\([a-zA-Z]\):|$(UNIX_PATH_PREFIX)/\1|g' \
>       -e '\|$(TOPDIR)|I !d' \

Looks good.  Approved.

Tim



From david.holmes at oracle.com  Wed May  3 04:07:11 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 3 May 2017 14:07:11 +1000
Subject: getting toolchain to be used
In-Reply-To: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
References: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
Message-ID: <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>

Hi Xen,

On 3/05/2017 7:09 AM, Xen wrote:
> I understand that the build environment has changed since 1.7 but I am
> trying to build 1.7 for an older Synology device.

The info below indicates you are trying to build for ARMv5. There is no 
native build for ARMv5 so I assume you are trying to cross-compile

For cross compilation you should need to set the following only:

ARCH arm
ALT_COMPILER_PATH <path to your toolchain>
ALT_OPENWIN_HOME <path to X11R6 in your toolchain>
CROSS_COMPILE_ARCH arm
EXTRA_CFLAGS  <this is where you set things like -march=armv5e -marm>

the local toolchain will be used for things that need to be compiled and 
executed locally as part of the build. HOST_CC should take care of that.

> I first succeeded in building it using OE but since the compiler and/or

Out of curiosity what is OE?

David
-----

> libc used was too high for the platform I am now trying to do it using
> the platform's toolchain.
>
> Unfortunately it seems it is using my own host g++ instead of the
> toolchain g++ when it ought to be using that one.
>
> I have copied many options from those used by OE. The biggest difference
> is that I am either using an older toolchain or I am not using -e.
>
> But when currently I use -e it fails immediately due to probably some
> variables being unset.
>
> What is the best way to ensure it is using my proper toolchain?
>
> here are some of the values I have defined:
>
> export ALT_OBJCOPY=${TOOLDIR}/${prefix}objcopy
> export ALT_STRIP=${TOOLDIR}/${prefix}strip
> export ALT_CPP=${TOOLDIR}/${prefix}cpp
> export ALT_GCC="${TOOLDIR}/${prefix}gcc -march=armv5e -marm
> --sysroot=$SYSROOT"
> export ALT_LD="$ALT_GCC"
> export ALT_CXX="${TOOLDIR}/${prefix}g++ -march=armv5e -marm
> --sysroot=$SYSROOT"
> export ALT_CPP_FLAGS=-lstdc++
> export ALT_CXX_FLAGS=-lstdc++
> export BUILD_CC="$ALT_GCC"
> export BUILD_LD="$ALT_GCC"
> export BUILD_GCC="$ALT_GCC"
> export BUILD_CXX="$ALT_CXX"
> export HOST_CC=gcc
> export CC_FOR_BUILD=$HOST_CC
>
> with TOOLDIR being something like arm-none-linux-gnueabi/bin
> and prefix being arm-none-linux-gnueabi-
>
> The point is that it first gives some hpp errors with ints not being
> long ints, and then later an error referencing a crt1.o file on my main
> system.
>
> which clearly indicates that my main g++ is being used.
>
> I am using the same bootstrap as OE, which is 1.6.0.
>
> I am not using the same PATH although that wouldn't matter in this sense
> I believe.
>
> This is because the "hosttools" are also in the path, just last.
>
> And their directory of "native" tools doesn't contain any compilers.
>
> So everything seems to be quite equivalent.
>
> I added variables CC and CCC and CXX to that list now...
>
> Now it does do something different! And appears to halt on conversion
> errors (float to double, int to long, int to float, ...)
>
> and I can't get it to honour any compiler flags...
>
> Well with these changed CC/CCC/CXX values it just outputs more warnings,
> ultimately I got the same errors, I fixed the first ones, now I get again.
>
> I used the wrong LD...
>
> But it's still not using my own g++. Help?


From magnus.ihse.bursie at oracle.com  Wed May  3 07:01:40 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 3 May 2017 09:01:40 +0200
Subject: RFR: JDK-8179453 Add a proper SetupProcessMarkdown
In-Reply-To: <4fbf498c-2481-ddb8-9949-ea4db5628d6a@oracle.com>
References: <04db6bd8-3141-5b06-3391-b4e90641c013@oracle.com>
 <4fbf498c-2481-ddb8-9949-ea4db5628d6a@oracle.com>
Message-ID: <a250ea97-3dd5-5d87-2882-d537c3e2204f@oracle.com>

On 2017-05-02 20:32, Erik Joelsson wrote:
> Hello,
>
> Looks good. For efficiency reasons, I would recommend the following 
> change:
>
> Assign $1_$2_OPTIONS using just = for lazy evaluation so that we only 
> do the shell call if executing the recipe. Also remove it from VARDEPS 
> because the contents of OPTIONS only depends on the source file anyway 
> and the rule already depends on the source file.
Good point. I fixed it like that.

/Magnus
>
> /Erik
>
>
> On 2017-04-28 21:52, Magnus Ihse Bursie wrote:
>> To cover the coming needs of the added markdown specifications, a 
>> more proper function for setting up markdown processing is needed.
>>
>> The CSS file is intented as a first approach/placeholder. It needs to 
>> be updated later on.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179453
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8179453-add-process-markdown/webrev.01
>>
>> /Magnus
>



From magnus.ihse.bursie at oracle.com  Wed May  3 07:02:08 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 3 May 2017 09:02:08 +0200
Subject: RFR: JDK-8179438: Incremental builds broken on Windows
In-Reply-To: <a8589243-8d16-bb77-030c-65444571edf7@oracle.com>
References: <a8589243-8d16-bb77-030c-65444571edf7@oracle.com>
Message-ID: <722c9038-f20c-48d0-7958-90552c345aae@oracle.com>

On 2017-05-03 00:00, Erik Joelsson wrote:
> This is the same fix as I already din in JDK 10 in JDK-8179079. The 
> problem was annoying enough that we need it fixed in 9 too. The patch 
> is exactly the same.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179438
>
> diff -r 143d4c87bc1e make/common/NativeCompilation.gmk
> --- a/make/common/NativeCompilation.gmk Fri Apr 28 15:40:49 2017 +0200
> +++ b/make/common/NativeCompilation.gmk Tue May 02 23:54:24 2017 +0200
> @@ -165,6 +165,7 @@
>  WINDOWS_SHOWINCLUDE_SED_PATTERN := \
>      -e '/^Note: including file:/!d' \
>      -e 's|Note: including file: *||' \
> +    -e 's|\r||g' \
>      -e 's|\\|/|g' \
>      -e 's|^\([a-zA-Z]\):|$(UNIX_PATH_PREFIX)/\1|g' \
>      -e '\|$(TOPDIR)|I !d' \
>

Looks good to me.

/Magnus


From lenborje at gmail.com  Wed May  3 08:52:22 2017
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Wed, 3 May 2017 10:52:22 +0200
Subject: Graal missing from MacOS Java 9 EA download b167
Message-ID: <6CF09D22-D5CC-4459-94BA-65C709523E5B@gmail.com>

Graal (e.g. the module jdk.internal.vm.compiler) seems to be missing from the Java 9 Early-Access download for MacOS. I noticed this with b166 and it is still so in b167.
 
As it is perfectly possible (I?ve done it) to download the source, configure the build to include graal, and build it, I suspect this is possibly an oversight in the packaging of the EA on MacOS, due to that AOT is only to be supported on Linux. But graal per se should surely be included on all platforms?
 
How to test:

Download and install Java 9 EA. Put it on the PATH.
 
java --list-modules | grep jdk.internal.vm.compiler
 
(finds compiler on Linux; finds nothing on MacOS)

 
java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version
 
(Works on Linux; complains about "no JVMCI compiler selected" on MacOS)

From magnus.ihse.bursie at oracle.com  Wed May  3 14:02:22 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 3 May 2017 16:02:22 +0200
Subject: RFR: JDK-8179556 Add specs copyright file
Message-ID: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>

The new $module/specs specifications needs to point to a proper 
copyright file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01

/Magnus



From magnus.ihse.bursie at oracle.com  Wed May  3 14:08:07 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 3 May 2017 16:08:07 +0200
Subject: RFR: JDK-8179557 Update generated Javadoc footer documentation link
Message-ID: <fbaf93ac-7e2b-8e2d-a0c6-45fc129a7b54@oracle.com>

Update the JDK Javadoc footer link from [1] to [2].

[1] http://docs.oracle.com/javase/9/docs/index.html

[2] http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=homepage

Bug: https://bugs.openjdk.java.net/browse/JDK-8179557
Patch inline:
diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk
--- a/make/Javadoc.gmk
+++ b/make/Javadoc.gmk
@@ -52,7 +52,7 @@
  DOCROOTPARENT_FLAG ?= TRUE

  # URLs
-JAVADOC_BASE_URL := 
http://docs.oracle.com/javase/$(VERSION_SPECIFICATION)/docs
+JAVADOC_BASE_URL := 
http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=homepage
  BUG_SUBMIT_URL := http://bugreport.java.com/bugreport/
  COPYRIGHT_URL := {@docroot}/../legal/cpyr.html

/Magnus


From erik.joelsson at oracle.com  Wed May  3 15:49:55 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 3 May 2017 08:49:55 -0700
Subject: RFR: JDK-8179556 Add specs copyright file
In-Reply-To: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
References: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
Message-ID: <5c9b879a-bd10-94b6-16a1-9a6a643f0b40@oracle.com>

Looks good.

/Erik


On 2017-05-03 07:02, Magnus Ihse Bursie wrote:
> The new $module/specs specifications needs to point to a proper 
> copyright file.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01
>
> /Magnus
>



From erik.joelsson at oracle.com  Wed May  3 15:50:42 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 3 May 2017 08:50:42 -0700
Subject: RFR: JDK-8179557 Update generated Javadoc footer documentation
 link
In-Reply-To: <fbaf93ac-7e2b-8e2d-a0c6-45fc129a7b54@oracle.com>
References: <fbaf93ac-7e2b-8e2d-a0c6-45fc129a7b54@oracle.com>
Message-ID: <87a569fd-d603-15f4-fd2b-49bef7785d9c@oracle.com>

Looks good.

/Erik


On 2017-05-03 07:08, Magnus Ihse Bursie wrote:
> Update the JDK Javadoc footer link from [1] to [2].
>
> [1] http://docs.oracle.com/javase/9/docs/index.html
>
> [2] http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=homepage
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179557
> Patch inline:
> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk
> --- a/make/Javadoc.gmk
> +++ b/make/Javadoc.gmk
> @@ -52,7 +52,7 @@
>  DOCROOTPARENT_FLAG ?= TRUE
>
>  # URLs
> -JAVADOC_BASE_URL := 
> http://docs.oracle.com/javase/$(VERSION_SPECIFICATION)/docs
> +JAVADOC_BASE_URL := 
> http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=homepage
>  BUG_SUBMIT_URL := http://bugreport.java.com/bugreport/
>  COPYRIGHT_URL := {@docroot}/../legal/cpyr.html
>
> /Magnus



From list at xenhideout.nl  Wed May  3 16:36:41 2017
From: list at xenhideout.nl (Xen)
Date: Wed, 03 May 2017 18:36:41 +0200
Subject: getting toolchain to be used
In-Reply-To: <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
References: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
 <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
Message-ID: <80f3808e0c2694e87439f2961cc50df9@xenhideout.nl>

David Holmes schreef op 03-05-2017 6:07:

> ARCH arm
> ALT_COMPILER_PATH <path to your toolchain>
> ALT_OPENWIN_HOME <path to X11R6 in your toolchain>
> CROSS_COMPILE_ARCH arm
> EXTRA_CFLAGS  <this is where you set things like -march=armv5e -marm>

In the forest of options, I actually forgot some of those :p.

I am trying to compile headless though.

> the local toolchain will be used for things that need to be compiled
> and executed locally as part of the build. HOST_CC should take care of
> that.

Does the ALT_COMPILER_PATH needs access to regular files like "gcc"? The 
toolchains of course all have "arm-linux-gnueabi-gcc" style paths.

I can create a directory with symlinked versions, actually I already 
had.

I took the toolchain from Ubuntu 14.04, since it is the last to have a 
glibc version (for arm) that will run on kernel 2.6.32. Not ideal 
perhaps but the older one available is for 12.04, and haven't tested 
that one yet.

Now it compiled a long time until it got a problem with a host tool.

./mkbc: 1: ./mkbc: Syntax error: word unexpected (expecting ")")

Which is a bit peculiar, but I expect it to be cause by improper setup? 
We will soon find out :) :p.

I really don't know how ALT_COMPILER_PATH would magically allow it to 
find a compiler like /usr/bin/arm-linux-gnueabi-g++-4.7, so I will go 
ahead and symlink it anyway.

Some of these files are also sitting in /usr/arm-linux-genueabi and even 
though they are identical... Euhm, yep, they are hardlinked :p.

Well everything seems to be fine but I still have the same error:

/toolchaindir/bin/g++ <long command> - < 
/openjdk-7-jre/99b00-2.6.5-r6.1/icedtea-2.6.5/build/openjdk/hotspot/src/cpu/zero/vm/bytecodes_arm.def 
|  ./mkbc - bytecodes_arm.s

./mkbc: 1: ./mkbc: Syntax error: word unexpected (expecting ")")

Yup I am still using the IcedTea distribution. Not sure if that would 
botch things up.

Well downloading openjdk-7 update 131 now to see if it makes a 
difference.

So there we go.

:).

It can't find the header <new>! That is so weird.

It includes -I/usr/arm-linux-gnueabi/include
in /usr/arm-linux-gnueabi/include/c++/4.7.3/ there is the file "new".

And yet it doesn't find it. Oops, my mistake. Then it needs another 
header, this time from 
/usr/arm-linux-gnueabi/include/c++/4.7.3/arm-linux-gnueabi,

is this thing going to require an include for every header location? 
Lol.

I guess they did that this way to separate armel from armhf.

Next up is a "mcp" variable reference in

/openjdk-7-u131/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp at line 
37 that is nowhere else in the file.

So I downgraded to u101 and it went on, but now it cannot link libjvm.so 
because a symlink to it already exists :/.

     rm -f libjvm.so.1; ln -s libjvm.so libjvm.so.1;
     [ -f libjvm.so ] || { ln -s libjvm.so libjvm.so; ln -s libjvm.so.1 
libjvm.so.1; };

It's definitely missing a directory somewhere.

>> I first succeeded in building it using OE but since the compiler 
>> and/or
> 
> Out of curiosity what is OE?

Oh sorry, I thought it would be something standard. OpenEmbedded.


From mandy.chung at oracle.com  Wed May  3 17:37:03 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 3 May 2017 10:37:03 -0700
Subject: RFR: JDK-8179556 Add specs copyright file
In-Reply-To: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
References: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
Message-ID: <C9768D7A-BFC1-4D63-AAAA-D6A1F30CEBD2@oracle.com>

Looks good.

Mandy

> On May 3, 2017, at 7:02 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> The new $module/specs specifications needs to point to a proper copyright file.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01
> 
> /Magnus
> 



From list at xenhideout.nl  Wed May  3 21:31:17 2017
From: list at xenhideout.nl (Xen)
Date: Wed, 03 May 2017 23:31:17 +0200
Subject: getting toolchain to be used
In-Reply-To: <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
References: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
 <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
Message-ID: <98fa642e5aeb1bfccf0e655a874d9c30@xenhideout.nl>

David Holmes schreef op 03-05-2017 6:07:

> For cross compilation you should need to set the following only:

So basically I know have a working HotSpot build for u101 but u131 and 
u121 fail because a single cpp file references a variable that doesn't 
exist anywhere in the source code. I know it means "MutableCallSite" 
because it is referenced in java code but there is no other cpp or hpp 
file that actually uses it.

Not that name of variable at least.

And u101 refuses to create the final executable correctly, I mean the 
final liblvm.so.

So next up is u111b01 :p.

111b01 succeeds in building but again cannot create the liblvm.so

So I had to add "rm -f $@; \" to the vm.make file and then I needed to 
add -Xlinker -rpath=directory to my EXTRA_CFLAGS.

For linking against libffi.so.6

And now the hotspot concluded :p.

Within seconds it ran into another library not found error this time 
libjvm.so that it just created.

Am I doing something wrong with the directories?

In the makefile $@ expanded to libjvm.so and LIBJVM_G also expanded to 
that, when clearly they were intended to be separate

I think I told it only to build a client vm but my target build dir 
/lib/arm/client does not exist; is empty.

That server jvm is 121 MB :O. Is that because of debug information?

Okay, for some reason before it required -Xlinker -rpath and now it 
requires -L...

Now it tries to add a copyright date notice to a small header file and 
then add to it using build/tmp/java/java.nio/nio/genSocketOptionRegistry 
but this program fails, saying:

Syntax error: word unexpected (expecting ")")


The problem is that it is trying to run an ARM executable on my build 
host :).

:P.

This is going to take fundamentally forever, if I keep this up.

So the makefile was not correct, it only used HOST_CC in case of MacOS 
platform.

I am going to apply those IcedTea patches I think....

Now it uses the wrong AS.

My mistake, gcc actually uses the path to find an as that matches it, 
which doesn't work in my case since I have overridden it. Proceeding 
again.

So I fixed the previous thing wrong and got a java compile error because 
the file ended up empty after using the default "CC" CCFLAGS, obviously 
that doesn't work so well when using HOST_CC.

Fixed again, now at last I get a normal error: libasound is not there 
yet :p.

The errors that are supposed to happen.

Thankful errors :p.

Omg I should never have attempted this.

But anyway with libasound compiled I am further ahead again.

Now my biggest question: how can I create a true headless mode?


DO I need X11 headers pers?? Can I just skip X11 compilation and awt 
compilation?

Please? :P.



Regards.


From david.holmes at oracle.com  Thu May  4 02:20:10 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 May 2017 12:20:10 +1000
Subject: getting toolchain to be used
In-Reply-To: <98fa642e5aeb1bfccf0e655a874d9c30@xenhideout.nl>
References: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
 <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
 <98fa642e5aeb1bfccf0e655a874d9c30@xenhideout.nl>
Message-ID: <e1a453f9-8e10-c8e3-4f79-57ebe536f6e4@oracle.com>

Hi Xen,

Quite the adventure.

Note that the options I suggested were all you should need, not options 
you need in addition to what you had attempted. And yes you need the 
symlinks to the simple names - gcc etc.

You are building something that was never provided by the OpenJDK. There 
is no ARM version of OpenJDK in 7, or 8. There is an Oracle JDK version 
for ARM in 7 but that was for Java SE Embedded. So while I can provide 
the basic information I did about how we use cross-compilation to build 
for ARM it may be incomplete in your environment. You really should be 
talking to the IcedTea folk.

You can try setting BUILD_HEADLESS_ONLY=true to avoid the need for an 
X11 headers etc but again I don't know if that will work for you. 
Generally even a headless JRE has to build in a headful environment.

David

On 4/05/2017 7:31 AM, Xen wrote:
> David Holmes schreef op 03-05-2017 6:07:
>
>> For cross compilation you should need to set the following only:
>
> So basically I know have a working HotSpot build for u101 but u131 and
> u121 fail because a single cpp file references a variable that doesn't
> exist anywhere in the source code. I know it means "MutableCallSite"
> because it is referenced in java code but there is no other cpp or hpp
> file that actually uses it.
>
> Not that name of variable at least.
>
> And u101 refuses to create the final executable correctly, I mean the
> final liblvm.so.
>
> So next up is u111b01 :p.
>
> 111b01 succeeds in building but again cannot create the liblvm.so
>
> So I had to add "rm -f $@; \" to the vm.make file and then I needed to
> add -Xlinker -rpath=directory to my EXTRA_CFLAGS.
>
> For linking against libffi.so.6
>
> And now the hotspot concluded :p.
>
> Within seconds it ran into another library not found error this time
> libjvm.so that it just created.
>
> Am I doing something wrong with the directories?
>
> In the makefile $@ expanded to libjvm.so and LIBJVM_G also expanded to
> that, when clearly they were intended to be separate
>
> I think I told it only to build a client vm but my target build dir
> /lib/arm/client does not exist; is empty.
>
> That server jvm is 121 MB :O. Is that because of debug information?
>
> Okay, for some reason before it required -Xlinker -rpath and now it
> requires -L...
>
> Now it tries to add a copyright date notice to a small header file and
> then add to it using build/tmp/java/java.nio/nio/genSocketOptionRegistry
> but this program fails, saying:
>
> Syntax error: word unexpected (expecting ")")
>
>
> The problem is that it is trying to run an ARM executable on my build
> host :).
>
> :P.
>
> This is going to take fundamentally forever, if I keep this up.
>
> So the makefile was not correct, it only used HOST_CC in case of MacOS
> platform.
>
> I am going to apply those IcedTea patches I think....
>
> Now it uses the wrong AS.
>
> My mistake, gcc actually uses the path to find an as that matches it,
> which doesn't work in my case since I have overridden it. Proceeding again.
>
> So I fixed the previous thing wrong and got a java compile error because
> the file ended up empty after using the default "CC" CCFLAGS, obviously
> that doesn't work so well when using HOST_CC.
>
> Fixed again, now at last I get a normal error: libasound is not there
> yet :p.
>
> The errors that are supposed to happen.
>
> Thankful errors :p.
>
> Omg I should never have attempted this.
>
> But anyway with libasound compiled I am further ahead again.
>
> Now my biggest question: how can I create a true headless mode?
>
>
> DO I need X11 headers pers?? Can I just skip X11 compilation and awt
> compilation?
>
> Please? :P.
>
>
>
> Regards.


From list at xenhideout.nl  Thu May  4 06:38:56 2017
From: list at xenhideout.nl (Xen)
Date: Thu, 04 May 2017 08:38:56 +0200
Subject: getting toolchain to be used
In-Reply-To: <e1a453f9-8e10-c8e3-4f79-57ebe536f6e4@oracle.com>
References: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
 <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
 <98fa642e5aeb1bfccf0e655a874d9c30@xenhideout.nl>
 <e1a453f9-8e10-c8e3-4f79-57ebe536f6e4@oracle.com>
Message-ID: <ff9fcd4a5d11a0f7ae81777f37043dc9@xenhideout.nl>

David Holmes schreef op 04-05-2017 4:20:
> Hi Xen,
> 
> Quite the adventure.
> 
> Note that the options I suggested were all you should need, not
> options you need in addition to what you had attempted. And yes you
> need the symlinks to the simple names - gcc etc.
> 
> You are building something that was never provided by the OpenJDK.
> There is no ARM version of OpenJDK in 7, or 8. There is an Oracle JDK
> version for ARM in 7 but that was for Java SE Embedded. So while I can
> provide the basic information I did about how we use cross-compilation
> to build for ARM it may be incomplete in your environment. You really
> should be talking to the IcedTea folk.
> 
> You can try setting BUILD_HEADLESS_ONLY=true to avoid the need for an
> X11 headers etc but again I don't know if that will work for you.
> Generally even a headless JRE has to build in a headful environment.

Yes, some of the patches I found in the IcedTea directory where the same 
or similar as I had done :p. Notably the HOSTCC fix (they used 
CC_FOR_BUILD) and perhaps something else.

There was a patch for OpenEmbedded that would forego the need of X11 
headers, that I found, however upon trying it myself it didn't work at 
all.

You wrote somewhere else in 2012 that BUILD_HEADLESS_ONLY hardly works 
anymore; and that it would be better to use BUILD_HEADLESS instead.

So I just went ahead to try to get those X11 headers (and libs) to build 
against but this is quite a chore.

There are like a zillion individual small libraries just like the linux 
folk like to have 4k files in the filesystem max ;-).

I use a DESTDIR because I got errors while not using it, but then e.g. 
libxcl will use the pkgconfig of xcb-proto and search in the wrong 
location; -- can't they just put it in one package lol.

So you have to botch up the pkgconfig ...

Oh, I didn't notice, libX11 completed.

Apart from the fact that it installed in my own /usr/local...

;-).

LDFLAGS to the rescue I guess, and properly using it (DESTDIR).

As these things go, it now automatically compiles and installs 
xcb-proto, libXau, libxcb, libX11, libffi and libasound :p.

It's the search path not found errors that drive you insane though.

For every header it needs it checks the path I supplied.

Except for this one.

And why, because it opens a pkgconfig file and looks no further. So here 
I am, spending at least an hour trying to get one program to reference 
one file.

Such a good ... spending of time.

And then when it doesn't complain it's because it is actually loading 
the file from my main system...

So basically when I use a good prefix for my configurations other 
packages won't be able to find it because the pkgtool shows a relative 
link relative to sysroot, that they don't process.

Then, the .la files also have the full absolute path on my own system.

Then, the next library is going to actually process the .la paths based 
on a sysroot directive I give it, creating overly long, nonexistent 
paths.

So what I actually need to do is to botch up every pkgconfig file after 
the fact so that it works for this system for absolute paths, while the 
.la files are actually okay  for those who use sysroot.....

Now I am back with another library that is not found, and this pain just 
keeps repeating itself.

Sorry about this.













> 
> David
> 
> On 4/05/2017 7:31 AM, Xen wrote:
>> David Holmes schreef op 03-05-2017 6:07:
>> 
>>> For cross compilation you should need to set the following only:
>> 
>> So basically I know have a working HotSpot build for u101 but u131 and
>> u121 fail because a single cpp file references a variable that doesn't
>> exist anywhere in the source code. I know it means "MutableCallSite"
>> because it is referenced in java code but there is no other cpp or hpp
>> file that actually uses it.
>> 
>> Not that name of variable at least.
>> 
>> And u101 refuses to create the final executable correctly, I mean the
>> final liblvm.so.
>> 
>> So next up is u111b01 :p.
>> 
>> 111b01 succeeds in building but again cannot create the liblvm.so
>> 
>> So I had to add "rm -f $@; \" to the vm.make file and then I needed to
>> add -Xlinker -rpath=directory to my EXTRA_CFLAGS.
>> 
>> For linking against libffi.so.6
>> 
>> And now the hotspot concluded :p.
>> 
>> Within seconds it ran into another library not found error this time
>> libjvm.so that it just created.
>> 
>> Am I doing something wrong with the directories?
>> 
>> In the makefile $@ expanded to libjvm.so and LIBJVM_G also expanded to
>> that, when clearly they were intended to be separate
>> 
>> I think I told it only to build a client vm but my target build dir
>> /lib/arm/client does not exist; is empty.
>> 
>> That server jvm is 121 MB :O. Is that because of debug information?
>> 
>> Okay, for some reason before it required -Xlinker -rpath and now it
>> requires -L...
>> 
>> Now it tries to add a copyright date notice to a small header file and
>> then add to it using 
>> build/tmp/java/java.nio/nio/genSocketOptionRegistry
>> but this program fails, saying:
>> 
>> Syntax error: word unexpected (expecting ")")
>> 
>> 
>> The problem is that it is trying to run an ARM executable on my build
>> host :).
>> 
>> :P.
>> 
>> This is going to take fundamentally forever, if I keep this up.
>> 
>> So the makefile was not correct, it only used HOST_CC in case of MacOS
>> platform.
>> 
>> I am going to apply those IcedTea patches I think....
>> 
>> Now it uses the wrong AS.
>> 
>> My mistake, gcc actually uses the path to find an as that matches it,
>> which doesn't work in my case since I have overridden it. Proceeding 
>> again.
>> 
>> So I fixed the previous thing wrong and got a java compile error 
>> because
>> the file ended up empty after using the default "CC" CCFLAGS, 
>> obviously
>> that doesn't work so well when using HOST_CC.
>> 
>> Fixed again, now at last I get a normal error: libasound is not there
>> yet :p.
>> 
>> The errors that are supposed to happen.
>> 
>> Thankful errors :p.
>> 
>> Omg I should never have attempted this.
>> 
>> But anyway with libasound compiled I am further ahead again.
>> 
>> Now my biggest question: how can I create a true headless mode?
>> 
>> 
>> DO I need X11 headers pers?? Can I just skip X11 compilation and awt
>> compilation?
>> 
>> Please? :P.
>> 
>> 
>> 
>> Regards.


From david.holmes at oracle.com  Thu May  4 23:26:41 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 5 May 2017 09:26:41 +1000
Subject: build fail with Cygwin
In-Reply-To: <7260aba0fe13d.590b78b9@videotron.ca>
References: <001601d2c3ba$01ecdf80$05c69e80$@videotron.ca>
 <66P8dHt1OImXY66PAdZk5E@videotron.ca> <7240ff359cd2a.590a70d9@videotron.ca>
 <38de0531-a439-c3c6-b3f2-04383b87f9a0@oracle.com>
 <68rodIUfGImXY68rpdZuVY@videotron.ca> <7360fa67fb5e9.590b0fb9@videotron.ca>
 <73009032f8ed0.590ad780@videotron.ca> <6GAyd9UbpkBnL6GB0dZ5LH@videotron.ca>
 <7270dfc6fb19e.590b260c@videotron.ca> <7390a54bfb0c1.590b2648@videotron.ca>
 <7360c3d1ffacf.590b2686@videotron.ca> <73408fd4fcd22.590b26c3@videotron.ca>
 <6GR3dmPpyb0CV6GR6dnAGO@videotron.ca> <72f0f03ffa942.590b320d@videotron.ca>
 <7210aa1ef8898.590b324a@videotron.ca> <7270ba24ff6de.590b3287@videotron.ca>
 <7300cc01fd6aa.590afa65@videotron.ca> <6HNBdwInn3wDa6HNCdWQFb@videotron.ca>
 <71f090ac88147.590b582f@videotron.ca> <7390eff0fccfa.590b675d@videotron.ca>
 <72b0eedaff385.590b679a@videotron.ca> <7300d91ef8c5a.590b6813@videotron.ca>
 <7370b50efd605.590b2ff3@videotron.ca> <6MVddyCNY3wDa6MVedY5bX@videotron.ca>
 <7260aba0fe13d.590b78b9@videotron.ca>
Message-ID: <f0d81e2a-133a-0fef-11b8-f4511a8cdf38@oracle.com>

First - please edit subject so we stop getting Re: added ad-infinitum :)

Second - this is a general build issue relating to cygwin etc so I've 
cc'd build-dev and bcc'd jdk8-dev.

I suspect your version of cygwin may be too new for the 8u build. You 
should check out the build-dev archives over the last few weeks:

http://mail.openjdk.java.net/pipermail/build-dev/

David

On 5/05/2017 8:53 AM, Guy Bonneau wrote:
> No success with the change to the profile.
>
> Guy
>
> Le 04/05/17 ? 15:33, *Michal Vala * <mvala at redhat.com> a ?crit :
>>
>>
>> On 05/04/2017 07:43 PM, Guy Bonneau wrote:
>> >Good point!
>> >
>> >
>> >This is what I have found. The file _the.jars.contents is a text file
>> that has a list of classes. There is many hundred of them.
>> >The command: /usr/bin/grep -e '\.class$'
>> /cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.jars.contents
>> yields nothing. It is empty and create an empty
>> _the.rt.jar.contents.tmp file with nothing. I checked and it is indeed
>> a file size of 0 bytes.
>> >
>> >
>> >However the command /usr/bin/grep -e '\.class^M$'
>> /cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.jars.contents
>> yields all the classes.
>> >
>> >
>> >I checked with a binary editor the file: _the.jars.contents and all
>> the line ending are Windows style. Not Linux style. It seems the tool
>> invoked that creates the _the.jars.contents see Windows as the OS and
>> put Windows style EndOfLine. Then Grep pattern fails because it
>> searches for Linux-style EndOfLine.
>> >
>> >
>> >Note that my JDK which might be invoked to run Java outside of the
>> Cygwin folder installation might create Windows style EndOfLine. This
>> could be the issue.
>> >
>> >
>> >Thus my guessing is the script must be modified with a grep pattern
>> that can automatically extract the lines ending with .class with
>> either Linux or Windows style EndOfLine.
>> >
>> >
>> >If you can give me a quick fix I could try it.
>>
>> You may try to add this to your ~/.bash_profile in cygwin
>>
>> export SHELLOPTS
>> set -o ignc
>>
>>
>> >
>> >
>> >Thanks
>> >Guy
>> >
>> >
>> >
>> >
>> >Le 04/05/17 ? 10:04, Weijun Wang  <weijun.wang at oracle.com> a ?crit :
>> >>Looks like the exploded build succeeds and there is something wrong
>> with the image build.
>> >>
>> >>Can you try if the JDK inside
>> /cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/jdk
>> (i.e. the exploded build) works fine?
>> >>
>> >>The last few lines show
>> >>
>> >>/usr/bin/grep -e '\.class$'
>> /cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.jars.contents
>> >
>> /cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.rt.jar.contents.tmp
>> >>make[2]: *** [CreateJars.gmk:268:
>> /cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.rt.jar.contents]
>> Error 1
>> >>
>> >>Can you rerun that grep command and see if _the.rt.jar.contents.tmp
>> is empty?
>> >>
>> >>--Max
>> >>
>> >>On 05/04/2017 09:54 PM, Guy Bonneau wrote:
>> >>>I removed the JDK 8 and left the JDK 7 (1.7.0_80). No success same
>> error. I check the config log and saw some complaining about the JRE
>> 7, So I removed this one as well and left only the JDK 7 to be found.
>> No success and same error at the same place.
>> >>>
>> >>>Guy
>> >>>
>> >>>Le 04/05/17, Guy Bonneau <guy.bonneau at videotron.ca> a ?crit :
>> >>>>I have both oracle JDK 7 and JDK 8 installed on the default Java
>> installation folder of my computer (Need both of them while working
>> with Eclipse and miscellaneous project). I would have expected the
>> configuration script to automatically choose the JDK 7 rather than JDK
>> 8 as a Bootstrap. I'll uninstall Oracle JDK 8 and restart the build
>> and let you know.
>> >>>>
>> >>>>Thanks
>> >>>>Guy
>> >>>>
>> >>>>Le 04/05/17, David Holmes <david.holmes at oracle.com> a ?crit :
>> >>>>>On 4/05/2017 9:25 PM, Guy Bonneau wrote:
>> >>>>>>Did it. Both configuration and build logs are now shared at:
>> >>>>>>
>> >>>>>>https://www.dropbox.com/sh/6xbmjzxu8xlbsr0/AADBHa-Zn7owJpyeihlmej9pa?dl=0
>> >>>>>
>> >>
>> >>
>>
>> --
>> Michal Vala
>> OpenJDK QE
>> Red Hat Czech


From guy.bonneau at videotron.ca  Fri May  5 01:32:46 2017
From: guy.bonneau at videotron.ca (Guy Bonneau)
Date: Thu, 04 May 2017 21:32:46 -0400
Subject: build fail with Cygwin
In-Reply-To: <6Q95dO8HGBok76Q96dWjGf@videotron.ca>
References: <001601d2c3ba$01ecdf80$05c69e80$@videotron.ca>
 <66P8dHt1OImXY66PAdZk5E@videotron.ca>
 <7240ff359cd2a.590a70d9@videotron.ca>
 <38de0531-a439-c3c6-b3f2-04383b87f9a0@oracle.com>
 <68rodIUfGImXY68rpdZuVY@videotron.ca>
 <7360fa67fb5e9.590b0fb9@videotron.ca>
 <73009032f8ed0.590ad780@videotron.ca>
 <6GAyd9UbpkBnL6GB0dZ5LH@videotron.ca>
 <7270dfc6fb19e.590b260c@videotron.ca>
 <7390a54bfb0c1.590b2648@videotron.ca>
 <7360c3d1ffacf.590b2686@videotron.ca>
 <73408fd4fcd22.590b26c3@videotron.ca>
 <6GR3dmPpyb0CV6GR6dnAGO@videotron.ca>
 <72f0f03ffa942.590b320d@videotron.ca>
 <7210aa1ef8898.590b324a@videotron.ca>
 <7270ba24ff6de.590b3287@videotron.ca>
 <7300cc01fd6aa.590afa65@videotron.ca>
 <6HNBdwInn3wDa6HNCdWQFb@videotron.ca>
 <71f090ac88147.590b582f@videotron.ca>
 <7390eff0fccfa.590b675d@videotron.ca>
 <72b0eedaff385.590b679a@videotron.ca>
 <7300d91ef8c5a.590b6813@videotron.ca>
 <7370b50efd605.590b2ff3@videotron.ca>
 <6MVddyCNY3wDa6MVedY5bX@videotron.ca>
 <7260aba0fe13d.590b78b9@videotron.ca>
 <6Q95dO8HGBok76Q96dWjGf@videotron.ca>
Message-ID: <7290e27ff8df3.590b9dfe@videotron.ca>

I am now successful. I needed to switch from grep 3.02 to 2.27-2. That was the only issue with the latest Cygwin version.

2 others issues need some attention which might cause problems to newbies. The configuration doesn't set -disable-ccache?which is not supported by default on Windows. The other issue is multiple JDK version installed seems to confuse the configuration setup and a wrong JDK version might be picked up as the bootstrap JDK. I had both Oracle JDK 7 and JDK 8 installed and JDK 8 was chosen as the bootstrap JDK.

This being said thanks a lot everyone for your help. This is my first experience with the OpenJDK email list and I?was very pleased with the responsiveness of the developer. You are a great team. If you want me later to test the fixes just ping me.

Best regards
Guy Bonneau

Le 04/05/17 ? 19:26, David Holmes  <david.holmes at oracle.com> a ?crit :
> 
> First - please edit subject so we stop getting Re: added ad-infinitum :)
> 
> Second - this is a general build issue relating to cygwin etc so I've cc'd build-dev and bcc'd jdk8-dev.
> 
> I suspect your version of cygwin may be too new for the 8u build. You should check out the build-dev archives over the last few weeks:
> 
> http://mail.openjdk.java.net/pipermail/build-dev/
> 
> David
> 
> On 5/05/2017 8:53 AM, Guy Bonneau wrote:
> >No success with the change to the profile.
> >
> >Guy
> >
> >Le 04/05/17 ? 15:33, *Michal Vala * <mvala at redhat.com> a ?crit :
> >>
> >>
> >>On 05/04/2017 07:43 PM, Guy Bonneau wrote:
> >>>Good point!
> >>>
> >>>
> >>>This is what I have found. The file _the.jars.contents is a text file
> >>that has a list of classes. There is many hundred of them.
> >>>The command: /usr/bin/grep -e '\.class$'
> >>/cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.jars.contents
> >>yields nothing. It is empty and create an empty
> >>_the.rt.jar.contents.tmp file with nothing. I checked and it is indeed
> >>a file size of 0 bytes.
> >>>
> >>>
> >>>However the command /usr/bin/grep -e '\.class^M$'
> >>/cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.jars.contents
> >>yields all the classes.
> >>>
> >>>
> >>>I checked with a binary editor the file: _the.jars.contents and all
> >>the line ending are Windows style. Not Linux style. It seems the tool
> >>invoked that creates the _the.jars.contents see Windows as the OS and
> >>put Windows style EndOfLine. Then Grep pattern fails because it
> >>searches for Linux-style EndOfLine.
> >>>
> >>>
> >>>Note that my JDK which might be invoked to run Java outside of the
> >>Cygwin folder installation might create Windows style EndOfLine. This
> >>could be the issue.
> >>>
> >>>
> >>>Thus my guessing is the script must be modified with a grep pattern
> >>that can automatically extract the lines ending with .class with
> >>either Linux or Windows style EndOfLine.
> >>>
> >>>
> >>>If you can give me a quick fix I could try it.
> >>
> >>You may try to add this to your ~/.bash_profile in cygwin
> >>
> >>export SHELLOPTS
> >>set -o ignc
> >>
> >>
> >>>
> >>>
> >>>Thanks
> >>>Guy
> >>>
> >>>
> >>>
> >>>
> >>>Le 04/05/17 ? 10:04, Weijun Wang <weijun.wang at oracle.com> a ?crit :
> >>>>Looks like the exploded build succeeds and there is something wrong
> >>with the image build.
> >>>>
> >>>>Can you try if the JDK inside
> >>/cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/jdk
> >>(i.e. the exploded build) works fine?
> >>>>
> >>>>The last few lines show
> >>>>
> >>>>/usr/bin/grep -e '\.class$'
> >>/cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.jars.contents
> >>>
> >>/cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.rt.jar.contents.tmp
> >>>>make[2]: *** [CreateJars.gmk:268:
> >>/cygdrive/c/Projects/jdk-8/build/windows-x86_64-normal-server-fastdebug/images/lib/_the.rt.jar.contents]
> >>Error 1
> >>>>
> >>>>Can you rerun that grep command and see if _the.rt.jar.contents.tmp
> >>is empty?
> >>>>
> >>>>--Max
> >>>>
> >>>>On 05/04/2017 09:54 PM, Guy Bonneau wrote:
> >>>>>I removed the JDK 8 and left the JDK 7 (1.7.0_80). No success same
> >>error. I check the config log and saw some complaining about the JRE
> >>7, So I removed this one as well and left only the JDK 7 to be found.
> >>No success and same error at the same place.
> >>>>>
> >>>>>Guy
> >>>>>
> >>>>>Le 04/05/17, Guy Bonneau <guy.bonneau at videotron.ca> a ?crit :
> >>>>>>I have both oracle JDK 7 and JDK 8 installed on the default Java
> >>installation folder of my computer (Need both of them while working
> >>with Eclipse and miscellaneous project). I would have expected the
> >>configuration script to automatically choose the JDK 7 rather than JDK
> >>8 as a Bootstrap. I'll uninstall Oracle JDK 8 and restart the build
> >>and let you know.
> >>>>>>
> >>>>>>Thanks
> >>>>>>Guy
> >>>>>>
> >>>>>>Le 04/05/17, David Holmes <david.holmes at oracle.com> a ?crit :
> >>>>>>>On 4/05/2017 9:25 PM, Guy Bonneau wrote:
> >>>>>>>>Did it. Both configuration and build logs are now shared at:
> >>>>>>>>
> >>>>>>>>https://www.dropbox.com/sh/6xbmjzxu8xlbsr0/AADBHa-Zn7owJpyeihlmej9pa?dl=0
> >>>>>>>
> >>>>
> >>>>
> >>
> >>--
> >>Michal Vala
> >>OpenJDK QE
> >>Red Hat Czech
> 


From magnus.ihse.bursie at oracle.com  Fri May  5 13:17:11 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 5 May 2017 15:17:11 +0200
Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs
 directory
Message-ID: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>

The Security Standard Names document will be moved to a new location, so 
all links needs to be updated. Also, a minor fix to the build system was 
needed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8178278
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01

/Magnus



From magnus.ihse.bursie at oracle.com  Fri May  5 13:30:55 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 5 May 2017 15:30:55 +0200
Subject: RFR: JDK-8179692 Move RMI spec to specs directory
Message-ID: <80130257-2f60-9c2a-e324-8cb1f50e1c07@oracle.com>

The RMI spec will be moved to a new location, so all links needs to be 
updated.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179692
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8179692-rmi-spec-markdown/webrev.01

/Magnus



From magnus.ihse.bursie at oracle.com  Fri May  5 13:35:09 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 5 May 2017 15:35:09 +0200
Subject: RFR: JDK-8140268 Update link to license information in Javadoc
Message-ID: <577d0d4c-b9f7-8d65-b2fc-c735fa612c46@oracle.com>

The links to the Javadoc specification license needs to be updated for JDK9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8140268
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8140268-javadoc-license-link-footer/webrev.01

/Magnus



From magnus.ihse.bursie at oracle.com  Fri May  5 13:57:19 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 5 May 2017 15:57:19 +0200
Subject: RFR: JDK-8179658 SetupProcessMarkdown creates long file names
Message-ID: <d05b630c-58f0-72c3-f91b-abeb5fc44685@oracle.com>

When building with a root directory with a very deep level, the fix in 
JDK-8179658 can cause the build to fail.

The temporary files created use the entire path, which was never 
intended. This patch fixes that.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179658
Patch inline:
diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk
--- a/make/Javadoc.gmk
+++ b/make/Javadoc.gmk
@@ -390,14 +390,14 @@
      $(eval SPECS_$m := $(call FindModuleSpecsDirs, $m)) \
      $(foreach d, $(SPECS_$m), \
        $(if $(filter %.md, $(call CacheFind, $d)), \
-        $(eval $(call SetupProcessMarkdown, CONVERT_MARKDOWN_$m_$d, \
+        $(eval $(call SetupProcessMarkdown, 
CONVERT_MARKDOWN_$m_$(patsubst $(TOPDIR)/%,%,$d), \
              SRC := $d, \
              FILES := $(filter %.md, $(call CacheFind, $d)), \
              DEST := $(JAVADOC_OUTPUTDIR)/specs/, \
              CSS := $(GLOBAL_SPECS_DEFAULT_CSS_FILE), \
          )) \
        ) \
-      $(eval JDK_SPECS_TARGETS += $(CONVERT_MARKDOWN_$m_$d)) \
+      $(eval JDK_SPECS_TARGETS += $(CONVERT_MARKDOWN_$m_$(patsubst 
$(TOPDIR)/%,%,$d))) \
      ) \
    )
  endif

/Magnus



From magnus.ihse.bursie at oracle.com  Fri May  5 15:13:00 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 5 May 2017 17:13:00 +0200
Subject: getting toolchain to be used
In-Reply-To: <ff9fcd4a5d11a0f7ae81777f37043dc9@xenhideout.nl>
References: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
 <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
 <98fa642e5aeb1bfccf0e655a874d9c30@xenhideout.nl>
 <e1a453f9-8e10-c8e3-4f79-57ebe536f6e4@oracle.com>
 <ff9fcd4a5d11a0f7ae81777f37043dc9@xenhideout.nl>
Message-ID: <C3BAE196-2E57-453C-A8D6-0BB04D88E53B@oracle.com>

Xen,
Unless it's imperative for you that you build JDK 7, you might have more success with JDK 9. A lot have changed in the build system that may make it easier to build.

/Magnus

> 4 maj 2017 kl. 08:38 skrev Xen <list at xenhideout.nl>:
> 
> David Holmes schreef op 04-05-2017 4:20:
>> Hi Xen,
>> Quite the adventure.
>> Note that the options I suggested were all you should need, not
>> options you need in addition to what you had attempted. And yes you
>> need the symlinks to the simple names - gcc etc.
>> You are building something that was never provided by the OpenJDK.
>> There is no ARM version of OpenJDK in 7, or 8. There is an Oracle JDK
>> version for ARM in 7 but that was for Java SE Embedded. So while I can
>> provide the basic information I did about how we use cross-compilation
>> to build for ARM it may be incomplete in your environment. You really
>> should be talking to the IcedTea folk.
>> You can try setting BUILD_HEADLESS_ONLY=true to avoid the need for an
>> X11 headers etc but again I don't know if that will work for you.
>> Generally even a headless JRE has to build in a headful environment.
> 
> Yes, some of the patches I found in the IcedTea directory where the same or similar as I had done :p. Notably the HOSTCC fix (they used CC_FOR_BUILD) and perhaps something else.
> 
> There was a patch for OpenEmbedded that would forego the need of X11 headers, that I found, however upon trying it myself it didn't work at all.
> 
> You wrote somewhere else in 2012 that BUILD_HEADLESS_ONLY hardly works anymore; and that it would be better to use BUILD_HEADLESS instead.
> 
> So I just went ahead to try to get those X11 headers (and libs) to build against but this is quite a chore.
> 
> There are like a zillion individual small libraries just like the linux folk like to have 4k files in the filesystem max ;-).
> 
> I use a DESTDIR because I got errors while not using it, but then e.g. libxcl will use the pkgconfig of xcb-proto and search in the wrong location; -- can't they just put it in one package lol.
> 
> So you have to botch up the pkgconfig ...
> 
> Oh, I didn't notice, libX11 completed.
> 
> Apart from the fact that it installed in my own /usr/local...
> 
> ;-).
> 
> LDFLAGS to the rescue I guess, and properly using it (DESTDIR).
> 
> As these things go, it now automatically compiles and installs xcb-proto, libXau, libxcb, libX11, libffi and libasound :p.
> 
> It's the search path not found errors that drive you insane though.
> 
> For every header it needs it checks the path I supplied.
> 
> Except for this one.
> 
> And why, because it opens a pkgconfig file and looks no further. So here I am, spending at least an hour trying to get one program to reference one file.
> 
> Such a good ... spending of time.
> 
> And then when it doesn't complain it's because it is actually loading the file from my main system...
> 
> So basically when I use a good prefix for my configurations other packages won't be able to find it because the pkgtool shows a relative link relative to sysroot, that they don't process.
> 
> Then, the .la files also have the full absolute path on my own system.
> 
> Then, the next library is going to actually process the .la paths based on a sysroot directive I give it, creating overly long, nonexistent paths.
> 
> So what I actually need to do is to botch up every pkgconfig file after the fact so that it works for this system for absolute paths, while the .la files are actually okay  for those who use sysroot.....
> 
> Now I am back with another library that is not found, and this pain just keeps repeating itself.
> 
> Sorry about this.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> David
>>> On 4/05/2017 7:31 AM, Xen wrote:
>>> David Holmes schreef op 03-05-2017 6:07:
>>>> For cross compilation you should need to set the following only:
>>> So basically I know have a working HotSpot build for u101 but u131 and
>>> u121 fail because a single cpp file references a variable that doesn't
>>> exist anywhere in the source code. I know it means "MutableCallSite"
>>> because it is referenced in java code but there is no other cpp or hpp
>>> file that actually uses it.
>>> Not that name of variable at least.
>>> And u101 refuses to create the final executable correctly, I mean the
>>> final liblvm.so.
>>> So next up is u111b01 :p.
>>> 111b01 succeeds in building but again cannot create the liblvm.so
>>> So I had to add "rm -f $@; \" to the vm.make file and then I needed to
>>> add -Xlinker -rpath=directory to my EXTRA_CFLAGS.
>>> For linking against libffi.so.6
>>> And now the hotspot concluded :p.
>>> Within seconds it ran into another library not found error this time
>>> libjvm.so that it just created.
>>> Am I doing something wrong with the directories?
>>> In the makefile $@ expanded to libjvm.so and LIBJVM_G also expanded to
>>> that, when clearly they were intended to be separate
>>> I think I told it only to build a client vm but my target build dir
>>> /lib/arm/client does not exist; is empty.
>>> That server jvm is 121 MB :O. Is that because of debug information?
>>> Okay, for some reason before it required -Xlinker -rpath and now it
>>> requires -L...
>>> Now it tries to add a copyright date notice to a small header file and
>>> then add to it using build/tmp/java/java.nio/nio/genSocketOptionRegistry
>>> but this program fails, saying:
>>> Syntax error: word unexpected (expecting ")")
>>> The problem is that it is trying to run an ARM executable on my build
>>> host :).
>>> :P.
>>> This is going to take fundamentally forever, if I keep this up.
>>> So the makefile was not correct, it only used HOST_CC in case of MacOS
>>> platform.
>>> I am going to apply those IcedTea patches I think....
>>> Now it uses the wrong AS.
>>> My mistake, gcc actually uses the path to find an as that matches it,
>>> which doesn't work in my case since I have overridden it. Proceeding again.
>>> So I fixed the previous thing wrong and got a java compile error because
>>> the file ended up empty after using the default "CC" CCFLAGS, obviously
>>> that doesn't work so well when using HOST_CC.
>>> Fixed again, now at last I get a normal error: libasound is not there
>>> yet :p.
>>> The errors that are supposed to happen.
>>> Thankful errors :p.
>>> Omg I should never have attempted this.
>>> But anyway with libasound compiled I am further ahead again.
>>> Now my biggest question: how can I create a true headless mode?
>>> DO I need X11 headers pers?? Can I just skip X11 compilation and awt
>>> compilation?
>>> Please? :P.
>>> Regards.



From tim.bell at oracle.com  Fri May  5 15:29:19 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 05 May 2017 08:29:19 -0700
Subject: RFR: JDK-8179658 SetupProcessMarkdown creates long file names
In-Reply-To: <d05b630c-58f0-72c3-f91b-abeb5fc44685@oracle.com>
References: <d05b630c-58f0-72c3-f91b-abeb5fc44685@oracle.com>
Message-ID: <590C9A4F.4040308@oracle.com>

On 05/05/17 06:57, Magnus Ihse Bursie wrote:
> When building with a root directory with a very deep level, the fix in
> JDK-8179658 can cause the build to fail.
>
> The temporary files created use the entire path, which was never
> intended. This patch fixes that.

Looks good.  Thank you for the fix.

Tim


>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179658
> Patch inline:
> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk
> --- a/make/Javadoc.gmk
> +++ b/make/Javadoc.gmk
> @@ -390,14 +390,14 @@
>       $(eval SPECS_$m := $(call FindModuleSpecsDirs, $m)) \
>       $(foreach d, $(SPECS_$m), \
>         $(if $(filter %.md, $(call CacheFind, $d)), \
> -        $(eval $(call SetupProcessMarkdown, CONVERT_MARKDOWN_$m_$d, \
> +        $(eval $(call SetupProcessMarkdown,
> CONVERT_MARKDOWN_$m_$(patsubst $(TOPDIR)/%,%,$d), \
>               SRC := $d, \
>               FILES := $(filter %.md, $(call CacheFind, $d)), \
>               DEST := $(JAVADOC_OUTPUTDIR)/specs/, \
>               CSS := $(GLOBAL_SPECS_DEFAULT_CSS_FILE), \
>           )) \
>         ) \
> -      $(eval JDK_SPECS_TARGETS += $(CONVERT_MARKDOWN_$m_$d)) \
> +      $(eval JDK_SPECS_TARGETS += $(CONVERT_MARKDOWN_$m_$(patsubst
> $(TOPDIR)/%,%,$d))) \
>       ) \
>     )
>   endif
>
> /Magnus
>



From erik.joelsson at oracle.com  Fri May  5 15:52:48 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 5 May 2017 08:52:48 -0700
Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs
 directory
In-Reply-To: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
Message-ID: <9ca199f9-5b0f-e210-c068-90cd81353864@oracle.com>

What's the reason for adding the conditional around SetupCopyFiles in 
Javadoc.gmk? The SetupCopyFiles macro should be safe to call with an 
empty FILES list. It should evaluate to basically nothing in that case.

/Erik


On 2017-05-05 06:17, Magnus Ihse Bursie wrote:
> The Security Standard Names document will be moved to a new location, 
> so all links needs to be updated. Also, a minor fix to the build 
> system was needed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01
>
> /Magnus
>



From erik.joelsson at oracle.com  Fri May  5 15:53:44 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 5 May 2017 08:53:44 -0700
Subject: RFR: JDK-8179692 Move RMI spec to specs directory
In-Reply-To: <80130257-2f60-9c2a-e324-8cb1f50e1c07@oracle.com>
References: <80130257-2f60-9c2a-e324-8cb1f50e1c07@oracle.com>
Message-ID: <6d546a82-9ee5-f1ed-f0c6-ba3f650c9e67@oracle.com>

Looks good to me.

/Erik


On 2017-05-05 06:30, Magnus Ihse Bursie wrote:
> The RMI spec will be moved to a new location, so all links needs to be 
> updated.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179692
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179692-rmi-spec-markdown/webrev.01
>
> /Magnus
>



From erik.joelsson at oracle.com  Fri May  5 15:54:38 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 5 May 2017 08:54:38 -0700
Subject: RFR: JDK-8140268 Update link to license information in Javadoc
In-Reply-To: <577d0d4c-b9f7-8d65-b2fc-c735fa612c46@oracle.com>
References: <577d0d4c-b9f7-8d65-b2fc-c735fa612c46@oracle.com>
Message-ID: <3c02c528-842c-ff0e-36ce-fb9de7e727d2@oracle.com>

Looks good.

/Erik


On 2017-05-05 06:35, Magnus Ihse Bursie wrote:
> The links to the Javadoc specification license needs to be updated for 
> JDK9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8140268
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8140268-javadoc-license-link-footer/webrev.01
>
> /Magnus
>



From erik.joelsson at oracle.com  Fri May  5 15:55:31 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 5 May 2017 08:55:31 -0700
Subject: RFR: JDK-8179658 SetupProcessMarkdown creates long file names
In-Reply-To: <d05b630c-58f0-72c3-f91b-abeb5fc44685@oracle.com>
References: <d05b630c-58f0-72c3-f91b-abeb5fc44685@oracle.com>
Message-ID: <c9ce9c10-4369-9e43-8a6c-7c3a1c366b31@oracle.com>

Looks good.

/Erik


On 2017-05-05 06:57, Magnus Ihse Bursie wrote:
> When building with a root directory with a very deep level, the fix in 
> JDK-8179658 can cause the build to fail.
>
> The temporary files created use the entire path, which was never 
> intended. This patch fixes that.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179658
> Patch inline:
> diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk
> --- a/make/Javadoc.gmk
> +++ b/make/Javadoc.gmk
> @@ -390,14 +390,14 @@
>      $(eval SPECS_$m := $(call FindModuleSpecsDirs, $m)) \
>      $(foreach d, $(SPECS_$m), \
>        $(if $(filter %.md, $(call CacheFind, $d)), \
> -        $(eval $(call SetupProcessMarkdown, CONVERT_MARKDOWN_$m_$d, \
> +        $(eval $(call SetupProcessMarkdown, 
> CONVERT_MARKDOWN_$m_$(patsubst $(TOPDIR)/%,%,$d), \
>              SRC := $d, \
>              FILES := $(filter %.md, $(call CacheFind, $d)), \
>              DEST := $(JAVADOC_OUTPUTDIR)/specs/, \
>              CSS := $(GLOBAL_SPECS_DEFAULT_CSS_FILE), \
>          )) \
>        ) \
> -      $(eval JDK_SPECS_TARGETS += $(CONVERT_MARKDOWN_$m_$d)) \
> +      $(eval JDK_SPECS_TARGETS += $(CONVERT_MARKDOWN_$m_$(patsubst 
> $(TOPDIR)/%,%,$d))) \
>      ) \
>    )
>  endif
>
> /Magnus
>



From sandeep.konchady at oracle.com  Fri May  5 17:04:19 2017
From: sandeep.konchady at oracle.com (Sandeep Konchady)
Date: Fri, 5 May 2017 10:04:19 -0700
Subject: Graal missing from MacOS Java 9 EA download b167
In-Reply-To: <6CF09D22-D5CC-4459-94BA-65C709523E5B@gmail.com>
References: <6CF09D22-D5CC-4459-94BA-65C709523E5B@gmail.com>
Message-ID: <D90E6F4D-1246-40C9-8FF9-A7D551DB022C@oracle.com>

Hi Lennart,

Feedback from development team:

In JDK 9 jdk.internal.vm.compiler module is only built on platforms which AOT supports. And it is only Linux-x64.
We don't support Graal as JIT compiler in JDK 9. Only as compiler for AOT.

As workaround customer can download Graal from Oracle Labs and drop it into JDK. All the necessary details are in https://github.com/graalvm/graal/blob/master/compiler/README.md. Hope this helps.

Thanks,
Sandeep

> On May 3, 2017, at 1:52 AM, Lennart B?rjeson <lenborje at gmail.com> wrote:
> 
> Graal (e.g. the module jdk.internal.vm.compiler) seems to be missing from the Java 9 Early-Access download for MacOS. I noticed this with b166 and it is still so in b167.
> 
> As it is perfectly possible (I?ve done it) to download the source, configure the build to include graal, and build it, I suspect this is possibly an oversight in the packaging of the EA on MacOS, due to that AOT is only to be supported on Linux. But graal per se should surely be included on all platforms?
> 
> How to test:
> 
> Download and install Java 9 EA. Put it on the PATH.
> 
> java --list-modules | grep jdk.internal.vm.compiler
> 
> (finds compiler on Linux; finds nothing on MacOS)
> 
> 
> java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version
> 
> (Works on Linux; complains about "no JVMCI compiler selected" on MacOS)



From sean.mullan at oracle.com  Fri May  5 20:50:24 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 5 May 2017 16:50:24 -0400
Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs
 directory
In-Reply-To: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
Message-ID: <1ca80e0c-daa9-7dab-fb10-7762e9605a07@oracle.com>

General: change the text of all of the links from "Java Cryptography 
Architecture Standard Algorithm Name Documentation" (the old name) to 
"Java Security Standard Algorithm Names Specification".

Looks good otherwise.

Thanks,
Sean

On 5/5/17 9:17 AM, Magnus Ihse Bursie wrote:
> The Security Standard Names document will be moved to a new location, so
> all links needs to be updated. Also, a minor fix to the build system was
> needed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01
>
> /Magnus
>


From bradford.wetmore at oracle.com  Sat May  6 00:22:45 2017
From: bradford.wetmore at oracle.com (Brad R. Wetmore)
Date: Fri, 5 May 2017 17:22:45 -0700
Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs
 directory
In-Reply-To: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
Message-ID: <91779d8f-c22b-fe0f-3757-ff32dcad998b@oracle.com>

I applied the patch to the jdk workspace and verified that all of the 
instances were updated to 
{@docRoot}/../specs/security/standard-names.html, and that no links 
remain to the old StandardNames.html.

Sean wrote:

 > General: change the text of all of the links from "Java Cryptography
 > Architecture Standard Algorithm Name Documentation" (the old name) to
 > "Java Security Standard Algorithm Names Specification".

+1

Can you add similar wording to that effect in DrbgParameters.java?

jdk/src/java.base/share/classes/java/security/cert/CertPathValidator.java

155-156, 193-194:  extra spaces at beginning of line.

jdk/src/java.base/share/classes/javax/crypto/Cipher.java

153:  Why did you choose to use "Cipher Algorithm Names" instead of 
Cipher Algorithms?  None of the other sections use "Names".

Can you add a link in the JSSE KeyManagerFactory class description to 
the standard names sections for KeyManagerFactory's?  Even though we 
don't require any currently, we should probably point to the names anyway.

Thanks,

Brad





On 5/5/2017 6:17 AM, Magnus Ihse Bursie wrote:
> The Security Standard Names document will be moved to a new location, so
> all links needs to be updated. Also, a minor fix to the build system was
> needed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01
>
> /Magnus
>


From list at xenhideout.nl  Sat May  6 06:13:28 2017
From: list at xenhideout.nl (Xen)
Date: Sat, 06 May 2017 08:13:28 +0200
Subject: getting toolchain to be used
In-Reply-To: <C3BAE196-2E57-453C-A8D6-0BB04D88E53B@oracle.com>
References: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
 <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
 <98fa642e5aeb1bfccf0e655a874d9c30@xenhideout.nl>
 <e1a453f9-8e10-c8e3-4f79-57ebe536f6e4@oracle.com>
 <ff9fcd4a5d11a0f7ae81777f37043dc9@xenhideout.nl>
 <C3BAE196-2E57-453C-A8D6-0BB04D88E53B@oracle.com>
Message-ID: <9a83d7a4882e94c5358a4b4c426a0d74@xenhideout.nl>

Magnus Ihse Bursie schreef op 05-05-2017 17:13:
> Xen,
> Unless it's imperative for you that you build JDK 7, you might have
> more success with JDK 9. A lot have changed in the build system that
> may make it easier to build.

I suspected as such especially as there was already a configure in JDK 
8, but for me the reason is that I like to stay low :p. Also I do not 
know whether or not JDK 9 will not require more dependencies and 
libraries, and higher versions of GCC to build?

I gave up a few days ago after I could not get libX11 to find a shared 
library that was nothing other than sys/types sitting clearly in the 
direction I gave it but now I don't remember if it was not looking for 
sys/types instead of sys/types.h....

No, it is just looking for sys/types.h.

The issue is probably caused by the fact that it wasnts my main system 
compiler for that.

But it has no way for me to specify flags for native vs. cross? The 
annoyance always. Why can't they just...

Why can't they just list variables in ./configure for both types of 
compiler, ffs....

If I compile JDK with my own /usr/include present it will keep linking 
or at least including /usr/include/X11 all the time.

Most libraries don't have a HOSTCC for CC_FOR_BUILD in their config file 
or they don't use it at all...

Now it can't find a file that is sitting at the exact location it says 
it is searching unless it uses a --sysroot that I've not given it.

/bin/sed: can't read =/target/usr/local/lib/libXau.la: No such file or 
directory
libtool: link: `=/target/usr/local/lib/libXau.la' is not a valid libtool 
archive

Yay.

The problem is not so much JDK, the problem is these other libraries 
that depend on pkgconfig that lies to them if I put it in a staging 
directory and who won't actually use --sysroot to find anything when 
they should.

That whole build system is basically broken and I don't know my ways 
around it.

So yeah I have yet to solve the puzzle of:

- using DESTDIR will cause pkgconfig to have original, target filesystem 
links
- packages don't actually use --sysroot when resolving the locations 
taken from pkgconfig.

- they don't search anywhere else either when PKGCONFIG is found.
- it is often impossible to tell what values they want in 
LIBRARY_NAME_LIBS or whatever to make it work without pkgconfig.

- the result is that you compile with full filesystem paths instead.

I really think I just have to run a script to fix pkgconfig paths to the 
full paths of my host system, but it might not work for all of them....

- omg it finished. I just didn't use --sysroot anywhere. Maybe my error 
has been...

I mean maybe when using --sysroot I have to explicitly specify relative 
paths in -I, but it's not like the one I tested actually looked there. 
Or used that.

So the JDK fails to build if it has access to /usr/include/math.h 
because it shouldn't be using that one but the toolchain one instead.

So that means looking at the compiler command again.... see if all the 
-I are included in the right way, etc..

I thank you for your suggestion.


Typically older versions just have less dependencies and might also be 
smaller?

Regards.





> 
> /Magnus
> 
>> 4 maj 2017 kl. 08:38 skrev Xen <list at xenhideout.nl>:
>> 
>> David Holmes schreef op 04-05-2017 4:20:
>>> Hi Xen,
>>> Quite the adventure.
>>> Note that the options I suggested were all you should need, not
>>> options you need in addition to what you had attempted. And yes you
>>> need the symlinks to the simple names - gcc etc.
>>> You are building something that was never provided by the OpenJDK.
>>> There is no ARM version of OpenJDK in 7, or 8. There is an Oracle JDK
>>> version for ARM in 7 but that was for Java SE Embedded. So while I 
>>> can
>>> provide the basic information I did about how we use 
>>> cross-compilation
>>> to build for ARM it may be incomplete in your environment. You really
>>> should be talking to the IcedTea folk.
>>> You can try setting BUILD_HEADLESS_ONLY=true to avoid the need for an
>>> X11 headers etc but again I don't know if that will work for you.
>>> Generally even a headless JRE has to build in a headful environment.
>> 
>> Yes, some of the patches I found in the IcedTea directory where the 
>> same or similar as I had done :p. Notably the HOSTCC fix (they used 
>> CC_FOR_BUILD) and perhaps something else.
>> 
>> There was a patch for OpenEmbedded that would forego the need of X11 
>> headers, that I found, however upon trying it myself it didn't work at 
>> all.
>> 
>> You wrote somewhere else in 2012 that BUILD_HEADLESS_ONLY hardly works 
>> anymore; and that it would be better to use BUILD_HEADLESS instead.
>> 
>> So I just went ahead to try to get those X11 headers (and libs) to 
>> build against but this is quite a chore.
>> 
>> There are like a zillion individual small libraries just like the 
>> linux folk like to have 4k files in the filesystem max ;-).
>> 
>> I use a DESTDIR because I got errors while not using it, but then e.g. 
>> libxcl will use the pkgconfig of xcb-proto and search in the wrong 
>> location; -- can't they just put it in one package lol.
>> 
>> So you have to botch up the pkgconfig ...
>> 
>> Oh, I didn't notice, libX11 completed.
>> 
>> Apart from the fact that it installed in my own /usr/local...
>> 
>> ;-).
>> 
>> LDFLAGS to the rescue I guess, and properly using it (DESTDIR).
>> 
>> As these things go, it now automatically compiles and installs 
>> xcb-proto, libXau, libxcb, libX11, libffi and libasound :p.
>> 
>> It's the search path not found errors that drive you insane though.
>> 
>> For every header it needs it checks the path I supplied.
>> 
>> Except for this one.
>> 
>> And why, because it opens a pkgconfig file and looks no further. So 
>> here I am, spending at least an hour trying to get one program to 
>> reference one file.
>> 
>> Such a good ... spending of time.
>> 
>> And then when it doesn't complain it's because it is actually loading 
>> the file from my main system...
>> 
>> So basically when I use a good prefix for my configurations other 
>> packages won't be able to find it because the pkgtool shows a relative 
>> link relative to sysroot, that they don't process.
>> 
>> Then, the .la files also have the full absolute path on my own system.
>> 
>> Then, the next library is going to actually process the .la paths 
>> based on a sysroot directive I give it, creating overly long, 
>> nonexistent paths.
>> 
>> So what I actually need to do is to botch up every pkgconfig file 
>> after the fact so that it works for this system for absolute paths, 
>> while the .la files are actually okay  for those who use sysroot.....
>> 
>> Now I am back with another library that is not found, and this pain 
>> just keeps repeating itself.
>> 
>> Sorry about this.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> David
>>>> On 4/05/2017 7:31 AM, Xen wrote:
>>>> David Holmes schreef op 03-05-2017 6:07:
>>>>> For cross compilation you should need to set the following only:
>>>> So basically I know have a working HotSpot build for u101 but u131 
>>>> and
>>>> u121 fail because a single cpp file references a variable that 
>>>> doesn't
>>>> exist anywhere in the source code. I know it means "MutableCallSite"
>>>> because it is referenced in java code but there is no other cpp or 
>>>> hpp
>>>> file that actually uses it.
>>>> Not that name of variable at least.
>>>> And u101 refuses to create the final executable correctly, I mean 
>>>> the
>>>> final liblvm.so.
>>>> So next up is u111b01 :p.
>>>> 111b01 succeeds in building but again cannot create the liblvm.so
>>>> So I had to add "rm -f $@; \" to the vm.make file and then I needed 
>>>> to
>>>> add -Xlinker -rpath=directory to my EXTRA_CFLAGS.
>>>> For linking against libffi.so.6
>>>> And now the hotspot concluded :p.
>>>> Within seconds it ran into another library not found error this time
>>>> libjvm.so that it just created.
>>>> Am I doing something wrong with the directories?
>>>> In the makefile $@ expanded to libjvm.so and LIBJVM_G also expanded 
>>>> to
>>>> that, when clearly they were intended to be separate
>>>> I think I told it only to build a client vm but my target build dir
>>>> /lib/arm/client does not exist; is empty.
>>>> That server jvm is 121 MB :O. Is that because of debug information?
>>>> Okay, for some reason before it required -Xlinker -rpath and now it
>>>> requires -L...
>>>> Now it tries to add a copyright date notice to a small header file 
>>>> and
>>>> then add to it using 
>>>> build/tmp/java/java.nio/nio/genSocketOptionRegistry
>>>> but this program fails, saying:
>>>> Syntax error: word unexpected (expecting ")")
>>>> The problem is that it is trying to run an ARM executable on my 
>>>> build
>>>> host :).
>>>> :P.
>>>> This is going to take fundamentally forever, if I keep this up.
>>>> So the makefile was not correct, it only used HOST_CC in case of 
>>>> MacOS
>>>> platform.
>>>> I am going to apply those IcedTea patches I think....
>>>> Now it uses the wrong AS.
>>>> My mistake, gcc actually uses the path to find an as that matches 
>>>> it,
>>>> which doesn't work in my case since I have overridden it. Proceeding 
>>>> again.
>>>> So I fixed the previous thing wrong and got a java compile error 
>>>> because
>>>> the file ended up empty after using the default "CC" CCFLAGS, 
>>>> obviously
>>>> that doesn't work so well when using HOST_CC.
>>>> Fixed again, now at last I get a normal error: libasound is not 
>>>> there
>>>> yet :p.
>>>> The errors that are supposed to happen.
>>>> Thankful errors :p.
>>>> Omg I should never have attempted this.
>>>> But anyway with libasound compiled I am further ahead again.
>>>> Now my biggest question: how can I create a true headless mode?
>>>> DO I need X11 headers pers?? Can I just skip X11 compilation and awt
>>>> compilation?
>>>> Please? :P.
>>>> Regards.


From list at xenhideout.nl  Sat May  6 07:49:31 2017
From: list at xenhideout.nl (Xen)
Date: Sat, 06 May 2017 09:49:31 +0200
Subject: getting toolchain to be used
In-Reply-To: <C3BAE196-2E57-453C-A8D6-0BB04D88E53B@oracle.com>
References: <00845f0d03e0323a9362ac02c8540c5d@xenhideout.nl>
 <a0bea4f6-2e9d-6a8d-58d8-a4d212c2028e@oracle.com>
 <98fa642e5aeb1bfccf0e655a874d9c30@xenhideout.nl>
 <e1a453f9-8e10-c8e3-4f79-57ebe536f6e4@oracle.com>
 <ff9fcd4a5d11a0f7ae81777f37043dc9@xenhideout.nl>
 <C3BAE196-2E57-453C-A8D6-0BB04D88E53B@oracle.com>
Message-ID: <ef5c50800e6730967521e8ad6e166e43@xenhideout.nl>

So seriously,

because the command line includes -I/usr/include

and because the toolchain directory /usr/arm-linux-eabi/include is 
embedded in the toolchain,
and because --sysroot /usr/include is also a standard directory

it searches its full paramters first before it considers any standard 
locations, even if those standard locations are actually supplied on the 
command line.

So it will find /usr/include first before venturing into e.g. 
$SYSROOT/usr/include.

Why? Well apparently because due to --sysroot /usr/include is no longer 
a standard location, so it is considered first.

Isn't that freaking amazing, it just ignores your parameters because it 
already knows about them.

It integrates them into its list and only after will it start sorting 
them according to what it already knew.

Which is really just wrong behaviour, but anyway.

It should integrate after sorting and then use the first occurance in 
the list.

So I can get around it yes.

If I just copy the headers to $SYSROOT/usr/local/include.fuckedup, then 
it will work.

Symlinks also don't work because it will just readlink them :p.

Meanwhile --sysroot actually does not cause locations to be resolved 
according to $SYSROOT.

So it's whole purpose is meaningless: it just causes important locations 
to be searched last.

Neither full nor relative paths are resolved with regards to it. Why 
have it then???

Maybe it works for libraries, I don't know.

Oh man...

I truly believe people make it harder on purpose. Not you, in this case 
just GCC.

There are just people invested in making life harder for other people.

For example, why doesn't GCC or make just output a list of locations 
that it searched in?

It would be so easy.

And save so much time.

But they don't do it.

They just give a non-descript error.

That you need fucking strace to diagnose.

Sorry for my language though.

Regards.


From magnus.ihse.bursie at oracle.com  Mon May  8 07:51:38 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 8 May 2017 09:51:38 +0200
Subject: RFR: JDK-8179879 Clarify install.sh
Message-ID: <68a2d735-e6be-29bf-8db0-64c39f3c43b7@oracle.com>

Clarify the purpose of install.sh

Bug: https://bugs.openjdk.java.net/browse/JDK-8179879
Patch inline:
diff --git a/common/autoconf/build-aux/install.sh 
b/common/autoconf/build-aux/install.sh
--- a/common/autoconf/build-aux/install.sh
+++ b/common/autoconf/build-aux/install.sh
@@ -1,5 +1,28 @@
-#!/bin/sh
-echo >&2 "No suitable 'install' command found.'"
-echo >&2 "If automake is installed, running 'automake -fa'"
-echo >&2 "(and ignoring the errors) might produce one."
-exit 1
+#!/bin/bash
+#
+# Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.
+# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+#
+# This code is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License version 2 only, as
+# published by the Free Software Foundation.  Oracle designates this
+# particular file as subject to the "Classpath" exception as provided
+# by Oracle in the LICENSE file that accompanied this code.
+#
+# This code is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+# version 2 for more details (a copy is included in the LICENSE file that
+# accompanied this code).
+#
+# You should have received a copy of the GNU General Public License version
+# 2 along with this work; if not, write to the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+# or visit www.oracle.com if you need additional information or have any
+# questions.
+#
+
+# This file is empty on purpose. It's a placeholder which is required by
+# autoconf, but it serves no purpose for us.

/Magnus



From magnus.ihse.bursie at oracle.com  Mon May  8 11:29:53 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 8 May 2017 13:29:53 +0200
Subject: RFR: JDK-8179889 Fix typographic errors in copyright headers
Message-ID: <f619ac0c-7de1-fc4c-323b-b4c9b5482449@oracle.com>

Some of the copyright headers have minor problems. The most common one 
is not following the prescribed Oracle pattern of copyright year 
("<initial_change>, <last_change>, ").

Other errors seems to be the result of accidents in the editor, 
including search/replace gone wild ("LICENSE file" => "LICENSE 
randomAccessFile" :-)), or random edits.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179889
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8179889-fix-copyright-header-typos/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Mon May  8 13:29:03 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 8 May 2017 15:29:03 +0200
Subject: RFR: JDK-8179889 Fix typographic errors in copyright headers
In-Reply-To: <f619ac0c-7de1-fc4c-323b-b4c9b5482449@oracle.com>
References: <f619ac0c-7de1-fc4c-323b-b4c9b5482449@oracle.com>
Message-ID: <6b5ae5c6-12a9-86e0-ad6c-0665726bb4b8@oracle.com>

On 2017-05-08 13:29, Magnus Ihse Bursie wrote:
> Some of the copyright headers have minor problems. The most common one 
> is not following the prescribed Oracle pattern of copyright year 
> ("<initial_change>, <last_change>, ").
>
> Other errors seems to be the result of accidents in the editor, 
> including search/replace gone wild ("LICENSE file" => "LICENSE 
> randomAccessFile" :-)), or random edits.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179889
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179889-fix-copyright-header-typos/webrev.01
>
> /Magnus

Here is an updated webrev with even more files fixed:

http://cr.openjdk.java.net/~ihse/JDK-8179889-fix-copyright-header-typos/webrev.02

/Magnus


From erik.joelsson at oracle.com  Mon May  8 15:09:51 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 8 May 2017 08:09:51 -0700
Subject: RFR: JDK-8179879 Clarify install.sh
In-Reply-To: <68a2d735-e6be-29bf-8db0-64c39f3c43b7@oracle.com>
References: <68a2d735-e6be-29bf-8db0-64c39f3c43b7@oracle.com>
Message-ID: <72888545-3da4-2d4f-f229-3b6ff41db818@oracle.com>

Looks good to me.

/Erik


On 2017-05-08 00:51, Magnus Ihse Bursie wrote:
> Clarify the purpose of install.sh
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179879
> Patch inline:
> diff --git a/common/autoconf/build-aux/install.sh 
> b/common/autoconf/build-aux/install.sh
> --- a/common/autoconf/build-aux/install.sh
> +++ b/common/autoconf/build-aux/install.sh
> @@ -1,5 +1,28 @@
> -#!/bin/sh
> -echo >&2 "No suitable 'install' command found.'"
> -echo >&2 "If automake is installed, running 'automake -fa'"
> -echo >&2 "(and ignoring the errors) might produce one."
> -exit 1
> +#!/bin/bash
> +#
> +# Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.
> +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> +#
> +# This code is free software; you can redistribute it and/or modify it
> +# under the terms of the GNU General Public License version 2 only, as
> +# published by the Free Software Foundation.  Oracle designates this
> +# particular file as subject to the "Classpath" exception as provided
> +# by Oracle in the LICENSE file that accompanied this code.
> +#
> +# This code is distributed in the hope that it will be useful, but 
> WITHOUT
> +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +# version 2 for more details (a copy is included in the LICENSE file 
> that
> +# accompanied this code).
> +#
> +# You should have received a copy of the GNU General Public License 
> version
> +# 2 along with this work; if not, write to the Free Software Foundation,
> +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> +#
> +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 
> USA
> +# or visit www.oracle.com if you need additional information or have any
> +# questions.
> +#
> +
> +# This file is empty on purpose. It's a placeholder which is required by
> +# autoconf, but it serves no purpose for us.
>
> /Magnus
>



From erik.joelsson at oracle.com  Mon May  8 15:20:20 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 8 May 2017 08:20:20 -0700
Subject: RFR: JDK-8179889 Fix typographic errors in copyright headers
In-Reply-To: <6b5ae5c6-12a9-86e0-ad6c-0665726bb4b8@oracle.com>
References: <f619ac0c-7de1-fc4c-323b-b4c9b5482449@oracle.com>
 <6b5ae5c6-12a9-86e0-ad6c-0665726bb4b8@oracle.com>
Message-ID: <ac5bf26b-a0e4-1d5c-886d-3666f3434b9b@oracle.com>

Looks good. Great work!

/Erik


On 2017-05-08 06:29, Magnus Ihse Bursie wrote:
> On 2017-05-08 13:29, Magnus Ihse Bursie wrote:
>> Some of the copyright headers have minor problems. The most common 
>> one is not following the prescribed Oracle pattern of copyright year 
>> ("<initial_change>, <last_change>, ").
>>
>> Other errors seems to be the result of accidents in the editor, 
>> including search/replace gone wild ("LICENSE file" => "LICENSE 
>> randomAccessFile" :-)), or random edits.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179889
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8179889-fix-copyright-header-typos/webrev.01
>>
>> /Magnus
>
> Here is an updated webrev with even more files fixed:
>
> http://cr.openjdk.java.net/~ihse/JDK-8179889-fix-copyright-header-typos/webrev.02 
>
>
> /Magnus



From david.holmes at oracle.com  Tue May  9 00:43:39 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 9 May 2017 10:43:39 +1000
Subject: RFR: JDK-8179889 Fix typographic errors in copyright headers
In-Reply-To: <6b5ae5c6-12a9-86e0-ad6c-0665726bb4b8@oracle.com>
References: <f619ac0c-7de1-fc4c-323b-b4c9b5482449@oracle.com>
 <6b5ae5c6-12a9-86e0-ad6c-0665726bb4b8@oracle.com>
Message-ID: <0040c587-55ec-25ec-750c-e06aa640c41a@oracle.com>

Hi Magnus,

Changes look good. I'm very surprised that such problems persist in 
existing files given all the previous audits and fixups that have been 
done. :(

The patch shows various changes that I can only assume are whitespace 
related - yet such issues should have been prevented by jcheck. ??

Thanks,
David

On 8/05/2017 11:29 PM, Magnus Ihse Bursie wrote:
> On 2017-05-08 13:29, Magnus Ihse Bursie wrote:
>> Some of the copyright headers have minor problems. The most common one
>> is not following the prescribed Oracle pattern of copyright year
>> ("<initial_change>, <last_change>, ").
>>
>> Other errors seems to be the result of accidents in the editor,
>> including search/replace gone wild ("LICENSE file" => "LICENSE
>> randomAccessFile" :-)), or random edits.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179889
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8179889-fix-copyright-header-typos/webrev.01
>>
>>
>> /Magnus
>
> Here is an updated webrev with even more files fixed:
>
> http://cr.openjdk.java.net/~ihse/JDK-8179889-fix-copyright-header-typos/webrev.02
>
>
> /Magnus


From magnus.ihse.bursie at oracle.com  Tue May  9 11:37:50 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 9 May 2017 13:37:50 +0200
Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs
 directory
In-Reply-To: <9ca199f9-5b0f-e210-c068-90cd81353864@oracle.com>
References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
 <9ca199f9-5b0f-e210-c068-90cd81353864@oracle.com>
Message-ID: <4a008991-3caa-6025-6439-f07bed5f2522@oracle.com>


On 2017-05-05 17:52, Erik Joelsson wrote:
> What's the reason for adding the conditional around SetupCopyFiles in 
> Javadoc.gmk? The SetupCopyFiles macro should be safe to call with an 
> empty FILES list. It should evaluate to basically nothing in that case.

I don't think there's an explicit reason. The code evolved that way. The 
previous version had a check for $(SPECS_$m), since SetupCopyFiles does 
*not* cope with an empty SRC. (Trust me on this ;-))

However, the new foreach will take care of that, so $d will always be 
specified. The current pattern also mimicks the call to 
SetupProcessMarkdown further down. (Which, I believe, would not handle 
an empty value on FILES. Which it perhaps should.)

If nothing else, it would probably save us a few clock cycles. :-)

Do you want me to remove it?

/Magnus

>
> /Erik
>
>
> On 2017-05-05 06:17, Magnus Ihse Bursie wrote:
>> The Security Standard Names document will be moved to a new location, 
>> so all links needs to be updated. Also, a minor fix to the build 
>> system was needed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01
>>
>> /Magnus
>>
>



From magnus.ihse.bursie at oracle.com  Tue May  9 12:21:38 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 9 May 2017 14:21:38 +0200
Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs
 directory
In-Reply-To: <91779d8f-c22b-fe0f-3757-ff32dcad998b@oracle.com>
References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
 <91779d8f-c22b-fe0f-3757-ff32dcad998b@oracle.com>
Message-ID: <e91e9022-154e-0fc1-e3e8-613522328916@oracle.com>


On 2017-05-06 02:22, Brad R. Wetmore wrote:
> I applied the patch to the jdk workspace and verified that all of the 
> instances were updated to 
> {@docRoot}/../specs/security/standard-names.html, and that no links 
> remain to the old StandardNames.html.
>
> Sean wrote:
>
> > General: change the text of all of the links from "Java Cryptography
> > Architecture Standard Algorithm Name Documentation" (the old name) to
> > "Java Security Standard Algorithm Names Specification".
>
> +1

I've updated the name in all places that I could find.

> Can you add similar wording to that effect in DrbgParameters.java?

I'm sorry, that instruction is too unclear for me. :-( The main purpose 
of this patch is to prepare for the markdown based specification, not 
fixing the entire content. I'll leave modification of the actual 
documentation to the component owners.

>
> jdk/src/java.base/share/classes/java/security/cert/CertPathValidator.java
>
> 155-156, 193-194:  extra spaces at beginning of line.
Fixed.

>
> jdk/src/java.base/share/classes/javax/crypto/Cipher.java
>
> 153:  Why did you choose to use "Cipher Algorithm Names" instead of 
> Cipher Algorithms?  None of the other sections use "Names".

I did not choose that, that's what the section is called in the document 
(and has been since at least JDK 8). The difference here is that the 
anchor links are named after the actual headings in the document, not 
arbitrarily named anchors (for better and for worse).

>
> Can you add a link in the JSSE KeyManagerFactory class description to 
> the standard names sections for KeyManagerFactory's?  Even though we 
> don't require any currently, we should probably point to the names 
> anyway.

I'll give you the same reply here as for DrbgParameters.java: I don't 
know enough about the domain to be able to do this job properly. Please 
file a follow-up bug and fix it yourself, or assign to someone who knows.

Updated webrev: (contains whitespace fixes and rename of document, but 
only the jdk repo)

http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.02

/Magnus


/Magnus


>
> Thanks,
>
> Brad
>
>
>
>
>
> On 5/5/2017 6:17 AM, Magnus Ihse Bursie wrote:
>> The Security Standard Names document will be moved to a new location, so
>> all links needs to be updated. Also, a minor fix to the build system was
>> needed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 
>>
>>
>> /Magnus
>>



From erik.joelsson at oracle.com  Tue May  9 15:48:05 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 9 May 2017 08:48:05 -0700
Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs
 directory
In-Reply-To: <4a008991-3caa-6025-6439-f07bed5f2522@oracle.com>
References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
 <9ca199f9-5b0f-e210-c068-90cd81353864@oracle.com>
 <4a008991-3caa-6025-6439-f07bed5f2522@oracle.com>
Message-ID: <ee34ddbe-d713-9b17-6ee6-27f26d7e3d3b@oracle.com>

Nah, it's fine.

/Erik


On 2017-05-09 04:37, Magnus Ihse Bursie wrote:
>
> On 2017-05-05 17:52, Erik Joelsson wrote:
>> What's the reason for adding the conditional around SetupCopyFiles in 
>> Javadoc.gmk? The SetupCopyFiles macro should be safe to call with an 
>> empty FILES list. It should evaluate to basically nothing in that case.
>
> I don't think there's an explicit reason. The code evolved that way. 
> The previous version had a check for $(SPECS_$m), since SetupCopyFiles 
> does *not* cope with an empty SRC. (Trust me on this ;-))
>
> However, the new foreach will take care of that, so $d will always be 
> specified. The current pattern also mimicks the call to 
> SetupProcessMarkdown further down. (Which, I believe, would not handle 
> an empty value on FILES. Which it perhaps should.)
>
> If nothing else, it would probably save us a few clock cycles. :-)
>
> Do you want me to remove it?
>
> /Magnus
>
>>
>> /Erik
>>
>>
>> On 2017-05-05 06:17, Magnus Ihse Bursie wrote:
>>> The Security Standard Names document will be moved to a new 
>>> location, so all links needs to be updated. Also, a minor fix to the 
>>> build system was needed.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01
>>>
>>> /Magnus
>>>
>>
>



From bradford.wetmore at oracle.com  Tue May  9 20:11:46 2017
From: bradford.wetmore at oracle.com (Brad R. Wetmore)
Date: Tue, 9 May 2017 13:11:46 -0700
Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs
 directory
In-Reply-To: <e91e9022-154e-0fc1-e3e8-613522328916@oracle.com>
References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com>
 <91779d8f-c22b-fe0f-3757-ff32dcad998b@oracle.com>
 <e91e9022-154e-0fc1-e3e8-613522328916@oracle.com>
Message-ID: <d4c0cbcd-f38a-b150-360e-1ffa6e4db6fe@oracle.com>


>> Can you add similar wording to that effect in DrbgParameters.java?
>
> I'm sorry, that instruction is too unclear for me. :-( The main purpose
> of this patch is to prepare for the markdown based specification, not
> fixing the entire content. I'll leave modification of the actual
> documentation to the component owners.

In rereading this, I withdraw this comment.  It didn't make sense.

>> jdk/src/java.base/share/classes/java/security/cert/CertPathValidator.java
>>
>> 155-156, 193-194:  extra spaces at beginning of line.
> Fixed.
>
>>
>> jdk/src/java.base/share/classes/javax/crypto/Cipher.java
>>
>> 153:  Why did you choose to use "Cipher Algorithm Names" instead of
>> Cipher Algorithms?  None of the other sections use "Names".
>
> I did not choose that, that's what the section is called in the document
> (and has been since at least JDK 8). The difference here is that the
> anchor links are named after the actual headings in the document, not
> arbitrarily named anchors (for better and for worse).

When I got down into the .md file, I figured out your methodology. 
Thanks for explaining.

>> Can you add a link in the JSSE KeyManagerFactory class description to
>> the standard names sections for KeyManagerFactory's?  Even though we
>> don't require any currently, we should probably point to the names
>> anyway.
>
> I'll give you the same reply here as for DrbgParameters.java: I don't
> know enough about the domain to be able to do this job properly. Please
> file a follow-up bug and fix it yourself, or assign to someone who knows.

I've filed:  JDK-8180005

Thanks.

> Updated webrev: (contains whitespace fixes and rename of document, but
> only the jdk repo)

Whitespace looks fine.  I did a spot check of the renames and seemed 
pretty straightforward, so I didn't go through all of them.

Brad


> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.02
>
>
> /Magnus
>
>
> /Magnus
>
>
>>
>> Thanks,
>>
>> Brad
>>
>>
>>
>>
>>
>> On 5/5/2017 6:17 AM, Magnus Ihse Bursie wrote:
>>> The Security Standard Names document will be moved to a new location, so
>>> all links needs to be updated. Also, a minor fix to the build system was
>>> needed.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01
>>>
>>>
>>> /Magnus
>>>
>


From erik.joelsson at oracle.com  Tue May  9 23:28:32 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 9 May 2017 16:28:32 -0700
Subject: RFR: JDK9 b167: demos exist in JDK bundles
Message-ID: <11b53f87-2155-bee2-f90a-ff262a2ebaba@oracle.com>

We recently stopped building the JDK demos, or at least most of them. 
For client testing purposes we are still building some of them, and 
those are now ending up in the JDK bundle. Since we are very late in JDK 
9, we do not want to interrupt the testing procedures by moving these 
demos out of the jdk image. This patch restores the filtering of the jdk 
bundle to again exclude the demo directory.

Since these demo files are now only kept for use in testing, their 
proper place is actually in the test-image/bundle. This patch also adds 
them there to support the transition of the testing procedures.

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

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

/Erik



From magnus.ihse.bursie at oracle.com  Wed May 10 07:06:35 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 10 May 2017 09:06:35 +0200
Subject: RFR: JDK9 b167: demos exist in JDK bundles
In-Reply-To: <11b53f87-2155-bee2-f90a-ff262a2ebaba@oracle.com>
References: <11b53f87-2155-bee2-f90a-ff262a2ebaba@oracle.com>
Message-ID: <686e0990-d47a-0ff0-556a-4f72faa164cc@oracle.com>

On 2017-05-10 01:28, Erik Joelsson wrote:
> We recently stopped building the JDK demos, or at least most of them. 
> For client testing purposes we are still building some of them, and 
> those are now ending up in the JDK bundle. Since we are very late in 
> JDK 9, we do not want to interrupt the testing procedures by moving 
> these demos out of the jdk image. This patch restores the filtering of 
> the jdk bundle to again exclude the demo directory.
>
> Since these demo files are now only kept for use in testing, their 
> proper place is actually in the test-image/bundle. This patch also 
> adds them there to support the transition of the testing procedures.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179867
>
> Webrev: http://cr.openjdk.java.net/~erikj/8179867/webrev.01

Looks good to me.

Thanks for being proactive in moving the demos to the test image!

/Magnus

>
> /Erik
>



From magnus.ihse.bursie at oracle.com  Wed May 10 08:18:57 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 10 May 2017 10:18:57 +0200
Subject: RFR: JDK-8179105 A new property to specify import module to be
 included in unified docs bundle
Message-ID: <2d8abb62-d13f-5ec2-b8b1-3b48f2fb8016@oracle.com>

javafx modules include a `build.properties` file to specify the properties
when being imported in JDK image build. `make docs` currently includes 
all imported modules.

  A new property e.g. `include_in_docs` would allow FX to select which
FX modules to be included in the docs bundle.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179105
Patch inline:
diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk
--- a/make/common/Modules.gmk
+++ b/make/common/Modules.gmk
@@ -391,7 +391,10 @@
        else ifeq ($$(classloader), ext)
          PLATFORM_MODULES += $1
        endif
-      DOCS_MODULES += $1
+      ifneq ($$(include_in_docs), false)
+        # defaults to true if unspecified
+        DOCS_MODULES += $1
+      endif
      else
        # Default to include in all
        JRE_MODULES += $1

/Magnus


From magnus.ihse.bursie at oracle.com  Wed May 10 09:12:31 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 10 May 2017 11:12:31 +0200
Subject: JDK-8175825 Stop including pubs repo
Message-ID: <cf82b262-b212-1b78-8eb7-c4fd4ffbf9ae@oracle.com>

Here are some externally visible changes for an internal change: we will 
stop copying documentation from the "pubs" repo, and some of that logic 
has leaked through into the open parts, and will be removed with this patch.

I have also renamed Javadoc.gmk to Docs.gmk to better fit the current 
purpose, and included some other minor cleanups.

Bug: https://bugs.openjdk.java.net/browse/JDK-8175825
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8175825-no-more-pubs/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Wed May 10 13:03:07 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 10 May 2017 15:03:07 +0200
Subject: RFR: JDK-8174848 Remove gpl templates from hotspot/make
Message-ID: <31251b0a-8b7d-bf80-cf1e-4edbb99dd7c5@oracle.com>

The GPL templates in hotspot/make are not used anymore. The templates in 
$TOPDIR/make/templates remain.

Bug: https://bugs.openjdk.java.net/browse/JDK-8174848
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8174848-remove-hotspot-gpl-templates/webrev.01

/Magnus


From mandy.chung at oracle.com  Wed May 10 14:47:46 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 10 May 2017 07:47:46 -0700
Subject: RFR: JDK-8179105 A new property to specify import module to be
 included in unified docs bundle
In-Reply-To: <2d8abb62-d13f-5ec2-b8b1-3b48f2fb8016@oracle.com>
References: <2d8abb62-d13f-5ec2-b8b1-3b48f2fb8016@oracle.com>
Message-ID: <F71B2F76-0210-4FAE-81FA-0ADF68F3EF56@oracle.com>

+1

thanks
Mandy

> On May 10, 2017, at 1:18 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> javafx modules include a `build.properties` file to specify the properties 
> when being imported in JDK image build. `make docs` currently includes all imported modules. 
> 
>  A new property e.g. `include_in_docs` would allow FX to select which 
> FX modules to be included in the docs bundle. 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179105 <https://bugs.openjdk.java.net/browse/JDK-8179105>
> Patch inline:
> diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk
> --- a/make/common/Modules.gmk
> +++ b/make/common/Modules.gmk
> @@ -391,7 +391,10 @@
>        else ifeq ($$(classloader), ext)
>          PLATFORM_MODULES += $1
>        endif
> -      DOCS_MODULES += $1
> +      ifneq ($$(include_in_docs), false)
> +        # defaults to true if unspecified
> +        DOCS_MODULES += $1
> +      endif
>      else
>        # Default to include in all
>        JRE_MODULES += $1
> 
> /Magnus



From erik.joelsson at oracle.com  Wed May 10 16:05:38 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 10 May 2017 09:05:38 -0700
Subject: JDK-8175825 Stop including pubs repo
In-Reply-To: <cf82b262-b212-1b78-8eb7-c4fd4ffbf9ae@oracle.com>
References: <cf82b262-b212-1b78-8eb7-c4fd4ffbf9ae@oracle.com>
Message-ID: <658f8e35-fbaf-358a-63c5-f7c6a9797e80@oracle.com>

Open part looks good.

/Erik


On 2017-05-10 02:12, Magnus Ihse Bursie wrote:
> Here are some externally visible changes for an internal change: we 
> will stop copying documentation from the "pubs" repo, and some of that 
> logic has leaked through into the open parts, and will be removed with 
> this patch.
>
> I have also renamed Javadoc.gmk to Docs.gmk to better fit the current 
> purpose, and included some other minor cleanups.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175825
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8175825-no-more-pubs/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Wed May 10 16:06:10 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 10 May 2017 09:06:10 -0700
Subject: RFR: JDK-8174848 Remove gpl templates from hotspot/make
In-Reply-To: <31251b0a-8b7d-bf80-cf1e-4edbb99dd7c5@oracle.com>
References: <31251b0a-8b7d-bf80-cf1e-4edbb99dd7c5@oracle.com>
Message-ID: <9dc53e92-9196-4845-d750-89beb42fadf8@oracle.com>

Looks good.

/Erik


On 2017-05-10 06:03, Magnus Ihse Bursie wrote:
> The GPL templates in hotspot/make are not used anymore. The templates 
> in $TOPDIR/make/templates remain.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8174848
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8174848-remove-hotspot-gpl-templates/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Wed May 10 16:07:26 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 10 May 2017 09:07:26 -0700
Subject: RFR: JDK-8179105 A new property to specify import module to be
 included in unified docs bundle
In-Reply-To: <2d8abb62-d13f-5ec2-b8b1-3b48f2fb8016@oracle.com>
References: <2d8abb62-d13f-5ec2-b8b1-3b48f2fb8016@oracle.com>
Message-ID: <cc7999dd-2b95-6b08-13a8-8f619107f0d9@oracle.com>

Looks good.

/Erik


On 2017-05-10 01:18, Magnus Ihse Bursie wrote:
> javafx modules include a `build.properties` file to specify the 
> properties
> when being imported in JDK image build. `make docs` currently includes 
> all imported modules.
>
>  A new property e.g. `include_in_docs` would allow FX to select which
> FX modules to be included in the docs bundle.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179105
> Patch inline:
> diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk
> --- a/make/common/Modules.gmk
> +++ b/make/common/Modules.gmk
> @@ -391,7 +391,10 @@
>        else ifeq ($$(classloader), ext)
>          PLATFORM_MODULES += $1
>        endif
> -      DOCS_MODULES += $1
> +      ifneq ($$(include_in_docs), false)
> +        # defaults to true if unspecified
> +        DOCS_MODULES += $1
> +      endif
>      else
>        # Default to include in all
>        JRE_MODULES += $1
>
> /Magnus



From kumar.x.srinivasan at oracle.com  Wed May 10 16:42:58 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 10 May 2017 09:42:58 -0700
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
Message-ID: <59134312.6070701@oracle.com>

Hi,

Please review fix for the custom taglet to allow openjdk builds, in 
which case
the property "build.tools.taglet.ExtLink.NO_LINK" must be set to inhibit 
server
side lookups.

Thanks
Kumar

Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
JBS: https://bugs.openjdk.java.net/browse/JDK-8179915


From erik.joelsson at oracle.com  Wed May 10 16:51:53 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 10 May 2017 09:51:53 -0700
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <59134312.6070701@oracle.com>
References: <59134312.6070701@oracle.com>
Message-ID: <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>

Should this be set on the javadoc command line somewhere or am I missing 
something?

/Erik


On 2017-05-10 09:42, Kumar Srinivasan wrote:
> Hi,
>
> Please review fix for the custom taglet to allow openjdk builds, in 
> which case
> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to 
> inhibit server
> side lookups.
>
> Thanks
> Kumar
>
> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915



From kumar.x.srinivasan at oracle.com  Wed May 10 17:18:34 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 10 May 2017 10:18:34 -0700
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
References: <59134312.6070701@oracle.com>
 <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
Message-ID: <59134B6A.7090504@oracle.com>


On 5/10/2017 9:51 AM, Erik Joelsson wrote:
> Should this be set on the javadoc command line somewhere or am I 
> missing something?

Yes, one would have to set this prop, via the build system, when
performing a non-oracle build.

Kumar

>
> /Erik
>
>
> On 2017-05-10 09:42, Kumar Srinivasan wrote:
>> Hi,
>>
>> Please review fix for the custom taglet to allow openjdk builds, in 
>> which case
>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to 
>> inhibit server
>> side lookups.
>>
>> Thanks
>> Kumar
>>
>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915
>



From erik.joelsson at oracle.com  Wed May 10 21:12:48 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 10 May 2017 14:12:48 -0700
Subject: RFR: JDK-8180081: Adjust Jib and JDL configuration for 10 to support
 promotable builds
Message-ID: <c4e5b603-4a61-42fb-6168-fbd964c8d8a2@oracle.com>

This patch contains adjustments for the jib-profiles.js configuration 
needed for supporting the next generation Oracle internal build and test 
system.

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

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

/Erik



From christian.tornqvist at oracle.com  Wed May 10 21:26:10 2017
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Wed, 10 May 2017 14:26:10 -0700
Subject: RFR: JDK-8180081: Adjust Jib and JDL configuration for 10 to
 support promotable builds
In-Reply-To: <c4e5b603-4a61-42fb-6168-fbd964c8d8a2@oracle.com>
References: <c4e5b603-4a61-42fb-6168-fbd964c8d8a2@oracle.com>
Message-ID: <709FA5DF-6C5D-45ED-BFC1-3EFA0BC36433@oracle.com>

Hi Erik,

This looks good, thanks for fixing this!

Thanks,
Christian

> On May 10, 2017, at 2:12 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> This patch contains adjustments for the jib-profiles.js configuration needed for supporting the next generation Oracle internal build and test system.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180081
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8180081/webrev.01/
> 
> /Erik
> 



From tim.bell at oracle.com  Wed May 10 22:06:13 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 10 May 2017 15:06:13 -0700
Subject: RFR: XS: URGENT: JDK-8180129, , Bundles.gmk:181: *** unterminated call
 to function 'filter-out': missing ')'
Message-ID: <59138ED5.9070609@oracle.com>

A fix for packaging changes in the closed files missed one line
continuation in an open file, and without this all builds fail:

% hg diff
diff --git a/make/Bundles.gmk b/make/Bundles.gmk
--- a/make/Bundles.gmk
+++ b/make/Bundles.gmk
@@ -183,7 +183,7 @@
            $(JDK_SYMBOLS_EXCLUDE_PATTERN) \
            $(JDK_EXTRA_EXCLUDES) \
            $(SYMBOLS_EXCLUDE_PATTERN) \
-          $(JDK_IMAGE_HOMEDIR)/demo/%
+          $(JDK_IMAGE_HOMEDIR)/demo/% \
            , \
            $(ALL_JDK_FILES) \
        )

Already reviewed in person by erikj.  I am sending to the open build 
list to complete the loop.

Thanks in advance-

Tim


From erik.joelsson at oracle.com  Wed May 10 22:07:05 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 10 May 2017 15:07:05 -0700
Subject: RFR: XS: URGENT: JDK-8180129, , Bundles.gmk:181: *** unterminated
 call to function 'filter-out': missing ')'
In-Reply-To: <59138ED5.9070609@oracle.com>
References: <59138ED5.9070609@oracle.com>
Message-ID: <64ad431e-5a12-df7f-9d0e-e6135111f161@oracle.com>

Looks good. Thanks for fixing this!

/Erik


On 2017-05-10 15:06, Tim Bell wrote:
> A fix for packaging changes in the closed files missed one line
> continuation in an open file, and without this all builds fail:
>
> % hg diff
> diff --git a/make/Bundles.gmk b/make/Bundles.gmk
> --- a/make/Bundles.gmk
> +++ b/make/Bundles.gmk
> @@ -183,7 +183,7 @@
>            $(JDK_SYMBOLS_EXCLUDE_PATTERN) \
>            $(JDK_EXTRA_EXCLUDES) \
>            $(SYMBOLS_EXCLUDE_PATTERN) \
> -          $(JDK_IMAGE_HOMEDIR)/demo/%
> +          $(JDK_IMAGE_HOMEDIR)/demo/% \
>            , \
>            $(ALL_JDK_FILES) \
>        )
>
> Already reviewed in person by erikj.  I am sending to the open build 
> list to complete the loop.
>
> Thanks in advance-
>
> Tim



From bradford.wetmore at oracle.com  Wed May 10 22:08:02 2017
From: bradford.wetmore at oracle.com (Brad R. Wetmore)
Date: Wed, 10 May 2017 15:08:02 -0700
Subject: RFR: XS: URGENT: JDK-8180129, , Bundles.gmk:181: *** unterminated
 call to function 'filter-out': missing ')'
In-Reply-To: <59138ED5.9070609@oracle.com>
References: <59138ED5.9070609@oracle.com>
Message-ID: <f1ddd9a4-b24a-976e-fe42-54aaeac5edf8@oracle.com>

Looks good.

Brad


On 5/10/2017 3:06 PM, Tim Bell wrote:
> A fix for packaging changes in the closed files missed one line
> continuation in an open file, and without this all builds fail:
>
> % hg diff
> diff --git a/make/Bundles.gmk b/make/Bundles.gmk
> --- a/make/Bundles.gmk
> +++ b/make/Bundles.gmk
> @@ -183,7 +183,7 @@
>            $(JDK_SYMBOLS_EXCLUDE_PATTERN) \
>            $(JDK_EXTRA_EXCLUDES) \
>            $(SYMBOLS_EXCLUDE_PATTERN) \
> -          $(JDK_IMAGE_HOMEDIR)/demo/%
> +          $(JDK_IMAGE_HOMEDIR)/demo/% \
>            , \
>            $(ALL_JDK_FILES) \
>        )
>
> Already reviewed in person by erik.  I am sending to the open build
> list to complete the loop.
>
> Thanks in advance-
>
> Tim


From erik.joelsson at oracle.com  Wed May 10 22:14:19 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 10 May 2017 15:14:19 -0700
Subject: RFR: JDK-8180083: Adjust Jib and JDL configurations for 9 to support
 new generation Mach 5
Message-ID: <a52a0a94-10db-9457-d9d1-4d23a21b4dcf@oracle.com>

This patch contains adjustments for the jib-profiles.js configuration 
needed for supporting the next generation Oracle internal build and test 
system. This is largely the same changes as in 8180081 for JDK 10.

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

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

/Erik



From tim.bell at oracle.com  Thu May 11 01:09:22 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 10 May 2017 18:09:22 -0700
Subject: RFR: JDK-8180081: Adjust Jib and JDL configuration for 10 to
 support promotable builds
In-Reply-To: <709FA5DF-6C5D-45ED-BFC1-3EFA0BC36433@oracle.com>
References: <c4e5b603-4a61-42fb-6168-fbd964c8d8a2@oracle.com>
 <709FA5DF-6C5D-45ED-BFC1-3EFA0BC36433@oracle.com>
Message-ID: <5913B9C2.1080603@oracle.com>

Erik:

Looks good to me as well.

Tim

On 05/10/17 14:26, Christian Tornqvist wrote:
> Hi Erik,
>
> This looks good, thanks for fixing this!
>
> Thanks,
> Christian
>
>> On May 10, 2017, at 2:12 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> This patch contains adjustments for the jib-profiles.js configuration needed for supporting the next generation Oracle internal build and test system.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180081
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8180081/webrev.01/
>>
>> /Erik
>>
>



From tim.bell at oracle.com  Thu May 11 01:19:35 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 10 May 2017 18:19:35 -0700
Subject: RFR: JDK-8180083: Adjust Jib and JDL configurations for 9 to
 support new generation Mach 5
In-Reply-To: <a52a0a94-10db-9457-d9d1-4d23a21b4dcf@oracle.com>
References: <a52a0a94-10db-9457-d9d1-4d23a21b4dcf@oracle.com>
Message-ID: <5913BC27.1010904@oracle.com>

Erik:

> This patch contains adjustments for the jib-profiles.js configuration
> needed for supporting the next generation Oracle internal build and test
> system. This is largely the same changes as in 8180081 for JDK 10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180083
>
> Webrev: http://cr.openjdk.java.net/~erikj/8180083/webrev.01/

Looks good.

Tim




From david.holmes at oracle.com  Thu May 11 02:19:57 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 11 May 2017 12:19:57 +1000
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <59134B6A.7090504@oracle.com>
References: <59134312.6070701@oracle.com>
 <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
 <59134B6A.7090504@oracle.com>
Message-ID: <b2689382-8c82-528c-6e03-a598f601d240@oracle.com>

On 11/05/2017 3:18 AM, Kumar Srinivasan wrote:
>
> On 5/10/2017 9:51 AM, Erik Joelsson wrote:
>> Should this be set on the javadoc command line somewhere or am I
>> missing something?
>
> Yes, one would have to set this prop, via the build system, when
> performing a non-oracle build.

Shouldn't that be inverted then - given there is only 1 Oracle build and 
potentially innumerable non-Oracle builds? The default should be to not 
link unless the property is set.

Thanks,
David

> Kumar
>
>>
>> /Erik
>>
>>
>> On 2017-05-10 09:42, Kumar Srinivasan wrote:
>>> Hi,
>>>
>>> Please review fix for the custom taglet to allow openjdk builds, in
>>> which case
>>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to
>>> inhibit server
>>> side lookups.
>>>
>>> Thanks
>>> Kumar
>>>
>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915
>>
>


From magnus.ihse.bursie at oracle.com  Thu May 11 12:56:57 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 11 May 2017 14:56:57 +0200
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP 299
Message-ID: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>

In preparation for JDK-8178317, the existing man page troff sources will 
be moved to their corresponding modules, according to the layout 
determined by JEP 299. During the docs build, they will be copied to the 
man directory in the docs image, as specified by JEP 299. No markdown 
conversion will be done for now, though.

Note that this will only apply to OpenJDK, not the Oracle JDK, which do 
not ship the man pages from the OpenJDK repository. (This has not been 
the case since at least JDK 8.) Also note that the man pages themselves 
have not been updated. I did update "JDK 8" to "JDK 9", but I have made 
no other changes. Nevertheless, I believe having man pages (even if 
outdated) is better for the community than not having man pages.

The jhat and jsadebug tools have been removed in JDK 9, so I removed 
these man pages as well.

Prior to this reorganisation, the man pages were duplicated in three 
directories, one for each of solaris, linux and bsd. I have verified 
that for the remaining man pages, there were no substantial difference 
between these versions.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01

/Magnus



From Roger.Riggs at Oracle.com  Thu May 11 13:31:18 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 11 May 2017 09:31:18 -0400
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <59134312.6070701@oracle.com>
References: <59134312.6070701@oracle.com>
Message-ID: <f7b9212d-8f86-697f-7b10-f942a242ee2c@Oracle.com>

Hi,

That's a pretty cryptic property, where will it be documented? Release 
noted?

Is there any build option to set it so someone doesn't have to 
circumvent the build system
to get the effect?

Thanks, Roger

On 5/10/2017 12:42 PM, Kumar Srinivasan wrote:
> Hi,
>
> Please review fix for the custom taglet to allow openjdk builds, in 
> which case
> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to 
> inhibit server
> side lookups.
>
> Thanks
> Kumar
>
> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915



From magnus.ihse.bursie at oracle.com  Thu May 11 13:31:18 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 11 May 2017 15:31:18 +0200
Subject: RFR: JDK-8180081: Adjust Jib and JDL configuration for 10 to
 support promotable builds
In-Reply-To: <c4e5b603-4a61-42fb-6168-fbd964c8d8a2@oracle.com>
References: <c4e5b603-4a61-42fb-6168-fbd964c8d8a2@oracle.com>
Message-ID: <917f85e7-7df2-a4b5-d881-0b4d2c489093@oracle.com>

Looks good to me.

/Magnus

On 2017-05-10 23:12, Erik Joelsson wrote:
> This patch contains adjustments for the jib-profiles.js configuration 
> needed for supporting the next generation Oracle internal build and 
> test system.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180081
>
> Webrev: http://cr.openjdk.java.net/~erikj/8180081/webrev.01/
>
> /Erik
>



From magnus.ihse.bursie at oracle.com  Thu May 11 13:31:37 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 11 May 2017 15:31:37 +0200
Subject: RFR: JDK-8180083: Adjust Jib and JDL configurations for 9 to
 support new generation Mach 5
In-Reply-To: <a52a0a94-10db-9457-d9d1-4d23a21b4dcf@oracle.com>
References: <a52a0a94-10db-9457-d9d1-4d23a21b4dcf@oracle.com>
Message-ID: <9f9d7eca-69c7-3352-eef2-877e93681036@oracle.com>

Looks good to me.

/Magnus

On 2017-05-11 00:14, Erik Joelsson wrote:
> This patch contains adjustments for the jib-profiles.js configuration 
> needed for supporting the next generation Oracle internal build and 
> test system. This is largely the same changes as in 8180081 for JDK 10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180083
>
> Webrev: http://cr.openjdk.java.net/~erikj/8180083/webrev.01/
>
> /Erik
>



From erik.joelsson at oracle.com  Thu May 11 15:58:56 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 11 May 2017 08:58:56 -0700
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
Message-ID: <35d3bc81-5258-ee32-0b50-fe5c19b4c935@oracle.com>

Looks like this follows JEP 299 so OK by me. I do find it a bit strange 
that we move the man pages out of the JDK/JRE images though.

/Erik


On 2017-05-11 05:56, Magnus Ihse Bursie wrote:
> In preparation for JDK-8178317, the existing man page troff sources 
> will be moved to their corresponding modules, according to the layout 
> determined by JEP 299. During the docs build, they will be copied to 
> the man directory in the docs image, as specified by JEP 299. No 
> markdown conversion will be done for now, though.
>
> Note that this will only apply to OpenJDK, not the Oracle JDK, which 
> do not ship the man pages from the OpenJDK repository. (This has not 
> been the case since at least JDK 8.) Also note that the man pages 
> themselves have not been updated. I did update "JDK 8" to "JDK 9", but 
> I have made no other changes. Nevertheless, I believe having man pages 
> (even if outdated) is better for the community than not having man pages.
>
> The jhat and jsadebug tools have been removed in JDK 9, so I removed 
> these man pages as well.
>
> Prior to this reorganisation, the man pages were duplicated in three 
> directories, one for each of solaris, linux and bsd. I have verified 
> that for the remaining man pages, there were no substantial difference 
> between these versions.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>
> /Magnus
>



From kumar.x.srinivasan at oracle.com  Thu May 11 20:00:28 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 11 May 2017 13:00:28 -0700
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <f7b9212d-8f86-697f-7b10-f942a242ee2c@Oracle.com>
References: <59134312.6070701@oracle.com>
 <f7b9212d-8f86-697f-7b10-f942a242ee2c@Oracle.com>
Message-ID: <5914C2DC.8010705@oracle.com>


Hi Roger,

This is a build tool, ie. a tool used by the build system, potentially
could be documented in the build notes.

Kumar

> Hi,
>
> That's a pretty cryptic property, where will it be documented? Release 
> noted?
>
> Is there any build option to set it so someone doesn't have to 
> circumvent the build system
> to get the effect?
>
> Thanks, Roger
>
> On 5/10/2017 12:42 PM, Kumar Srinivasan wrote:
>> Hi,
>>
>> Please review fix for the custom taglet to allow openjdk builds, in 
>> which case
>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to 
>> inhibit server
>> side lookups.
>>
>> Thanks
>> Kumar
>>
>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915
>



From kumar.x.srinivasan at oracle.com  Thu May 11 20:51:03 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 11 May 2017 13:51:03 -0700
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <b2689382-8c82-528c-6e03-a598f601d240@oracle.com>
References: <59134312.6070701@oracle.com>
 <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
 <59134B6A.7090504@oracle.com>
 <b2689382-8c82-528c-6e03-a598f601d240@oracle.com>
Message-ID: <5914CEB7.5080505@oracle.com>

Hi,

Changes in this webrev:
* inverted the logic as you suggested
* some doc comment changes to reflect the change

http://cr.openjdk.java.net/~ksrini/8179915/webrev.1/

Thanks
Kumar

On 5/10/2017 7:19 PM, David Holmes wrote:
> On 11/05/2017 3:18 AM, Kumar Srinivasan wrote:
>>
>> On 5/10/2017 9:51 AM, Erik Joelsson wrote:
>>> Should this be set on the javadoc command line somewhere or am I
>>> missing something?
>>
>> Yes, one would have to set this prop, via the build system, when
>> performing a non-oracle build.
>
> Shouldn't that be inverted then - given there is only 1 Oracle build 
> and potentially innumerable non-Oracle builds? The default should be 
> to not link unless the property is set.
>
> Thanks,
> David
>
>> Kumar
>>
>>>
>>> /Erik
>>>
>>>
>>> On 2017-05-10 09:42, Kumar Srinivasan wrote:
>>>> Hi,
>>>>
>>>> Please review fix for the custom taglet to allow openjdk builds, in
>>>> which case
>>>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to
>>>> inhibit server
>>>> side lookups.
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915
>>>
>>



From Roger.Riggs at Oracle.com  Thu May 11 21:07:24 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 11 May 2017 17:07:24 -0400
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <5914CEB7.5080505@oracle.com>
References: <59134312.6070701@oracle.com>
 <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
 <59134B6A.7090504@oracle.com>
 <b2689382-8c82-528c-6e03-a598f601d240@oracle.com>
 <5914CEB7.5080505@oracle.com>
Message-ID: <8854108f-f9a7-49e4-e43f-437a6bc85be7@Oracle.com>

Hi,

I would generalize it just a bit by taking the URL from the system property;
if the property was set it would use the URL and if not generate the 
citation.
Then the taglet could be used a bit more broadly without complicating 
the build or code.

$.02, Roger


On 5/11/2017 4:51 PM, Kumar Srinivasan wrote:
> Hi,
>
> Changes in this webrev:
> * inverted the logic as you suggested
> * some doc comment changes to reflect the change
>
> http://cr.openjdk.java.net/~ksrini/8179915/webrev.1/
>
> Thanks
> Kumar
>
> On 5/10/2017 7:19 PM, David Holmes wrote:
>> On 11/05/2017 3:18 AM, Kumar Srinivasan wrote:
>>>
>>> On 5/10/2017 9:51 AM, Erik Joelsson wrote:
>>>> Should this be set on the javadoc command line somewhere or am I
>>>> missing something?
>>>
>>> Yes, one would have to set this prop, via the build system, when
>>> performing a non-oracle build.
>>
>> Shouldn't that be inverted then - given there is only 1 Oracle build 
>> and potentially innumerable non-Oracle builds? The default should be 
>> to not link unless the property is set.
>>
>> Thanks,
>> David
>>
>>> Kumar
>>>
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-05-10 09:42, Kumar Srinivasan wrote:
>>>>> Hi,
>>>>>
>>>>> Please review fix for the custom taglet to allow openjdk builds, in
>>>>> which case
>>>>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to
>>>>> inhibit server
>>>>> side lookups.
>>>>>
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915
>>>>
>>>
>



From jonathan.gibbons at oracle.com  Thu May 11 21:21:52 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 May 2017 14:21:52 -0700
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <8854108f-f9a7-49e4-e43f-437a6bc85be7@Oracle.com>
References: <59134312.6070701@oracle.com>
 <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
 <59134B6A.7090504@oracle.com>
 <b2689382-8c82-528c-6e03-a598f601d240@oracle.com>
 <5914CEB7.5080505@oracle.com>
 <8854108f-f9a7-49e4-e43f-437a6bc85be7@Oracle.com>
Message-ID: <5914D5F0.3060607@oracle.com>

Roger,

We discussed this in the original design.  This is a JDK-specific 
taglet, for use in the JDK-build,
for building JDK API-specifications, that may or may not link to some 
commercial documentation.

There is no intent to support {@extLink} for anything outside its 
limited use in the JDK API
documentation. The whole mechanism of using a query URL like this, and 
the set of names
that is defined, is highly specific to this one usage.

Given this limited usage, is it really helpful to generalize it so that 
we move the base URL from
one place in the JDK build infrastructure to another?

We seem to be in a bikeshed.

-- Jon

On 05/11/2017 02:07 PM, Roger Riggs wrote:
> Hi,
>
> I would generalize it just a bit by taking the URL from the system 
> property;
> if the property was set it would use the URL and if not generate the 
> citation.
> Then the taglet could be used a bit more broadly without complicating 
> the build or code.
>
> $.02, Roger
>
>
> On 5/11/2017 4:51 PM, Kumar Srinivasan wrote:
>> Hi,
>>
>> Changes in this webrev:
>> * inverted the logic as you suggested
>> * some doc comment changes to reflect the change
>>
>> http://cr.openjdk.java.net/~ksrini/8179915/webrev.1/
>>
>> Thanks
>> Kumar
>>
>> On 5/10/2017 7:19 PM, David Holmes wrote:
>>> On 11/05/2017 3:18 AM, Kumar Srinivasan wrote:
>>>>
>>>> On 5/10/2017 9:51 AM, Erik Joelsson wrote:
>>>>> Should this be set on the javadoc command line somewhere or am I
>>>>> missing something?
>>>>
>>>> Yes, one would have to set this prop, via the build system, when
>>>> performing a non-oracle build.
>>>
>>> Shouldn't that be inverted then - given there is only 1 Oracle build 
>>> and potentially innumerable non-Oracle builds? The default should be 
>>> to not link unless the property is set.
>>>
>>> Thanks,
>>> David
>>>
>>>> Kumar
>>>>
>>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>> On 2017-05-10 09:42, Kumar Srinivasan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review fix for the custom taglet to allow openjdk builds, in
>>>>>> which case
>>>>>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to
>>>>>> inhibit server
>>>>>> side lookups.
>>>>>>
>>>>>> Thanks
>>>>>> Kumar
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915
>>>>>
>>>>
>>
>



From mandy.chung at oracle.com  Thu May 11 22:38:48 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 May 2017 15:38:48 -0700
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
Message-ID: <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>

Magnus,

I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.

Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].  

If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8167558

> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
> 
> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
> 
> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
> 
> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
> 
> /Magnus
> 



From mandy.chung at oracle.com  Thu May 11 22:58:52 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 May 2017 15:58:52 -0700
Subject: Review Request: JDK-8180208  Provide a new docs bundle page
Message-ID: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>

The old docs bundle page (aka layer cake) is legacy and not maintained.  In JDK 9, we replace it with a simple page listing modules by groups.  This page can continuously be improved.

   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html

This is generated by a build tool.  Webrev at:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/index.html

The makefile generates this page in docs-index.html.

Magnus - we will follow up whether you or I make the change to replace index.html. 

thanks
Mandy

From jonathan.gibbons at oracle.com  Thu May 11 23:08:52 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 May 2017 16:08:52 -0700
Subject: Review Request: JDK-8180208  Provide a new docs bundle page
In-Reply-To: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
Message-ID: <5914EF04.303@oracle.com>

Mandy,

The <html> tag on line 2 of
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/jdk/make/src/classes/build/tools/docs/docs-bundle-page.html.html

should have
     lang="en"

One line 50,
     class="striped" is unnecessary, since we are not referring to a 
class in a stylesheet. The inline style in the <head> takes care of 
everything.

-- Jon

On 05/11/2017 03:58 PM, Mandy Chung wrote:
> The old docs bundle page (aka layer cake) is legacy and not maintained.  In JDK 9, we replace it with a simple page listing modules by groups.  This page can continuously be improved.
>
>     http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html
>
> This is generated by a build tool.  Webrev at:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/index.html
>
> The makefile generates this page in docs-index.html.
>
> Magnus - we will follow up whether you or I make the change to replace index.html.
>
> thanks
> Mandy



From erik.joelsson at oracle.com  Fri May 12 00:44:57 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 11 May 2017 17:44:57 -0700
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
Message-ID: <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>



On 2017-05-11 15:38, Mandy Chung wrote:
> Magnus,
>
> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
My quick skimming through JEP 299 led me to think this was indeed the 
intention, at least as placeholders until better documentation can be 
provided.
> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
The jmods will add man pages if there are any in support/modules_man but 
I know of now part of the build process that ever puts man pages in 
there. The man pages in the jdk/jre images are still copied into the 
image using manual makefile copy in Images.gmk.
> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
We currently only copy man pages into the jdk/jre images when building 
OpenJDK and not when building OracleJDK.

/Erik
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>
>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>
>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>
>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>
>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>
>> /Magnus
>>



From jonathan.gibbons at oracle.com  Fri May 12 00:54:21 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 May 2017 17:54:21 -0700
Subject: RFR: JDK-8180178 Restructure existing man pages according to
 JEP 299
In-Reply-To: <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
Message-ID: <591507BD.5010001@oracle.com>



On 05/11/2017 05:44 PM, Erik Joelsson wrote:
>
> On 2017-05-11 15:38, Mandy Chung wrote:
>> Magnus,
>>
>> I?m surprised to see the man pages are moved to src/$MODULE/share/man 
>> directory.  These man pages are not maintained and not updated. It?s 
>> agreed that the man pages are specification for the tools that we 
>> should write and include in the source under src/$MODULE/share/man 
>> directory.  However, it?s not intended to move these unmaintained man 
>> page to the source.
> My quick skimming through JEP 299 led me to think this was indeed the 
> intention, at least as placeholders until better documentation can be 
> provided. 

That was the original intent when we (optimistically) thought that we 
would have time to do a pass over these docs to bring them up to date 
for JDK 9.

-- jon


From weijun.wang at oracle.com  Fri May 12 02:25:48 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 12 May 2017 10:25:48 +0800
Subject: Review Request: JDK-8180208 Provide a new docs bundle page
In-Reply-To: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
Message-ID: <f2f380c0-2792-2fb4-8a03-91cc80397cf8@oracle.com>


On 05/12/2017 06:58 AM, Mandy Chung wrote:
> The old docs bundle page (aka layer cake) is legacy and not maintained.  In JDK 9, we replace it with a simple page listing modules by groups.  This page can continuously be improved.
>
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html

jdk.crypto.mscapi is not listed.

--Max

>
> This is generated by a build tool.  Webrev at:
>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/index.html
>
> The makefile generates this page in docs-index.html.
>
> Magnus - we will follow up whether you or I make the change to replace index.html.
>
> thanks
> Mandy
>


From mandy.chung at oracle.com  Fri May 12 02:41:48 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 May 2017 19:41:48 -0700
Subject: Review Request: JDK-8180208 Provide a new docs bundle page
In-Reply-To: <f2f380c0-2792-2fb4-8a03-91cc80397cf8@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
 <f2f380c0-2792-2fb4-8a03-91cc80397cf8@oracle.com>
Message-ID: <7CF664B6-D5C4-48EC-AD96-23FFFA7D0B5C@oracle.com>


> On May 11, 2017, at 7:25 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> On 05/12/2017 06:58 AM, Mandy Chung wrote:
>> The old docs bundle page (aka layer cake) is legacy and not maintained.  In JDK 9, we replace it with a simple page listing modules by groups.  This page can continuously be improved.
>> 
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html
> 
> jdk.crypto.mscapi is not listed.

jdk.crypto.mscapi and jdk.crypto.ucrypto are platform-specific.  We need to figure a better way to include the platform-specific in a docs bundle.  We will address that in JDK 10.  They are mentioned in existing documentations today and so no change in that regards.

Mandy

From mandy.chung at oracle.com  Fri May 12 02:57:04 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 May 2017 19:57:04 -0700
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
Message-ID: <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>


> On May 11, 2017, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> 
> 
> On 2017-05-11 15:38, Mandy Chung wrote:
>> Magnus,
>> 
>> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
> My quick skimming through JEP 299 led me to think this was indeed the intention, at least as placeholders until better documentation can be provided.

Jon already clarified.  That?s the original intent but had to defer it to JDK 10 due to the time we have.

>> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
> The jmods will add man pages if there are any in support/modules_man but I know of now part of the build process that ever puts man pages in there. The man pages in the jdk/jre images are still copied into the image using manual makefile copy in Images.gmk.

Hmm?  At that time we might have thought to wait for JEP 299 to do the man pages work.  I added the jmod and jlink mechanism and waited for the man pages be converted to the source form.

>> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
> We currently only copy man pages into the jdk/jre images when building OpenJDK and not when building OracleJDK.
> 

We have to decide what to do with the man pages for OpenJDK build:
1) copy to jdk/jre image as is.
  These man pages are out dated.  Copying by default seems not good.
2) a configure option to enable copying man pages.  Default no man page.

other options?

Mandy

> /Erik
>> Mandy
>> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>> 
>>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>> 
>>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>> 
>>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>> 
>>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>> 
>>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>> 
>>> /Magnus
>>> 
> 



From mandy.chung at oracle.com  Fri May 12 03:00:19 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 May 2017 20:00:19 -0700
Subject: Review Request: JDK-8180208  Provide a new docs bundle page
In-Reply-To: <5914EF04.303@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
 <5914EF04.303@oracle.com>
Message-ID: <D638916E-46CC-462D-A084-655ED6FB1042@oracle.com>


> On May 11, 2017, at 4:08 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Mandy,
> 
> The <html> tag on line 2 of
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/jdk/make/src/classes/build/tools/docs/docs-bundle-page.html.html
> 
> should have
>    lang=?en"
> 

Fixed.

> One line 50,
>    class="striped" is unnecessary, since we are not referring to a class in a stylesheet. The inline style in the <head> takes care of everything.

Leftover from previous edit.  Removed.

Webrev with updated module grouping:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.01/

Updated doc bundle page:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html

Mandy

From david.holmes at oracle.com  Fri May 12 03:21:00 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 May 2017 13:21:00 +1000
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
 <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
Message-ID: <1c993b11-7f3e-c96d-e110-f78a353822c6@oracle.com>

Sorry but:

 > Nevertheless, I believe having man pages (even if outdated) is
 > better for the community than not having man pages.

is not something I can agree with at all. This seems quite a ridiculous 
situation. We have not updated and maintained these manpages, they have 
been slated for removal - indeed I thought they already had been 
removed, yet we're now proposing to include them in OpenJDK builds - 
why?? The only thing worse than no documentation is out-of-date, 
incorrect documentation - which is what these man pages are!

David
-----

On 12/05/2017 12:57 PM, Mandy Chung wrote:
>
>> On May 11, 2017, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>>
>>
>> On 2017-05-11 15:38, Mandy Chung wrote:
>>> Magnus,
>>>
>>> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
>> My quick skimming through JEP 299 led me to think this was indeed the intention, at least as placeholders until better documentation can be provided.
>
> Jon already clarified.  That?s the original intent but had to defer it to JDK 10 due to the time we have.
>
>>> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
>> The jmods will add man pages if there are any in support/modules_man but I know of now part of the build process that ever puts man pages in there. The man pages in the jdk/jre images are still copied into the image using manual makefile copy in Images.gmk.
>
> Hmm?  At that time we might have thought to wait for JEP 299 to do the man pages work.  I added the jmod and jlink mechanism and waited for the man pages be converted to the source form.
>
>>> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
>> We currently only copy man pages into the jdk/jre images when building OpenJDK and not when building OracleJDK.
>>
>
> We have to decide what to do with the man pages for OpenJDK build:
> 1) copy to jdk/jre image as is.
>   These man pages are out dated.  Copying by default seems not good.
> 2) a configure option to enable copying man pages.  Default no man page.
>
> other options?
>
> Mandy
>
>> /Erik
>>> Mandy
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>>>
>>>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>>
>>>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>>>
>>>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>>>
>>>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>>>
>>>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>>>
>>>> /Magnus
>>>>
>>
>


From magnus.ihse.bursie at oracle.com  Fri May 12 06:51:26 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 08:51:26 +0200
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
 <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
Message-ID: <CC719FC8-D4DD-4FD1-96D0-055C8D36737F@oracle.com>

(Sorry if this is a bit TL, please don't DR though...)

Good we started clearing this up!

Let me start with a recap of the current situation:

The man pages exist in the source code in OpenJDK. During the build, they get copied to the JRE and JDK image, in the normal OpenJDK build. (Let me remind you that this is an OpenJDK list, so what we're discussing here is, by default, OpenJDK.)

In the Oracle JDK, some additional code has been added that actively filters out the man pages from the image. 

The net effect is that the OpenJDK build includes these man pages, while the Oracle JDK does not. 

At some point in time, during JDK 8 I think, Oracle started doing this filtering. As a consequence, we suggested deleting the man pages. This was, as I remember it, met by opposition from other parts of the community. It ended up with the man pages remaining, and a declaration from Oracle that the man pages will not be updated by Oracle, and that the rest of the community needed to step up to keep this up to date. 

As far as I know, no contributions have been made to the man pages during this period. 

This leaves us at today. That means that if we do nothing, we (meaning the OpenJDK project) will ship the same man pages as we did in JDK 8. (Note that the discussion what *Oracle* ships is different, and need to be conducted in a different forum.)

Since the rest of the community previously preferred to have any man pages, even if they were out of date, rather than to have none, I presume this still is the case. It would be good to have some input on this assumption, though, from e.g. Red Hat. 

So, the first decision we need to make is:
1) should we keep the man pages as they are?
2) should we remove them completely?
3) should we keep the man pages and update them?

Unfortunately, option 3 which should have been the winner, is out of the question due to time constraints. 

The default route (doing nothing) is selecting option 1, and so does this patch. Anyone opting for option 2, need to file a bug to remove the man pages. 

My vote is definitely for option 1. It's the rare documentation that's completely up to date, and in most cases some documentation is better than none. I know I'd be pissed if I couldn't type "man javac" in my OpenJDK installation on Ubuntu. I acknowledge that there have been some substantial changes in JDK to some of the central tools, but most of the tools are unchanged, and even for java and javac, the vast majority  of the options and descriptions still apply. 

The second part of the question is, given that option 1 above is followed, where should the man pages reside in the source tree, and where should it end up in the output? If option 2 is chosen, the rest of this discussion can be skipped. 

JEP 299 clearly states a place in the source tree for man pages. While it  says that man pages should be in markdown format, it also includes a caveat saying that actual conversation of the man pages to markdown is a non-goal of the JEP. From a build perspective, it makes sense to look at all files in the $module/man directories, and if the file is in markdown, convert it (I have this code in a sandbox, and I had planned to post that as a follow-up), or if it's in troff format, just copy it. 

So this patch is the first step of the build requirements on man pages as stated in JEP 299. 

Given that we should keep these files, I see no reason not to move them to the location given by JEP 299. I really hope there is no opposition to this part, at least. 

The final question is about where to store the man pages in the output. Previously, they have been part of the JDK and JRE images. Since JEP 299 states that man pages should be part of the docs image, I assume it meant that they should be removed from the JDK/JRE images, since it does not make sense to have it in two places. 

The ability of jlink to include man pages was news to me. This is not mentioned in JEP 299, nor used in the current build. I assume this is a remnant from previous thinking, prior to JEP 299. 

Frankly, I'm a bit surprised by the buzz this patch has generated. I think most of it stems from the confusion between OpenJDK and Oracle JDK, where it has not been apparent to all Oracle employees that what Oracle ships differs in this respect from what OpenJDK ships. And once again, this patch is not about what Oracle will ship, but OpenJDK. 

/Magnus

> 12 maj 2017 kl. 04:57 skrev Mandy Chung <mandy.chung at oracle.com>:
> 
> 
>> On May 11, 2017, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> 
>> 
>> 
>>> On 2017-05-11 15:38, Mandy Chung wrote:
>>> Magnus,
>>> 
>>> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
>> My quick skimming through JEP 299 led me to think this was indeed the intention, at least as placeholders until better documentation can be provided.
> 
> Jon already clarified.  That?s the original intent but had to defer it to JDK 10 due to the time we have.
> 
>>> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
>> The jmods will add man pages if there are any in support/modules_man but I know of now part of the build process that ever puts man pages in there. The man pages in the jdk/jre images are still copied into the image using manual makefile copy in Images.gmk.
> 
> Hmm?  At that time we might have thought to wait for JEP 299 to do the man pages work.  I added the jmod and jlink mechanism and waited for the man pages be converted to the source form.
> 
>>> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
>> We currently only copy man pages into the jdk/jre images when building OpenJDK and not when building OracleJDK.
> 
> We have to decide what to do with the man pages for OpenJDK build:
> 1) copy to jdk/jre image as is.
>  These man pages are out dated.  Copying by default seems not good.
> 2) a configure option to enable copying man pages.  Default no man page.
> 
> other options?
> 
> Mandy
> 
>> /Erik
>>> Mandy
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>>> 
>>>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>> 
>>>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>>> 
>>>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>>> 
>>>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>>> 
>>>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>>> 
>>>> /Magnus
> 



From magnus.ihse.bursie at oracle.com  Fri May 12 07:16:26 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 09:16:26 +0200
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <5914CEB7.5080505@oracle.com>
References: <59134312.6070701@oracle.com>
 <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
 <59134B6A.7090504@oracle.com>
 <b2689382-8c82-528c-6e03-a598f601d240@oracle.com>
 <5914CEB7.5080505@oracle.com>
Message-ID: <755A3DBA-BC9E-433B-82C2-8E2D94DF56B1@oracle.com>

Kumar,

This was not an improvement. This will require additional changes in the build system to avoid a regression. I see no reason for that. 

In fact, I propose we close the bug as WNF. Let me elaborate. 

The problem here is that Oracle has dual roles: partly as a contributor to OpenJDK, and partly as a independent company that wants to contribute to the Java ecosystem outside of the OpenJDK project. 

To Oracle's credit, most of the documentation provided goes into the OpenJDK project (and repositories). For some reason or reasons, Oracle chose to not so so with all Java-related documentation, typically user guides etc. 

The crucial question is then: should the OpenJDK documentation point to the (proprietary) Oracle documentation?

From the OpenJDK perspective, the ideal would be if the documentation was included with the OpenJDK distribution, but if that is not going to happen, then what is the best for the project?

I would argue that it is still better to link to the Oracle documents than to not do it. We have no qualms linking to other third party sites where suitable and helpful to the reader, and this is no different. 

(Yes, I have changed my opinion about this.)

This is not a question about what the Oracle JDK will do, since it will definitely link to the Oracle guides no matter what. What I'm thinking of is if the OpenJDK in any way would be considered helped by *not* linking to publicly available documentation on Oracle's web site. I can't see any such reason, and therefore, I see no reason not to link, making this addition unnecessary. 

That said, I hope that in due time, Oracle will consider adding more of the documentation to the OpenJDK project, if it seems reasonable that it belongs here. 

/Magnus

> 11 maj 2017 kl. 22:51 skrev Kumar Srinivasan <kumar.x.srinivasan at oracle.com>:
> 
> Hi,
> 
> Changes in this webrev:
> * inverted the logic as you suggested
> * some doc comment changes to reflect the change
> 
> http://cr.openjdk.java.net/~ksrini/8179915/webrev.1/
> 
> Thanks
> Kumar
> 
>> On 5/10/2017 7:19 PM, David Holmes wrote:
>>> On 11/05/2017 3:18 AM, Kumar Srinivasan wrote:
>>> 
>>>> On 5/10/2017 9:51 AM, Erik Joelsson wrote:
>>>> Should this be set on the javadoc command line somewhere or am I
>>>> missing something?
>>> 
>>> Yes, one would have to set this prop, via the build system, when
>>> performing a non-oracle build.
>> 
>> Shouldn't that be inverted then - given there is only 1 Oracle build and potentially innumerable non-Oracle builds? The default should be to not link unless the property is set.
>> 
>> Thanks,
>> David
>> 
>>> Kumar
>>> 
>>>> 
>>>> /Erik
>>>> 
>>>> 
>>>>> On 2017-05-10 09:42, Kumar Srinivasan wrote:
>>>>> Hi,
>>>>> 
>>>>> Please review fix for the custom taglet to allow openjdk builds, in
>>>>> which case
>>>>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to
>>>>> inhibit server
>>>>> side lookups.
>>>>> 
>>>>> Thanks
>>>>> Kumar
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915
> 



From magnus.ihse.bursie at oracle.com  Fri May 12 10:08:31 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 12:08:31 +0200
Subject: RFR: JDK-8180281 --with-jtreg is broken for many use cases
Message-ID: <748e7e58-4dba-3901-ecd8-7fea3ade41c8@oracle.com>

JDK-8179537 was opened with a request to document the brokenness of 
--with-jtreg. Better to fix it than to document how it's broken.

Now --with-jtreg works like this:
  * --without-jtreg will explicitly disable jtreg.
  * --with-jtreg=<jtreg home> will use the specified directory, and will 
do sanity checks that it is indeed a jtreg home pointed to, and not a 
binary.
* When no option is given, we try to locate jtreg using JT_HOME from the 
environment, and, failing that, by finding the jtreg executable in the 
path and deriving a JT_HOME from that. If not found, jtreg will be disabled.
* --with-jtreg (with no arguments) will try to locate jtreg 
automatically as described above, but if it fails, it will abort configure.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180281
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8180281-with-jtreg-is-broken/webrev.01

/Magnus


From p.tommaso at gmail.com  Fri May 12 10:12:11 2017
From: p.tommaso at gmail.com (Tommaso Pasini)
Date: Fri, 12 May 2017 12:12:11 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
Message-ID: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>

Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max OS X
Sierra.
I was able to configure but when I run the command make clean install, it
stops with this error:

hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
> instantiation of variable 'TreeChunk<FreeChunk, AdaptiveFreeList<FreeChunk>
> >::_min_tree_chunk_size' required here, but no definition is available
> [-Werror,-Wundefined-var-template]
>
>     return _min_tree_chunk_size;
>
>
I checked the file and the variable is declared few lines before. I'm not
an expert of C++ and I'm not finding anything on the web.

Does anybody already faced this problem?

Thanks,
--Tommaso


From magnus.ihse.bursie at oracle.com  Fri May 12 10:33:04 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 12:33:04 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
Message-ID: <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>

My recommendation is that you remove the entire output directory ("rm 
-rf build"), re-do the configuration and try again. Before removing, you 
can do "make print-configuration" to get the command line you used to 
configure.

/Magnus

On 2017-05-12 12:12, Tommaso Pasini wrote:
> Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max OS X
> Sierra.
> I was able to configure but when I run the command make clean install, it
> stops with this error:
>
> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
>> instantiation of variable 'TreeChunk<FreeChunk, AdaptiveFreeList<FreeChunk>
>>> ::_min_tree_chunk_size' required here, but no definition is available
>> [-Werror,-Wundefined-var-template]
>>
>>      return _min_tree_chunk_size;
>>
>>
> I checked the file and the variable is declared few lines before. I'm not
> an expert of C++ and I'm not finding anything on the web.
>
> Does anybody already faced this problem?
>
> Thanks,
> --Tommaso



From p.tommaso at gmail.com  Fri May 12 10:44:40 2017
From: p.tommaso at gmail.com (Tommaso Pasini)
Date: Fri, 12 May 2017 12:44:40 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
 <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
Message-ID: <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>

thanks for the answer, I tried to remove and reconfigure. Unfortunately I
still have the same issue.
This is very strange because the static variable _min_tree_chunk_size,
seams declared correctly in the class.

Tommaso Pasini

2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
>:

> My recommendation is that you remove the entire output directory ("rm -rf
> build"), re-do the configuration and try again. Before removing, you can do
> "make print-configuration" to get the command line you used to configure.
>
> /Magnus
>
>
> On 2017-05-12 12:12, Tommaso Pasini wrote:
>
>> Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max OS X
>> Sierra.
>> I was able to configure but when I run the command make clean install, it
>> stops with this error:
>>
>> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
>>
>>> instantiation of variable 'TreeChunk<FreeChunk,
>>> AdaptiveFreeList<FreeChunk>
>>>
>>>> ::_min_tree_chunk_size' required here, but no definition is available
>>>>
>>> [-Werror,-Wundefined-var-template]
>>>
>>>      return _min_tree_chunk_size;
>>>
>>>
>>> I checked the file and the variable is declared few lines before. I'm not
>> an expert of C++ and I'm not finding anything on the web.
>>
>> Does anybody already faced this problem?
>>
>> Thanks,
>> --Tommaso
>>
>
>


From david.holmes at oracle.com  Fri May 12 10:56:28 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 May 2017 20:56:28 +1000
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
 <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
 <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
Message-ID: <4f947940-1aff-30ce-522a-b591c36759b5@oracle.com>

What compiler (name and version) are you trying to use?

David

On 12/05/2017 8:44 PM, Tommaso Pasini wrote:
> thanks for the answer, I tried to remove and reconfigure. Unfortunately I
> still have the same issue.
> This is very strange because the static variable _min_tree_chunk_size,
> seams declared correctly in the class.
>
> Tommaso Pasini
>
> 2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
>> :
>
>> My recommendation is that you remove the entire output directory ("rm -rf
>> build"), re-do the configuration and try again. Before removing, you can do
>> "make print-configuration" to get the command line you used to configure.
>>
>> /Magnus
>>
>>
>> On 2017-05-12 12:12, Tommaso Pasini wrote:
>>
>>> Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max OS X
>>> Sierra.
>>> I was able to configure but when I run the command make clean install, it
>>> stops with this error:
>>>
>>> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
>>>
>>>> instantiation of variable 'TreeChunk<FreeChunk,
>>>> AdaptiveFreeList<FreeChunk>
>>>>
>>>>> ::_min_tree_chunk_size' required here, but no definition is available
>>>>>
>>>> [-Werror,-Wundefined-var-template]
>>>>
>>>>      return _min_tree_chunk_size;
>>>>
>>>>
>>>> I checked the file and the variable is declared few lines before. I'm not
>>> an expert of C++ and I'm not finding anything on the web.
>>>
>>> Does anybody already faced this problem?
>>>
>>> Thanks,
>>> --Tommaso
>>>
>>
>>


From p.tommaso at gmail.com  Fri May 12 11:02:36 2017
From: p.tommaso at gmail.com (Tommaso Pasini)
Date: Fri, 12 May 2017 13:02:36 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <4f947940-1aff-30ce-522a-b591c36759b5@oracle.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
 <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
 <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
 <4f947940-1aff-30ce-522a-b591c36759b5@oracle.com>
Message-ID: <CAJ-J8Tmn__+OipYs=VUfKqYG5BSQqJr92WNFE6gNu0APzfub2w@mail.gmail.com>

I have clang-802.0.42 installed. But I'm not 100% sure that this is what
make is using.
How can I check?

Tommaso Pasini

2017-05-12 12:56 GMT+02:00 David Holmes <david.holmes at oracle.com>:

> What compiler (name and version) are you trying to use?
>
> David
>
>
> On 12/05/2017 8:44 PM, Tommaso Pasini wrote:
>
>> thanks for the answer, I tried to remove and reconfigure. Unfortunately I
>> still have the same issue.
>> This is very strange because the static variable _min_tree_chunk_size,
>> seams declared correctly in the class.
>>
>> Tommaso Pasini
>>
>> 2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie <
>> magnus.ihse.bursie at oracle.com
>>
>>> :
>>>
>>
>> My recommendation is that you remove the entire output directory ("rm -rf
>>> build"), re-do the configuration and try again. Before removing, you can
>>> do
>>> "make print-configuration" to get the command line you used to configure.
>>>
>>> /Magnus
>>>
>>>
>>> On 2017-05-12 12:12, Tommaso Pasini wrote:
>>>
>>> Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max OS X
>>>> Sierra.
>>>> I was able to configure but when I run the command make clean install,
>>>> it
>>>> stops with this error:
>>>>
>>>> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
>>>>
>>>> instantiation of variable 'TreeChunk<FreeChunk,
>>>>> AdaptiveFreeList<FreeChunk>
>>>>>
>>>>> ::_min_tree_chunk_size' required here, but no definition is available
>>>>>>
>>>>>> [-Werror,-Wundefined-var-template]
>>>>>
>>>>>      return _min_tree_chunk_size;
>>>>>
>>>>>
>>>>> I checked the file and the variable is declared few lines before. I'm
>>>>> not
>>>>>
>>>> an expert of C++ and I'm not finding anything on the web.
>>>>
>>>> Does anybody already faced this problem?
>>>>
>>>> Thanks,
>>>> --Tommaso
>>>>
>>>>
>>>
>>>


From lenborje at gmail.com  Fri May 12 11:09:58 2017
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Fri, 12 May 2017 13:09:58 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
 <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
 <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
Message-ID: <A8E7C40C-C77E-42F7-9CE6-EEEF8D1E6A99@gmail.com>

I?ve had that error on my Mac since forever. :-/

You need to configure with "--disable-warnings-as-errors?.

You?ll then get that warning quite a few times during the build, bit it will work. (At least it does for me.)


/Lennart


> 12 maj 2017 kl. 12:44 skrev Tommaso Pasini <p.tommaso at gmail.com>:
> 
> thanks for the answer, I tried to remove and reconfigure. Unfortunately I
> still have the same issue.
> This is very strange because the static variable _min_tree_chunk_size,
> seams declared correctly in the class.
> 
> Tommaso Pasini
> 
> 2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
>> :
> 
>> My recommendation is that you remove the entire output directory ("rm -rf
>> build"), re-do the configuration and try again. Before removing, you can do
>> "make print-configuration" to get the command line you used to configure.
>> 
>> /Magnus
>> 
>> 
>> On 2017-05-12 12:12, Tommaso Pasini wrote:
>> 
>>> Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max OS X
>>> Sierra.
>>> I was able to configure but when I run the command make clean install, it
>>> stops with this error:
>>> 
>>> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
>>> 
>>>> instantiation of variable 'TreeChunk<FreeChunk,
>>>> AdaptiveFreeList<FreeChunk>
>>>> 
>>>>> ::_min_tree_chunk_size' required here, but no definition is available
>>>>> 
>>>> [-Werror,-Wundefined-var-template]
>>>> 
>>>>     return _min_tree_chunk_size;
>>>> 
>>>> 
>>>> I checked the file and the variable is declared few lines before. I'm not
>>> an expert of C++ and I'm not finding anything on the web.
>>> 
>>> Does anybody already faced this problem?
>>> 
>>> Thanks,
>>> --Tommaso
>>> 
>> 
>> 



From lenborje at gmail.com  Fri May 12 11:30:42 2017
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Fri, 12 May 2017 13:30:42 +0200
Subject: Graal missing from MacOS Java 9 EA download b167
In-Reply-To: <D90E6F4D-1246-40C9-8FF9-A7D551DB022C@oracle.com>
References: <6CF09D22-D5CC-4459-94BA-65C709523E5B@gmail.com>
 <D90E6F4D-1246-40C9-8FF9-A7D551DB022C@oracle.com>
Message-ID: <911130E2-3DD7-48CD-955B-9358F8B6165A@gmail.com>

Thank you for the response.

As I believe Graal is the most important new thing in jdk9, I?d then just want to state my opinion: Even if AOT is available only for x86_64 (and I have absolutely no problems with that), I still believe Graal should be included on all platforms. 

After all, Graal is Java, and running on all platforms is what Java is all about, isn?t it?  ;-)

(Not expecting an immediate policy change.)


Best regards,

/Lennart B?rjeson

> 5 maj 2017 kl. 19:04 skrev Sandeep Konchady <sandeep.konchady at oracle.com>:
> 
> Hi Lennart,
> 
> Feedback from development team:
> 
> In JDK 9 jdk.internal.vm.compiler module is only built on platforms which AOT supports. And it is only Linux-x64.
> We don't support Graal as JIT compiler in JDK 9. Only as compiler for AOT.
> 
> As workaround customer can download Graal from Oracle Labs and drop it into JDK. All the necessary details are in https://github.com/graalvm/graal/blob/master/compiler/README.md. Hope this helps.
> 
> Thanks,
> Sandeep
> 
>> On May 3, 2017, at 1:52 AM, Lennart B?rjeson <lenborje at gmail.com> wrote:
>> 
>> Graal (e.g. the module jdk.internal.vm.compiler) seems to be missing from the Java 9 Early-Access download for MacOS. I noticed this with b166 and it is still so in b167.
>> 
>> As it is perfectly possible (I?ve done it) to download the source, configure the build to include graal, and build it, I suspect this is possibly an oversight in the packaging of the EA on MacOS, due to that AOT is only to be supported on Linux. But graal per se should surely be included on all platforms?
>> 
>> How to test:
>> 
>> Download and install Java 9 EA. Put it on the PATH.
>> 
>> java --list-modules | grep jdk.internal.vm.compiler
>> 
>> (finds compiler on Linux; finds nothing on MacOS)
>> 
>> 
>> java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version
>> 
>> (Works on Linux; complains about "no JVMCI compiler selected" on MacOS)
> 



From magnus.ihse.bursie at oracle.com  Fri May 12 11:59:50 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 13:59:50 +0200
Subject: RFR: JDK-8180281 --with-jtreg is broken for many use cases
In-Reply-To: <748e7e58-4dba-3901-ecd8-7fea3ade41c8@oracle.com>
References: <748e7e58-4dba-3901-ecd8-7fea3ade41c8@oracle.com>
Message-ID: <1fecbed8-e9ef-8ff5-0ab7-6c0cb2acc33c@oracle.com>

It turned out that run-test behaved badly when JT_HOME was not set. 
Here's an updated version with a more helpful failure mode.

http://cr.openjdk.java.net/~ihse/JDK-8180281-with-jtreg-is-broken/webrev.02

/Magnus

On 2017-05-12 12:08, Magnus Ihse Bursie wrote:
> JDK-8179537 was opened with a request to document the brokenness of 
> --with-jtreg. Better to fix it than to document how it's broken.
>
> Now --with-jtreg works like this:
>  * --without-jtreg will explicitly disable jtreg.
>  * --with-jtreg=<jtreg home> will use the specified directory, and 
> will do sanity checks that it is indeed a jtreg home pointed to, and 
> not a binary.
> * When no option is given, we try to locate jtreg using JT_HOME from 
> the environment, and, failing that, by finding the jtreg executable in 
> the path and deriving a JT_HOME from that. If not found, jtreg will be 
> disabled.
> * --with-jtreg (with no arguments) will try to locate jtreg 
> automatically as described above, but if it fails, it will abort 
> configure.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180281
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180281-with-jtreg-is-broken/webrev.01
>
> /Magnus



From p.tommaso at gmail.com  Fri May 12 12:11:49 2017
From: p.tommaso at gmail.com (Tommaso Pasini)
Date: Fri, 12 May 2017 14:11:49 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <A8E7C40C-C77E-42F7-9CE6-EEEF8D1E6A99@gmail.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
 <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
 <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
 <A8E7C40C-C77E-42F7-9CE6-EEEF8D1E6A99@gmail.com>
Message-ID: <CAJ-J8TmwQUSEWtML+2LnTa-Z1mGJez4XquJY=pcNx-SQOV4A1A@mail.gmail.com>

ok, i suspected that Lennart, could you tell me how to set that flag?
Thanks a lot!

Tommaso Pasini

2017-05-12 13:09 GMT+02:00 Lennart B?rjeson <lenborje at gmail.com>:

> I?ve had that error on my Mac since forever. :-/
>
> You need to configure with "--disable-warnings-as-errors?.
>
> You?ll then get that warning quite a few times during the build, bit it
> will work. (At least it does for me.)
>
>
> /Lennart
>
>
> > 12 maj 2017 kl. 12:44 skrev Tommaso Pasini <p.tommaso at gmail.com>:
> >
> > thanks for the answer, I tried to remove and reconfigure. Unfortunately I
> > still have the same issue.
> > This is very strange because the static variable _min_tree_chunk_size,
> > seams declared correctly in the class.
> >
> > Tommaso Pasini
> >
> > 2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com
> >> :
> >
> >> My recommendation is that you remove the entire output directory ("rm
> -rf
> >> build"), re-do the configuration and try again. Before removing, you
> can do
> >> "make print-configuration" to get the command line you used to
> configure.
> >>
> >> /Magnus
> >>
> >>
> >> On 2017-05-12 12:12, Tommaso Pasini wrote:
> >>
> >>> Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max OS
> X
> >>> Sierra.
> >>> I was able to configure but when I run the command make clean install,
> it
> >>> stops with this error:
> >>>
> >>> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
> >>>
> >>>> instantiation of variable 'TreeChunk<FreeChunk,
> >>>> AdaptiveFreeList<FreeChunk>
> >>>>
> >>>>> ::_min_tree_chunk_size' required here, but no definition is available
> >>>>>
> >>>> [-Werror,-Wundefined-var-template]
> >>>>
> >>>>     return _min_tree_chunk_size;
> >>>>
> >>>>
> >>>> I checked the file and the variable is declared few lines before. I'm
> not
> >>> an expert of C++ and I'm not finding anything on the web.
> >>>
> >>> Does anybody already faced this problem?
> >>>
> >>> Thanks,
> >>> --Tommaso
> >>>
> >>
> >>
>
>


From p.tommaso at gmail.com  Fri May 12 12:13:31 2017
From: p.tommaso at gmail.com (Tommaso Pasini)
Date: Fri, 12 May 2017 14:13:31 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <CAJ-J8TmwQUSEWtML+2LnTa-Z1mGJez4XquJY=pcNx-SQOV4A1A@mail.gmail.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
 <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
 <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
 <A8E7C40C-C77E-42F7-9CE6-EEEF8D1E6A99@gmail.com>
 <CAJ-J8TmwQUSEWtML+2LnTa-Z1mGJez4XquJY=pcNx-SQOV4A1A@mail.gmail.com>
Message-ID: <CAJ-J8Tnmay2pbGLWq=0sURJuAeCi0-uqOSAKoU=53FpJ1rX45w@mail.gmail.com>

I check the make sources and they do not seam to use CFLAGS anywhere

Tommaso Pasini

2017-05-12 14:11 GMT+02:00 Tommaso Pasini <p.tommaso at gmail.com>:

> ok, i suspected that Lennart, could you tell me how to set that flag?
> Thanks a lot!
>
> Tommaso Pasini
>
> 2017-05-12 13:09 GMT+02:00 Lennart B?rjeson <lenborje at gmail.com>:
>
>> I?ve had that error on my Mac since forever. :-/
>>
>> You need to configure with "--disable-warnings-as-errors?.
>>
>> You?ll then get that warning quite a few times during the build, bit it
>> will work. (At least it does for me.)
>>
>>
>> /Lennart
>>
>>
>> > 12 maj 2017 kl. 12:44 skrev Tommaso Pasini <p.tommaso at gmail.com>:
>> >
>> > thanks for the answer, I tried to remove and reconfigure. Unfortunately
>> I
>> > still have the same issue.
>> > This is very strange because the static variable _min_tree_chunk_size,
>> > seams declared correctly in the class.
>> >
>> > Tommaso Pasini
>> >
>> > 2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie <
>> magnus.ihse.bursie at oracle.com
>> >> :
>> >
>> >> My recommendation is that you remove the entire output directory ("rm
>> -rf
>> >> build"), re-do the configuration and try again. Before removing, you
>> can do
>> >> "make print-configuration" to get the command line you used to
>> configure.
>> >>
>> >> /Magnus
>> >>
>> >>
>> >> On 2017-05-12 12:12, Tommaso Pasini wrote:
>> >>
>> >>> Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max
>> OS X
>> >>> Sierra.
>> >>> I was able to configure but when I run the command make clean
>> install, it
>> >>> stops with this error:
>> >>>
>> >>> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
>> >>>
>> >>>> instantiation of variable 'TreeChunk<FreeChunk,
>> >>>> AdaptiveFreeList<FreeChunk>
>> >>>>
>> >>>>> ::_min_tree_chunk_size' required here, but no definition is
>> available
>> >>>>>
>> >>>> [-Werror,-Wundefined-var-template]
>> >>>>
>> >>>>     return _min_tree_chunk_size;
>> >>>>
>> >>>>
>> >>>> I checked the file and the variable is declared few lines before.
>> I'm not
>> >>> an expert of C++ and I'm not finding anything on the web.
>> >>>
>> >>> Does anybody already faced this problem?
>> >>>
>> >>> Thanks,
>> >>> --Tommaso
>> >>>
>> >>
>> >>
>>
>>
>


From magnus.ihse.bursie at oracle.com  Fri May 12 12:17:54 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 14:17:54 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <CAJ-J8TmwQUSEWtML+2LnTa-Z1mGJez4XquJY=pcNx-SQOV4A1A@mail.gmail.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
 <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
 <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
 <A8E7C40C-C77E-42F7-9CE6-EEEF8D1E6A99@gmail.com>
 <CAJ-J8TmwQUSEWtML+2LnTa-Z1mGJez4XquJY=pcNx-SQOV4A1A@mail.gmail.com>
Message-ID: <bde4d052-1969-378f-67c4-c23be3fd1849@oracle.com>

"bash configure --disable-warnings-as-errors"

/Magnus

On 2017-05-12 14:11, Tommaso Pasini wrote:
> ok, i suspected that Lennart, could you tell me how to set that flag?
> Thanks a lot!
>
> Tommaso Pasini
>
> 2017-05-12 13:09 GMT+02:00 Lennart B?rjeson <lenborje at gmail.com 
> <mailto:lenborje at gmail.com>>:
>
>     I?ve had that error on my Mac since forever. :-/
>
>     You need to configure with "--disable-warnings-as-errors?.
>
>     You?ll then get that warning quite a few times during the build,
>     bit it will work. (At least it does for me.)
>
>
>     /Lennart
>
>
>     > 12 maj 2017 kl. 12:44 skrev Tommaso Pasini <p.tommaso at gmail.com
>     <mailto:p.tommaso at gmail.com>>:
>     >
>     > thanks for the answer, I tried to remove and reconfigure.
>     Unfortunately I
>     > still have the same issue.
>     > This is very strange because the static variable
>     _min_tree_chunk_size,
>     > seams declared correctly in the class.
>     >
>     > Tommaso Pasini
>     >
>     > 2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie
>     <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>
>     >> :
>     >
>     >> My recommendation is that you remove the entire output
>     directory ("rm -rf
>     >> build"), re-do the configuration and try again. Before
>     removing, you can do
>     >> "make print-configuration" to get the command line you used to
>     configure.
>     >>
>     >> /Magnus
>     >>
>     >>
>     >> On 2017-05-12 12:12, Tommaso Pasini wrote:
>     >>
>     >>> Hi guys, its the whole morning I'm trying to build OpenJDK 9
>     on max OS X
>     >>> Sierra.
>     >>> I was able to configure but when I run the command make clean
>     install, it
>     >>> stops with this error:
>     >>>
>     >>> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12:
>     error:
>     >>>
>     >>>> instantiation of variable 'TreeChunk<FreeChunk,
>     >>>> AdaptiveFreeList<FreeChunk>
>     >>>>
>     >>>>> ::_min_tree_chunk_size' required here, but no definition is
>     available
>     >>>>>
>     >>>> [-Werror,-Wundefined-var-template]
>     >>>>
>     >>>>     return _min_tree_chunk_size;
>     >>>>
>     >>>>
>     >>>> I checked the file and the variable is declared few lines
>     before. I'm not
>     >>> an expert of C++ and I'm not finding anything on the web.
>     >>>
>     >>> Does anybody already faced this problem?
>     >>>
>     >>> Thanks,
>     >>> --Tommaso
>     >>>
>     >>
>     >>
>
>



From magnus.ihse.bursie at oracle.com  Fri May 12 12:31:03 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 14:31:03 +0200
Subject: Review Request: JDK-8180208 Provide a new docs bundle page
In-Reply-To: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
Message-ID: <26a574a9-84e2-16bc-9eaf-3f6aaa7deeac@oracle.com>

Mandy,

Build changes mostly look good. I have a few requests:

1) Please rename the target docs-jdk-index instead of docs-jdk-index-html.

2) I'm glad you added a LogInfo line, however
+        $(call LogInfo, Generating docs bundle page at $@)
will print the full path to the output file, and we try to avoid it. I'd 
be happy with just "$(call LogInfo, Generating docs bundle page)", since 
it's unique.

3) Is this really correct?

+JDK_DOCS_INDEX_HTML := $(JAVADOC_OUTPUTDIR)/docs-index.html

I assumed the output would be index.html?

Regarding the generated page, I don't want to be bikeshedding, but I 
think there's some room for improvement here... Maybe that should be 
defered to a separate bug, I don't know. "Outside Java SE" just sounds 
like a weird way to say "Misc" -- how can it be listed in the "Standard" 
column and still be outside?

What's a "Group"? Isn't that more like "Area"? Why use "Standard" 
instead of "Java SE"?

Shouldn't there be any indication that the module links are shortcuts 
into the same place that the very first link "API Specification" points 
to? Now it sounds like it's completely different documents.

/Magnus



On 2017-05-12 00:58, Mandy Chung wrote:
> The old docs bundle page (aka layer cake) is legacy and not maintained.  In JDK 9, we replace it with a simple page listing modules by groups.  This page can continuously be improved.
>
>     http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html
>
> This is generated by a build tool.  Webrev at:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/index.html
>
> The makefile generates this page in docs-index.html.
>
> Magnus - we will follow up whether you or I make the change to replace index.html.
>
> thanks
> Mandy



From p.tommaso at gmail.com  Fri May 12 12:57:02 2017
From: p.tommaso at gmail.com (Tommaso Pasini)
Date: Fri, 12 May 2017 14:57:02 +0200
Subject: Mac OsX Sierra - Stuck on binaryTreeDictionary.hpp compilation
In-Reply-To: <bde4d052-1969-378f-67c4-c23be3fd1849@oracle.com>
References: <CAJ-J8TkMLW0r0H2GO5AbaQRSCx_ss_rfNG9bVQa-Uf6ZMFSzpQ@mail.gmail.com>
 <a2140b60-c853-e77d-b657-d6dcca7143e8@oracle.com>
 <CAJ-J8TnWOa2EHw8eWS2ibyTMZSitG6NJ8qWfEqEcGwzJW13_3g@mail.gmail.com>
 <A8E7C40C-C77E-42F7-9CE6-EEEF8D1E6A99@gmail.com>
 <CAJ-J8TmwQUSEWtML+2LnTa-Z1mGJez4XquJY=pcNx-SQOV4A1A@mail.gmail.com>
 <bde4d052-1969-378f-67c4-c23be3fd1849@oracle.com>
Message-ID: <CAJ-J8TmFtUWqyjVD1KSKXG_gjaWG_YPMViP19vtwRGq0UNxf+Q@mail.gmail.com>

:D great! It worked perfectly! Thanks a lot

Tommaso Pasini

2017-05-12 14:17 GMT+02:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
>:

> "bash configure --disable-warnings-as-errors"
>
> /Magnus
>
>
> On 2017-05-12 14:11, Tommaso Pasini wrote:
>
> ok, i suspected that Lennart, could you tell me how to set that flag?
> Thanks a lot!
>
> Tommaso Pasini
>
> 2017-05-12 13:09 GMT+02:00 Lennart B?rjeson <lenborje at gmail.com>:
>
>> I?ve had that error on my Mac since forever. :-/
>>
>> You need to configure with "--disable-warnings-as-errors?.
>>
>> You?ll then get that warning quite a few times during the build, bit it
>> will work. (At least it does for me.)
>>
>>
>> /Lennart
>>
>>
>> > 12 maj 2017 kl. 12:44 skrev Tommaso Pasini <p.tommaso at gmail.com>:
>> >
>> > thanks for the answer, I tried to remove and reconfigure. Unfortunately
>> I
>> > still have the same issue.
>> > This is very strange because the static variable _min_tree_chunk_size,
>> > seams declared correctly in the class.
>> >
>> > Tommaso Pasini
>> >
>> > 2017-05-12 12:33 GMT+02:00 Magnus Ihse Bursie <
>> magnus.ihse.bursie at oracle.com
>> >> :
>> >
>> >> My recommendation is that you remove the entire output directory ("rm
>> -rf
>> >> build"), re-do the configuration and try again. Before removing, you
>> can do
>> >> "make print-configuration" to get the command line you used to
>> configure.
>> >>
>> >> /Magnus
>> >>
>> >>
>> >> On 2017-05-12 12:12, Tommaso Pasini wrote:
>> >>
>> >>> Hi guys, its the whole morning I'm trying to build OpenJDK 9 on max
>> OS X
>> >>> Sierra.
>> >>> I was able to configure but when I run the command make clean
>> install, it
>> >>> stops with this error:
>> >>>
>> >>> hotspot/src/share/vm/memory/binaryTreeDictionary.hpp:167:12: error:
>> >>>
>> >>>> instantiation of variable 'TreeChunk<FreeChunk,
>> >>>> AdaptiveFreeList<FreeChunk>
>> >>>>
>> >>>>> ::_min_tree_chunk_size' required here, but no definition is
>> available
>> >>>>>
>> >>>> [-Werror,-Wundefined-var-template]
>> >>>>
>> >>>>     return _min_tree_chunk_size;
>> >>>>
>> >>>>
>> >>>> I checked the file and the variable is declared few lines before.
>> I'm not
>> >>> an expert of C++ and I'm not finding anything on the web.
>> >>>
>> >>> Does anybody already faced this problem?
>> >>>
>> >>> Thanks,
>> >>> --Tommaso
>> >>>
>> >>
>> >>
>>
>>
>
>


From mandy.chung at oracle.com  Fri May 12 15:04:41 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 08:04:41 -0700
Subject: Review Request: JDK-8180208 Provide a new docs bundle page
In-Reply-To: <26a574a9-84e2-16bc-9eaf-3f6aaa7deeac@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
 <26a574a9-84e2-16bc-9eaf-3f6aaa7deeac@oracle.com>
Message-ID: <A6462B7A-4FEB-47BD-98DC-86045784B75C@oracle.com>


> On May 12, 2017, at 5:31 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> Mandy,
> 
> Build changes mostly look good. I have a few requests:
> 
> 1) Please rename the target docs-jdk-index instead of docs-jdk-index-html. 
> 

Will fix.

> 2) I'm glad you added a LogInfo line, however 
> +        $(call LogInfo, Generating docs bundle page at $@)
> will print the full path to the output file, and we try to avoid it. I'd be happy with just "$(call LogInfo, Generating docs bundle page)", since it's unique.
> 

OK.

> 3) Is this really correct?
> +JDK_DOCS_INDEX_HTML := $(JAVADOC_OUTPUTDIR)/docs-index.html
> I assumed the output would be index.html?
> 

This is what I mentioned to coordinate with you.  You have a patch coming to stop building the technotes that I don?t know I should wait for your patch before changing it to index.html

> Regarding the generated page, I don't want to be bikeshedding, but I think there's some room for improvement here... Maybe that should be defered to a separate bug, I don't know. "Outside Java SE" just sounds like a weird way to say "Misc" -- how can it be listed in the "Standard" column and still be outside?
> 

There are two options: making ?Standard? to ?Java SE? and move java.smartcardio and java.jnlp to another column.   I?ll follow up with Alex who proposes to make this column ?Standard?.   We can always follow up with a separate issue to improve this.

> What's a "Group"? Isn't that more like "Area"? Why use "Standard" instead of "Java SE"? 
> 

It isn?t really an area.  

> Shouldn't there be any indication that the module links are shortcuts into the same place that the very first link "API Specification" points to? Now it sounds like it's completely different documents.
> 

It links to the module summary page which can include other information over time e.g. links to other specification such as JNI etc. 

Mandy

> /Magnus
> 
> 
> 
> On 2017-05-12 00:58, Mandy Chung wrote:
>> The old docs bundle page (aka layer cake) is legacy and not maintained.  In JDK 9, we replace it with a simple page listing modules by groups.  This page can continuously be improved.
>> 
>>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html <http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html>
>> 
>> This is generated by a build tool.  Webrev at:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/index.html <http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/index.html>
>> 
>> The makefile generates this page in docs-index.html.
>> 
>> Magnus - we will follow up whether you or I make the change to replace index.html. 
>> 
>> thanks
>> Mandy
> 



From erik.joelsson at oracle.com  Fri May 12 16:01:24 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 12 May 2017 09:01:24 -0700
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <CC719FC8-D4DD-4FD1-96D0-055C8D36737F@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
 <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
 <CC719FC8-D4DD-4FD1-96D0-055C8D36737F@oracle.com>
Message-ID: <293e1bda-fc91-8db0-cdb3-039afd20884e@oracle.com>

Thanks Magnus, I agree completely with the below.

Option 1 seems most logical to me, especially since the work to conform 
to JEP 299 has already been done.

/Erik


On 2017-05-11 23:51, Magnus Ihse Bursie wrote:
> (Sorry if this is a bit TL, please don't DR though...)
>
> Good we started clearing this up!
>
> Let me start with a recap of the current situation:
>
> The man pages exist in the source code in OpenJDK. During the build, they get copied to the JRE and JDK image, in the normal OpenJDK build. (Let me remind you that this is an OpenJDK list, so what we're discussing here is, by default, OpenJDK.)
>
> In the Oracle JDK, some additional code has been added that actively filters out the man pages from the image.
>
> The net effect is that the OpenJDK build includes these man pages, while the Oracle JDK does not.
>
> At some point in time, during JDK 8 I think, Oracle started doing this filtering. As a consequence, we suggested deleting the man pages. This was, as I remember it, met by opposition from other parts of the community. It ended up with the man pages remaining, and a declaration from Oracle that the man pages will not be updated by Oracle, and that the rest of the community needed to step up to keep this up to date.
>
> As far as I know, no contributions have been made to the man pages during this period.
>
> This leaves us at today. That means that if we do nothing, we (meaning the OpenJDK project) will ship the same man pages as we did in JDK 8. (Note that the discussion what *Oracle* ships is different, and need to be conducted in a different forum.)
>
> Since the rest of the community previously preferred to have any man pages, even if they were out of date, rather than to have none, I presume this still is the case. It would be good to have some input on this assumption, though, from e.g. Red Hat.
>
> So, the first decision we need to make is:
> 1) should we keep the man pages as they are?
> 2) should we remove them completely?
> 3) should we keep the man pages and update them?
>
> Unfortunately, option 3 which should have been the winner, is out of the question due to time constraints.
>
> The default route (doing nothing) is selecting option 1, and so does this patch. Anyone opting for option 2, need to file a bug to remove the man pages.
>
> My vote is definitely for option 1. It's the rare documentation that's completely up to date, and in most cases some documentation is better than none. I know I'd be pissed if I couldn't type "man javac" in my OpenJDK installation on Ubuntu. I acknowledge that there have been some substantial changes in JDK to some of the central tools, but most of the tools are unchanged, and even for java and javac, the vast majority  of the options and descriptions still apply.
>
> The second part of the question is, given that option 1 above is followed, where should the man pages reside in the source tree, and where should it end up in the output? If option 2 is chosen, the rest of this discussion can be skipped.
>
> JEP 299 clearly states a place in the source tree for man pages. While it  says that man pages should be in markdown format, it also includes a caveat saying that actual conversation of the man pages to markdown is a non-goal of the JEP. From a build perspective, it makes sense to look at all files in the $module/man directories, and if the file is in markdown, convert it (I have this code in a sandbox, and I had planned to post that as a follow-up), or if it's in troff format, just copy it.
>
> So this patch is the first step of the build requirements on man pages as stated in JEP 299.
>
> Given that we should keep these files, I see no reason not to move them to the location given by JEP 299. I really hope there is no opposition to this part, at least.
>
> The final question is about where to store the man pages in the output. Previously, they have been part of the JDK and JRE images. Since JEP 299 states that man pages should be part of the docs image, I assume it meant that they should be removed from the JDK/JRE images, since it does not make sense to have it in two places.
>
> The ability of jlink to include man pages was news to me. This is not mentioned in JEP 299, nor used in the current build. I assume this is a remnant from previous thinking, prior to JEP 299.
>
> Frankly, I'm a bit surprised by the buzz this patch has generated. I think most of it stems from the confusion between OpenJDK and Oracle JDK, where it has not been apparent to all Oracle employees that what Oracle ships differs in this respect from what OpenJDK ships. And once again, this patch is not about what Oracle will ship, but OpenJDK.
>
> /Magnus
>
>> 12 maj 2017 kl. 04:57 skrev Mandy Chung <mandy.chung at oracle.com>:
>>
>>
>>> On May 11, 2017, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>
>>>
>>>
>>>> On 2017-05-11 15:38, Mandy Chung wrote:
>>>> Magnus,
>>>>
>>>> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
>>> My quick skimming through JEP 299 led me to think this was indeed the intention, at least as placeholders until better documentation can be provided.
>> Jon already clarified.  That?s the original intent but had to defer it to JDK 10 due to the time we have.
>>
>>>> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
>>> The jmods will add man pages if there are any in support/modules_man but I know of now part of the build process that ever puts man pages in there. The man pages in the jdk/jre images are still copied into the image using manual makefile copy in Images.gmk.
>> Hmm?  At that time we might have thought to wait for JEP 299 to do the man pages work.  I added the jmod and jlink mechanism and waited for the man pages be converted to the source form.
>>
>>>> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
>>> We currently only copy man pages into the jdk/jre images when building OpenJDK and not when building OracleJDK.
>> We have to decide what to do with the man pages for OpenJDK build:
>> 1) copy to jdk/jre image as is.
>>   These man pages are out dated.  Copying by default seems not good.
>> 2) a configure option to enable copying man pages.  Default no man page.
>>
>> other options?
>>
>> Mandy
>>
>>> /Erik
>>>> Mandy
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>>>>
>>>>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>>>
>>>>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>>>>
>>>>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>>>>
>>>>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>>>>
>>>>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>>>>
>>>>> /Magnus



From erik.joelsson at oracle.com  Fri May 12 16:07:03 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 12 May 2017 09:07:03 -0700
Subject: RFR: JDK-8180281 --with-jtreg is broken for many use cases
In-Reply-To: <1fecbed8-e9ef-8ff5-0ab7-6c0cb2acc33c@oracle.com>
References: <748e7e58-4dba-3901-ecd8-7fea3ade41c8@oracle.com>
 <1fecbed8-e9ef-8ff5-0ab7-6c0cb2acc33c@oracle.com>
Message-ID: <4479ad66-20d2-040e-4cad-ce4dc61e94f3@oracle.com>

Looks good.

/Erik


On 2017-05-12 04:59, Magnus Ihse Bursie wrote:
> It turned out that run-test behaved badly when JT_HOME was not set. 
> Here's an updated version with a more helpful failure mode.
>
> http://cr.openjdk.java.net/~ihse/JDK-8180281-with-jtreg-is-broken/webrev.02 
>
>
> /Magnus
>
> On 2017-05-12 12:08, Magnus Ihse Bursie wrote:
>> JDK-8179537 was opened with a request to document the brokenness of 
>> --with-jtreg. Better to fix it than to document how it's broken.
>>
>> Now --with-jtreg works like this:
>>  * --without-jtreg will explicitly disable jtreg.
>>  * --with-jtreg=<jtreg home> will use the specified directory, and 
>> will do sanity checks that it is indeed a jtreg home pointed to, and 
>> not a binary.
>> * When no option is given, we try to locate jtreg using JT_HOME from 
>> the environment, and, failing that, by finding the jtreg executable 
>> in the path and deriving a JT_HOME from that. If not found, jtreg 
>> will be disabled.
>> * --with-jtreg (with no arguments) will try to locate jtreg 
>> automatically as described above, but if it fails, it will abort 
>> configure.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180281
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8180281-with-jtreg-is-broken/webrev.01
>>
>> /Magnus
>



From mandy.chung at oracle.com  Fri May 12 16:34:15 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 09:34:15 -0700
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <293e1bda-fc91-8db0-cdb3-039afd20884e@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
 <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
 <CC719FC8-D4DD-4FD1-96D0-055C8D36737F@oracle.com>
 <293e1bda-fc91-8db0-cdb3-039afd20884e@oracle.com>
Message-ID: <75B011EF-1076-462A-8878-7EDFBAE732D8@oracle.com>

I suggest do nothing in JDK 9 (i.e. option 1) and do the man pages cleanup effort in JDK 10.  

This patch together with conversion to markdown can be pushed to jdk10 repo (probably best after the jdk9 build/docs changes are completed to avoid any merge conflict).  There will probably be some follow-up discussion on the man pages for other platforms like windows that may be in HTML format. 

Mandy

> On May 12, 2017, at 9:01 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Thanks Magnus, I agree completely with the below.
> 
> Option 1 seems most logical to me, especially since the work to conform to JEP 299 has already been done.
> 
> /Erik
> 
> 
> On 2017-05-11 23:51, Magnus Ihse Bursie wrote:
>> (Sorry if this is a bit TL, please don't DR though...)
>> 
>> Good we started clearing this up!
>> 
>> Let me start with a recap of the current situation:
>> 
>> The man pages exist in the source code in OpenJDK. During the build, they get copied to the JRE and JDK image, in the normal OpenJDK build. (Let me remind you that this is an OpenJDK list, so what we're discussing here is, by default, OpenJDK.)
>> 
>> In the Oracle JDK, some additional code has been added that actively filters out the man pages from the image.
>> 
>> The net effect is that the OpenJDK build includes these man pages, while the Oracle JDK does not.
>> 
>> At some point in time, during JDK 8 I think, Oracle started doing this filtering. As a consequence, we suggested deleting the man pages. This was, as I remember it, met by opposition from other parts of the community. It ended up with the man pages remaining, and a declaration from Oracle that the man pages will not be updated by Oracle, and that the rest of the community needed to step up to keep this up to date.
>> 
>> As far as I know, no contributions have been made to the man pages during this period.
>> 
>> This leaves us at today. That means that if we do nothing, we (meaning the OpenJDK project) will ship the same man pages as we did in JDK 8. (Note that the discussion what *Oracle* ships is different, and need to be conducted in a different forum.)
>> 
>> Since the rest of the community previously preferred to have any man pages, even if they were out of date, rather than to have none, I presume this still is the case. It would be good to have some input on this assumption, though, from e.g. Red Hat.
>> 
>> So, the first decision we need to make is:
>> 1) should we keep the man pages as they are?
>> 2) should we remove them completely?
>> 3) should we keep the man pages and update them?
>> 
>> Unfortunately, option 3 which should have been the winner, is out of the question due to time constraints.
>> 
>> The default route (doing nothing) is selecting option 1, and so does this patch. Anyone opting for option 2, need to file a bug to remove the man pages.
>> 
>> My vote is definitely for option 1. It's the rare documentation that's completely up to date, and in most cases some documentation is better than none. I know I'd be pissed if I couldn't type "man javac" in my OpenJDK installation on Ubuntu. I acknowledge that there have been some substantial changes in JDK to some of the central tools, but most of the tools are unchanged, and even for java and javac, the vast majority  of the options and descriptions still apply.
>> 
>> The second part of the question is, given that option 1 above is followed, where should the man pages reside in the source tree, and where should it end up in the output? If option 2 is chosen, the rest of this discussion can be skipped.
>> 
>> JEP 299 clearly states a place in the source tree for man pages. While it  says that man pages should be in markdown format, it also includes a caveat saying that actual conversation of the man pages to markdown is a non-goal of the JEP. From a build perspective, it makes sense to look at all files in the $module/man directories, and if the file is in markdown, convert it (I have this code in a sandbox, and I had planned to post that as a follow-up), or if it's in troff format, just copy it.
>> 
>> So this patch is the first step of the build requirements on man pages as stated in JEP 299.
>> 
>> Given that we should keep these files, I see no reason not to move them to the location given by JEP 299. I really hope there is no opposition to this part, at least.
>> 
>> The final question is about where to store the man pages in the output. Previously, they have been part of the JDK and JRE images. Since JEP 299 states that man pages should be part of the docs image, I assume it meant that they should be removed from the JDK/JRE images, since it does not make sense to have it in two places.
>> 
>> The ability of jlink to include man pages was news to me. This is not mentioned in JEP 299, nor used in the current build. I assume this is a remnant from previous thinking, prior to JEP 299.
>> 
>> Frankly, I'm a bit surprised by the buzz this patch has generated. I think most of it stems from the confusion between OpenJDK and Oracle JDK, where it has not been apparent to all Oracle employees that what Oracle ships differs in this respect from what OpenJDK ships. And once again, this patch is not about what Oracle will ship, but OpenJDK.
>> 
>> /Magnus
>> 
>>> 12 maj 2017 kl. 04:57 skrev Mandy Chung <mandy.chung at oracle.com>:
>>> 
>>> 
>>>> On May 11, 2017, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 2017-05-11 15:38, Mandy Chung wrote:
>>>>> Magnus,
>>>>> 
>>>>> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
>>>> My quick skimming through JEP 299 led me to think this was indeed the intention, at least as placeholders until better documentation can be provided.
>>> Jon already clarified.  That?s the original intent but had to defer it to JDK 10 due to the time we have.
>>> 
>>>>> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
>>>> The jmods will add man pages if there are any in support/modules_man but I know of now part of the build process that ever puts man pages in there. The man pages in the jdk/jre images are still copied into the image using manual makefile copy in Images.gmk.
>>> Hmm?  At that time we might have thought to wait for JEP 299 to do the man pages work.  I added the jmod and jlink mechanism and waited for the man pages be converted to the source form.
>>> 
>>>>> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
>>>> We currently only copy man pages into the jdk/jre images when building OpenJDK and not when building OracleJDK.
>>> We have to decide what to do with the man pages for OpenJDK build:
>>> 1) copy to jdk/jre image as is.
>>>  These man pages are out dated.  Copying by default seems not good.
>>> 2) a configure option to enable copying man pages.  Default no man page.
>>> 
>>> other options?
>>> 
>>> Mandy
>>> 
>>>> /Erik
>>>>> Mandy
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>>>>> 
>>>>>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>>>> 
>>>>>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>>>>> 
>>>>>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>>>>> 
>>>>>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>>>>> 
>>>>>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>>>>> 
>>>>>> /Magnus
> 



From magnus.ihse.bursie at oracle.com  Fri May 12 16:44:56 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 18:44:56 +0200
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <293e1bda-fc91-8db0-cdb3-039afd20884e@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
 <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
 <CC719FC8-D4DD-4FD1-96D0-055C8D36737F@oracle.com>
 <293e1bda-fc91-8db0-cdb3-039afd20884e@oracle.com>
Message-ID: <24DFC770-67C5-423B-B806-85B24A7B0A9F@oracle.com>

I realize I was not very clear in my mail, despite my intentions. :-)

What I meant was, given option 1, there are some more choices to be made. 

1a) do not do anything, ignore this patch, and ship things just as they are in JDK 8. 

1b) apply this patch, move the files in the src tree and the output to the docs image. 

1c) do a partial implementation of this patch, e.g. move the man pages in the src tree but do not change the output. 

1d) do something differently, e.g start using the man functionality of jlink. 

From these choices, I prefer 1b. 

It was not clear to me which you (or Mandy) meant by your expressed support for "option 1". 

/Magnus

> 12 maj 2017 kl. 18:01 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Thanks Magnus, I agree completely with the below.
> 
> Option 1 seems most logical to me, especially since the work to conform to JEP 299 has already been done.
> 
> /Erik
> 
> 
>> On 2017-05-11 23:51, Magnus Ihse Bursie wrote:
>> (Sorry if this is a bit TL, please don't DR though...)
>> 
>> Good we started clearing this up!
>> 
>> Let me start with a recap of the current situation:
>> 
>> The man pages exist in the source code in OpenJDK. During the build, they get copied to the JRE and JDK image, in the normal OpenJDK build. (Let me remind you that this is an OpenJDK list, so what we're discussing here is, by default, OpenJDK.)
>> 
>> In the Oracle JDK, some additional code has been added that actively filters out the man pages from the image.
>> 
>> The net effect is that the OpenJDK build includes these man pages, while the Oracle JDK does not.
>> 
>> At some point in time, during JDK 8 I think, Oracle started doing this filtering. As a consequence, we suggested deleting the man pages. This was, as I remember it, met by opposition from other parts of the community. It ended up with the man pages remaining, and a declaration from Oracle that the man pages will not be updated by Oracle, and that the rest of the community needed to step up to keep this up to date.
>> 
>> As far as I know, no contributions have been made to the man pages during this period.
>> 
>> This leaves us at today. That means that if we do nothing, we (meaning the OpenJDK project) will ship the same man pages as we did in JDK 8. (Note that the discussion what *Oracle* ships is different, and need to be conducted in a different forum.)
>> 
>> Since the rest of the community previously preferred to have any man pages, even if they were out of date, rather than to have none, I presume this still is the case. It would be good to have some input on this assumption, though, from e.g. Red Hat.
>> 
>> So, the first decision we need to make is:
>> 1) should we keep the man pages as they are?
>> 2) should we remove them completely?
>> 3) should we keep the man pages and update them?
>> 
>> Unfortunately, option 3 which should have been the winner, is out of the question due to time constraints.
>> 
>> The default route (doing nothing) is selecting option 1, and so does this patch. Anyone opting for option 2, need to file a bug to remove the man pages.
>> 
>> My vote is definitely for option 1. It's the rare documentation that's completely up to date, and in most cases some documentation is better than none. I know I'd be pissed if I couldn't type "man javac" in my OpenJDK installation on Ubuntu. I acknowledge that there have been some substantial changes in JDK to some of the central tools, but most of the tools are unchanged, and even for java and javac, the vast majority  of the options and descriptions still apply.
>> 
>> The second part of the question is, given that option 1 above is followed, where should the man pages reside in the source tree, and where should it end up in the output? If option 2 is chosen, the rest of this discussion can be skipped.
>> 
>> JEP 299 clearly states a place in the source tree for man pages. While it  says that man pages should be in markdown format, it also includes a caveat saying that actual conversation of the man pages to markdown is a non-goal of the JEP. From a build perspective, it makes sense to look at all files in the $module/man directories, and if the file is in markdown, convert it (I have this code in a sandbox, and I had planned to post that as a follow-up), or if it's in troff format, just copy it.
>> 
>> So this patch is the first step of the build requirements on man pages as stated in JEP 299.
>> 
>> Given that we should keep these files, I see no reason not to move them to the location given by JEP 299. I really hope there is no opposition to this part, at least.
>> 
>> The final question is about where to store the man pages in the output. Previously, they have been part of the JDK and JRE images. Since JEP 299 states that man pages should be part of the docs image, I assume it meant that they should be removed from the JDK/JRE images, since it does not make sense to have it in two places.
>> 
>> The ability of jlink to include man pages was news to me. This is not mentioned in JEP 299, nor used in the current build. I assume this is a remnant from previous thinking, prior to JEP 299.
>> 
>> Frankly, I'm a bit surprised by the buzz this patch has generated. I think most of it stems from the confusion between OpenJDK and Oracle JDK, where it has not been apparent to all Oracle employees that what Oracle ships differs in this respect from what OpenJDK ships. And once again, this patch is not about what Oracle will ship, but OpenJDK.
>> 
>> /Magnus
>> 
>>> 12 maj 2017 kl. 04:57 skrev Mandy Chung <mandy.chung at oracle.com>:
>>> 
>>> 
>>>> On May 11, 2017, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 2017-05-11 15:38, Mandy Chung wrote:
>>>>> Magnus,
>>>>> 
>>>>> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
>>>> My quick skimming through JEP 299 led me to think this was indeed the intention, at least as placeholders until better documentation can be provided.
>>> Jon already clarified.  That?s the original intent but had to defer it to JDK 10 due to the time we have.
>>> 
>>>>> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
>>>> The jmods will add man pages if there are any in support/modules_man but I know of now part of the build process that ever puts man pages in there. The man pages in the jdk/jre images are still copied into the image using manual makefile copy in Images.gmk.
>>> Hmm?  At that time we might have thought to wait for JEP 299 to do the man pages work.  I added the jmod and jlink mechanism and waited for the man pages be converted to the source form.
>>> 
>>>>> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
>>>> We currently only copy man pages into the jdk/jre images when building OpenJDK and not when building OracleJDK.
>>> We have to decide what to do with the man pages for OpenJDK build:
>>> 1) copy to jdk/jre image as is.
>>>  These man pages are out dated.  Copying by default seems not good.
>>> 2) a configure option to enable copying man pages.  Default no man page.
>>> 
>>> other options?
>>> 
>>> Mandy
>>> 
>>>> /Erik
>>>>> Mandy
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>>>>> 
>>>>>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>>>> 
>>>>>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>>>>> 
>>>>>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>>>>> 
>>>>>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>>>>> 
>>>>>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>>>>> 
>>>>>> /Magnus
> 



From magnus.ihse.bursie at oracle.com  Fri May 12 17:18:58 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 19:18:58 +0200
Subject: Review Request: JDK-8180208 Provide a new docs bundle page
In-Reply-To: <A6462B7A-4FEB-47BD-98DC-86045784B75C@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
 <26a574a9-84e2-16bc-9eaf-3f6aaa7deeac@oracle.com>
 <A6462B7A-4FEB-47BD-98DC-86045784B75C@oracle.com>
Message-ID: <9f97b9be-1763-10b2-1047-d00a1fea9c44@oracle.com>



On 2017-05-12 17:04, Mandy Chung wrote:
>
>> On May 12, 2017, at 5:31 AM, Magnus Ihse Bursie 
>> <magnus.ihse.bursie at oracle.com 
>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>
>> Mandy,
>>
>> Build changes mostly look good. I have a few requests:
>>
>> 1) Please rename the target docs-jdk-index instead of 
>> docs-jdk-index-html.
>>
>
> Will fix.
>
>> 2) I'm glad you added a LogInfo line, however
>> +        $(call LogInfo, Generating docs bundle page at $@)
>> will print the full path to the output file, and we try to avoid it. 
>> I'd be happy with just "$(call LogInfo, Generating docs bundle 
>> page)", since it's unique.
>>
>
> OK.
>
>> 3) Is this really correct?
>> +JDK_DOCS_INDEX_HTML := $(JAVADOC_OUTPUTDIR)/docs-index.html
>> I assumed the output would be index.html?
>>
>
> This is what I mentioned to coordinate with you.  You have a patch 
> coming to stop building the technotes that I don?t know I should wait 
> for your patch before changing it to index.html
I see. JDK-8175825 (Stop including pubs repo) is pushed now, so there 
should be no conflict with an index.html from there.

>
>> Regarding the generated page, I don't want to be bikeshedding, but I 
>> think there's some room for improvement here... Maybe that should be 
>> defered to a separate bug, I don't know. "Outside Java SE" just 
>> sounds like a weird way to say "Misc" -- how can it be listed in the 
>> "Standard" column and still be outside?
>>
>
> There are two options: making ?Standard? to ?Java SE? and move 
> java.smartcardio and java.jnlp to another column.   I?ll follow up 
> with Alex who proposes to make this column ?Standard?.   We can always 
> follow up with a separate issue to improve this.
>
>> What's a "Group"? Isn't that more like "Area"? Why use "Standard" 
>> instead of "Java SE"?
>>
>
> It isn?t really an area.
>
>> Shouldn't there be any indication that the module links are shortcuts 
>> into the same place that the very first link "API Specification" 
>> points to? Now it sounds like it's completely different documents.
>>
>
> It links to the module summary page which can include other 
> information over time e.g. links to other specification such as JNI etc.

I don't think I made myself clear. On the page you are creating, the 
link for e.g. java.base goes to the module summary page for java.base, 
but the
The API link goes go api/index.html, which in turn links to e.g. the 
module summary page for java.base, while the but e.g. the "API 
specification" goes to the api/index.html page, which is just yet 
another collection of links to the module summary pages. It's like two 
different entry points to the collection of module summaries, one that 
is in alphabetic order and generated by javadoc, and one that's grouped 
per domain and generated by your tool.

This is, in itself, not a problem. Both entry points can make perfect sense.

What I'm trying to point out that this fact, that the "API 
specification" link is just another entry point to the same stuff that 
the table further down is linking to, is not made very clear. If you 
start with this page, you might very well come off with the impression 
that there's *two* sets of documentations, the "API specification" and 
the links to the different modules.

/Magnus

>
> Mandy
>
>> /Magnus
>>
>>
>>
>> On 2017-05-12 00:58, Mandy Chung wrote:
>>> The old docs bundle page (aka layer cake) is legacy and not maintained.  In JDK 9, we replace it with a simple page listing modules by groups.  This page can continuously be improved.
>>>
>>>     http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html
>>>
>>> This is generated by a build tool.  Webrev at:
>>>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.00/index.html
>>>
>>> The makefile generates this page in docs-index.html.
>>>
>>> Magnus - we will follow up whether you or I make the change to replace index.html.
>>>
>>> thanks
>>> Mandy
>>
>



From mandy.chung at oracle.com  Fri May 12 17:23:55 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 10:23:55 -0700
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <24DFC770-67C5-423B-B806-85B24A7B0A9F@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
 <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
 <CC719FC8-D4DD-4FD1-96D0-055C8D36737F@oracle.com>
 <293e1bda-fc91-8db0-cdb3-039afd20884e@oracle.com>
 <24DFC770-67C5-423B-B806-85B24A7B0A9F@oracle.com>
Message-ID: <C39DBA5F-E255-40FA-B343-626AA88A2FEE@oracle.com>

1a - do nothing in JDK 9 as I mentioned in my reply that answered your part 2 question for Option 1.

Do 1d in JDK 10 (along with modularizing the man pages)

Mandy

> On May 12, 2017, at 9:44 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> I realize I was not very clear in my mail, despite my intentions. :-)
> 
> What I meant was, given option 1, there are some more choices to be made. 
> 
> 1a) do not do anything, ignore this patch, and ship things just as they are in JDK 8. 
> 
> 1b) apply this patch, move the files in the src tree and the output to the docs image. 
> 
> 1c) do a partial implementation of this patch, e.g. move the man pages in the src tree but do not change the output. 
> 
> 1d) do something differently, e.g start using the man functionality of jlink. 
> 
> From these choices, I prefer 1b. 
> 
> It was not clear to me which you (or Mandy) meant by your expressed support for "option 1". 
> 
> /Magnus
> 
>> 12 maj 2017 kl. 18:01 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>> 
>> Thanks Magnus, I agree completely with the below.
>> 
>> Option 1 seems most logical to me, especially since the work to conform to JEP 299 has already been done.
>> 
>> /Erik
>> 
>> 
>>> On 2017-05-11 23:51, Magnus Ihse Bursie wrote:
>>> (Sorry if this is a bit TL, please don't DR though...)
>>> 
>>> Good we started clearing this up!
>>> 
>>> Let me start with a recap of the current situation:
>>> 
>>> The man pages exist in the source code in OpenJDK. During the build, they get copied to the JRE and JDK image, in the normal OpenJDK build. (Let me remind you that this is an OpenJDK list, so what we're discussing here is, by default, OpenJDK.)
>>> 
>>> In the Oracle JDK, some additional code has been added that actively filters out the man pages from the image.
>>> 
>>> The net effect is that the OpenJDK build includes these man pages, while the Oracle JDK does not.
>>> 
>>> At some point in time, during JDK 8 I think, Oracle started doing this filtering. As a consequence, we suggested deleting the man pages. This was, as I remember it, met by opposition from other parts of the community. It ended up with the man pages remaining, and a declaration from Oracle that the man pages will not be updated by Oracle, and that the rest of the community needed to step up to keep this up to date.
>>> 
>>> As far as I know, no contributions have been made to the man pages during this period.
>>> 
>>> This leaves us at today. That means that if we do nothing, we (meaning the OpenJDK project) will ship the same man pages as we did in JDK 8. (Note that the discussion what *Oracle* ships is different, and need to be conducted in a different forum.)
>>> 
>>> Since the rest of the community previously preferred to have any man pages, even if they were out of date, rather than to have none, I presume this still is the case. It would be good to have some input on this assumption, though, from e.g. Red Hat.
>>> 
>>> So, the first decision we need to make is:
>>> 1) should we keep the man pages as they are?
>>> 2) should we remove them completely?
>>> 3) should we keep the man pages and update them?
>>> 
>>> Unfortunately, option 3 which should have been the winner, is out of the question due to time constraints.
>>> 
>>> The default route (doing nothing) is selecting option 1, and so does this patch. Anyone opting for option 2, need to file a bug to remove the man pages.
>>> 
>>> My vote is definitely for option 1. It's the rare documentation that's completely up to date, and in most cases some documentation is better than none. I know I'd be pissed if I couldn't type "man javac" in my OpenJDK installation on Ubuntu. I acknowledge that there have been some substantial changes in JDK to some of the central tools, but most of the tools are unchanged, and even for java and javac, the vast majority  of the options and descriptions still apply.
>>> 
>>> The second part of the question is, given that option 1 above is followed, where should the man pages reside in the source tree, and where should it end up in the output? If option 2 is chosen, the rest of this discussion can be skipped.
>>> 
>>> JEP 299 clearly states a place in the source tree for man pages. While it  says that man pages should be in markdown format, it also includes a caveat saying that actual conversation of the man pages to markdown is a non-goal of the JEP. From a build perspective, it makes sense to look at all files in the $module/man directories, and if the file is in markdown, convert it (I have this code in a sandbox, and I had planned to post that as a follow-up), or if it's in troff format, just copy it.
>>> 
>>> So this patch is the first step of the build requirements on man pages as stated in JEP 299.
>>> 
>>> Given that we should keep these files, I see no reason not to move them to the location given by JEP 299. I really hope there is no opposition to this part, at least.
>>> 
>>> The final question is about where to store the man pages in the output. Previously, they have been part of the JDK and JRE images. Since JEP 299 states that man pages should be part of the docs image, I assume it meant that they should be removed from the JDK/JRE images, since it does not make sense to have it in two places.
>>> 
>>> The ability of jlink to include man pages was news to me. This is not mentioned in JEP 299, nor used in the current build. I assume this is a remnant from previous thinking, prior to JEP 299.
>>> 
>>> Frankly, I'm a bit surprised by the buzz this patch has generated. I think most of it stems from the confusion between OpenJDK and Oracle JDK, where it has not been apparent to all Oracle employees that what Oracle ships differs in this respect from what OpenJDK ships. And once again, this patch is not about what Oracle will ship, but OpenJDK.
>>> 
>>> /Magnus
>>> 
>>>> 12 maj 2017 kl. 04:57 skrev Mandy Chung <mandy.chung at oracle.com>:
>>>> 
>>>> 
>>>>> On May 11, 2017, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 2017-05-11 15:38, Mandy Chung wrote:
>>>>>> Magnus,
>>>>>> 
>>>>>> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
>>>>> My quick skimming through JEP 299 led me to think this was indeed the intention, at least as placeholders until better documentation can be provided.
>>>> Jon already clarified.  That?s the original intent but had to defer it to JDK 10 due to the time we have.
>>>> 
>>>>>> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
>>>>> The jmods will add man pages if there are any in support/modules_man but I know of now part of the build process that ever puts man pages in there. The man pages in the jdk/jre images are still copied into the image using manual makefile copy in Images.gmk.
>>>> Hmm?  At that time we might have thought to wait for JEP 299 to do the man pages work.  I added the jmod and jlink mechanism and waited for the man pages be converted to the source form.
>>>> 
>>>>>> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
>>>>> We currently only copy man pages into the jdk/jre images when building OpenJDK and not when building OracleJDK.
>>>> We have to decide what to do with the man pages for OpenJDK build:
>>>> 1) copy to jdk/jre image as is.
>>>> These man pages are out dated.  Copying by default seems not good.
>>>> 2) a configure option to enable copying man pages.  Default no man page.
>>>> 
>>>> other options?
>>>> 
>>>> Mandy
>>>> 
>>>>> /Erik
>>>>>> Mandy
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>>>>>> 
>>>>>>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>>>>> 
>>>>>>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>>>>>> 
>>>>>>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>>>>>> 
>>>>>>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>>>>>> 
>>>>>>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>>>>>> 
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>>>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>>>>>> 
>>>>>>> /Magnus
>> 
> 



From mandy.chung at oracle.com  Fri May 12 18:09:18 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 11:09:18 -0700
Subject: Review Request: JDK-8180208 Provide a new docs bundle page
In-Reply-To: <9f97b9be-1763-10b2-1047-d00a1fea9c44@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
 <26a574a9-84e2-16bc-9eaf-3f6aaa7deeac@oracle.com>
 <A6462B7A-4FEB-47BD-98DC-86045784B75C@oracle.com>
 <9f97b9be-1763-10b2-1047-d00a1fea9c44@oracle.com>
Message-ID: <B9A5B33C-F957-4FA7-A87B-69AE210DB589@oracle.com>

Thanks Magnus for the review and feedback.

Updated webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.02

- Merged with the recent changesets in jdk9/dev.
- Renamed docs-jdk-index-html target to docs-jdk-index.
- Keep the ?Java SE? column header.  Add a new table header to separate the other modules.
- I keep the API Specification there and improve this page as a follow-up issue.

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html

> On May 12, 2017, at 10:18 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>> This is what I mentioned to coordinate with you.  You have a patch coming to stop building the technotes that I don?t know I should wait for your patch before changing it to index.html
> I see. JDK-8175825 (Stop including pubs repo) is pushed now, so there should be no conflict with an index.html from there.

Thanks.  I renamed it.

> 
> I don't think I made myself clear. On the page you are creating, the link for e.g. java.base goes to the module summary page for java.base, but the 
> The API link goes go api/index.html, which in turn links to e.g. the module summary page for java.base, while the but e.g. the "API specification" goes to the api/index.html page, which is just yet another collection of links to the module summary pages. It's like two different entry points to the collection of module summaries, one that is in alphabetic order and generated by javadoc, and one that's grouped per domain and generated by your tool. 
> 
> This is, in itself, not a problem. Both entry points can make perfect sense.
> 

Yup and they give different views of the modules.  The API specification shows a complete list of the modules whereas this page gives a quick overview of some high level grouping.

> What I'm trying to point out that this fact, that the "API specification" link is just another entry point to the same stuff that the table further down is linking to, is not made very clear. If you start with this page, you might very well come off with the impression that there's *two* sets of documentations, the "API specification" and the links to the different modules.

I see the confusion you are pointing out.   I don?t have a good suggestion. 

Mandy



From magnus.ihse.bursie at oracle.com  Fri May 12 18:17:03 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 20:17:03 +0200
Subject: Review Request: JDK-8180208 Provide a new docs bundle page
In-Reply-To: <B9A5B33C-F957-4FA7-A87B-69AE210DB589@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
 <26a574a9-84e2-16bc-9eaf-3f6aaa7deeac@oracle.com>
 <A6462B7A-4FEB-47BD-98DC-86045784B75C@oracle.com>
 <9f97b9be-1763-10b2-1047-d00a1fea9c44@oracle.com>
 <B9A5B33C-F957-4FA7-A87B-69AE210DB589@oracle.com>
Message-ID: <0cde34fa-c7af-fa6a-a1ec-25a7552de57c@oracle.com>


On 2017-05-12 20:09, Mandy Chung wrote:
> Thanks Magnus for the review and feedback.
>
> Updated webrev:
>     http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/webrev.02
>
> - Merged with the recent changesets in jdk9/dev.
> - Renamed docs-jdk-index-html target to docs-jdk-index.
> - Keep the ?Java SE? column header.  Add a new table header to separate the other modules.
> - I keep the API Specification there and improve this page as a follow-up issue.

Looks good to me!

>
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180208/docs/docs-index.html
>
>> On May 12, 2017, at 10:18 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>> This is what I mentioned to coordinate with you.  You have a patch coming to stop building the technotes that I don?t know I should wait for your patch before changing it to index.html
>> I see. JDK-8175825 (Stop including pubs repo) is pushed now, so there should be no conflict with an index.html from there.
> Thanks.  I renamed it.
>
>> I don't think I made myself clear. On the page you are creating, the link for e.g. java.base goes to the module summary page for java.base, but the
>> The API link goes go api/index.html, which in turn links to e.g. the module summary page for java.base, while the but e.g. the "API specification" goes to the api/index.html page, which is just yet another collection of links to the module summary pages. It's like two different entry points to the collection of module summaries, one that is in alphabetic order and generated by javadoc, and one that's grouped per domain and generated by your tool.
>>
>> This is, in itself, not a problem. Both entry points can make perfect sense.
>>
> Yup and they give different views of the modules.  The API specification shows a complete list of the modules whereas this page gives a quick overview of some high level grouping.
>
>> What I'm trying to point out that this fact, that the "API specification" link is just another entry point to the same stuff that the table further down is linking to, is not made very clear. If you start with this page, you might very well come off with the impression that there's *two* sets of documentations, the "API specification" and the links to the different modules.
> I see the confusion you are pointing out.   I don?t have a good suggestion.

Maybe skip the three-bullet item list and rephrase it somewhat.

"The complete API specification is available from [this 
overview](api/index.html). The following table guides to to some 
important entry points".

Or something like that. I don't know. Should probably be done in a 
follow-up.

/Magnus

>
> Mandy
>



From erik.joelsson at oracle.com  Fri May 12 18:30:58 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 12 May 2017 11:30:58 -0700
Subject: RFR: JDK-8180198: make bootcycle-images fail with uses of -d64 flags
Message-ID: <807dc33f-b4a0-5e3d-904c-2ba861f25cb5@oracle.com>

With the removal of the -d64 flag, bootcycle builds started failing. 
This patch stops trying to use -d64 completely for the boot jdk since it 
shouldn't be needed for either JDK 8 or 9. The checks that used this 
parameter to see if the JVM was 64 bit has been rewritten to instead 
look at the version string.

This is for JDK 10.

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

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

/Erik



From mandy.chung at oracle.com  Fri May 12 18:32:42 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 11:32:42 -0700
Subject: RFR: JDK-8180198: make bootcycle-images fail with uses of -d64
 flags
In-Reply-To: <807dc33f-b4a0-5e3d-904c-2ba861f25cb5@oracle.com>
References: <807dc33f-b4a0-5e3d-904c-2ba861f25cb5@oracle.com>
Message-ID: <B406BBD2-5BBE-4579-A7EC-9FE413E2D3FF@oracle.com>


> On May 12, 2017, at 11:30 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> With the removal of the -d64 flag, bootcycle builds started failing. This patch stops trying to use -d64 completely for the boot jdk since it shouldn't be needed for either JDK 8 or 9. The checks that used this parameter to see if the JVM was 64 bit has been rewritten to instead look at the version string.
> 
> This is for JDK 10.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180198
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8180198/webrev.01/


Looks fine to me.

Mandy

From mandy.chung at oracle.com  Fri May 12 18:36:56 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 11:36:56 -0700
Subject: Review Request: JDK-8180208 Provide a new docs bundle page
In-Reply-To: <0cde34fa-c7af-fa6a-a1ec-25a7552de57c@oracle.com>
References: <B675A393-3A8E-489A-9424-68A3E227F1B0@oracle.com>
 <26a574a9-84e2-16bc-9eaf-3f6aaa7deeac@oracle.com>
 <A6462B7A-4FEB-47BD-98DC-86045784B75C@oracle.com>
 <9f97b9be-1763-10b2-1047-d00a1fea9c44@oracle.com>
 <B9A5B33C-F957-4FA7-A87B-69AE210DB589@oracle.com>
 <0cde34fa-c7af-fa6a-a1ec-25a7552de57c@oracle.com>
Message-ID: <1B62024D-0ACF-4B6A-832B-4F227A5B8E38@oracle.com>


> On May 12, 2017, at 11:17 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> 
> Maybe skip the three-bullet item list and rephrase it somewhat.
> 
> "The complete API specification is available from [this overview](api/index.html). The following table guides to to some important entry points".
> 
> Or something like that. I don't know. Should probably be done in a follow-up.


I prefer to follow up separately.

I rename ?API Specification? to ?JDK API Specification? in this patch.  It might not make a difference.

thanks
Mandy

From kumar.x.srinivasan at oracle.com  Fri May 12 18:36:28 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 12 May 2017 11:36:28 -0700
Subject: RFR: JDK-8180198: make bootcycle-images fail with uses of -d64
 flags
In-Reply-To: <807dc33f-b4a0-5e3d-904c-2ba861f25cb5@oracle.com>
References: <807dc33f-b4a0-5e3d-904c-2ba861f25cb5@oracle.com>
Message-ID: <591600AC.5000606@oracle.com>


Looks good, and thanks for fixing this quickly!.

Kumar

> With the removal of the -d64 flag, bootcycle builds started failing. 
> This patch stops trying to use -d64 completely for the boot jdk since 
> it shouldn't be needed for either JDK 8 or 9. The checks that used 
> this parameter to see if the JVM was 64 bit has been rewritten to 
> instead look at the version string.
>
> This is for JDK 10.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180198
>
> Webrev: http://cr.openjdk.java.net/~erikj/8180198/webrev.01/
>
> /Erik
>



From tim.bell at oracle.com  Fri May 12 18:47:11 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 12 May 2017 11:47:11 -0700
Subject: RFR: JDK-8180198: make bootcycle-images fail with uses of -d64
 flags
In-Reply-To: <591600AC.5000606@oracle.com>
References: <807dc33f-b4a0-5e3d-904c-2ba861f25cb5@oracle.com>
 <591600AC.5000606@oracle.com>
Message-ID: <5916032F.9060802@oracle.com>

Erik:

Looks good to me as well.

Tim

On 05/12/17 11:36, Kumar Srinivasan wrote:
>
> Looks good, and thanks for fixing this quickly!.
>
> Kumar
>
>> With the removal of the -d64 flag, bootcycle builds started failing.
>> This patch stops trying to use -d64 completely for the boot jdk since
>> it shouldn't be needed for either JDK 8 or 9. The checks that used
>> this parameter to see if the JVM was 64 bit has been rewritten to
>> instead look at the version string.
>>
>> This is for JDK 10.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180198
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8180198/webrev.01/
>>
>> /Erik
>>
>



From jonathan.gibbons at oracle.com  Fri May 12 22:21:28 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 May 2017 15:21:28 -0700
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <755A3DBA-BC9E-433B-82C2-8E2D94DF56B1@oracle.com>
References: <59134312.6070701@oracle.com>
 <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
 <59134B6A.7090504@oracle.com>
 <b2689382-8c82-528c-6e03-a598f601d240@oracle.com>
 <5914CEB7.5080505@oracle.com>
 <755A3DBA-BC9E-433B-82C2-8E2D94DF56B1@oracle.com>
Message-ID: <59163568.9000405@oracle.com>

Magnus,

I agree with this, and agree with closing it WNF.

-- Jon

On 05/12/2017 12:16 AM, Magnus Ihse Bursie wrote:
> Kumar,
>
> This was not an improvement. This will require additional changes in the build system to avoid a regression. I see no reason for that.
>
> In fact, I propose we close the bug as WNF. Let me elaborate.
>
> The problem here is that Oracle has dual roles: partly as a contributor to OpenJDK, and partly as a independent company that wants to contribute to the Java ecosystem outside of the OpenJDK project.
>
> To Oracle's credit, most of the documentation provided goes into the OpenJDK project (and repositories). For some reason or reasons, Oracle chose to not so so with all Java-related documentation, typically user guides etc.
>
> The crucial question is then: should the OpenJDK documentation point to the (proprietary) Oracle documentation?
>
>  From the OpenJDK perspective, the ideal would be if the documentation was included with the OpenJDK distribution, but if that is not going to happen, then what is the best for the project?
>
> I would argue that it is still better to link to the Oracle documents than to not do it. We have no qualms linking to other third party sites where suitable and helpful to the reader, and this is no different.
>
> (Yes, I have changed my opinion about this.)
>
> This is not a question about what the Oracle JDK will do, since it will definitely link to the Oracle guides no matter what. What I'm thinking of is if the OpenJDK in any way would be considered helped by *not* linking to publicly available documentation on Oracle's web site. I can't see any such reason, and therefore, I see no reason not to link, making this addition unnecessary.
>
> That said, I hope that in due time, Oracle will consider adding more of the documentation to the OpenJDK project, if it seems reasonable that it belongs here.
>
> /Magnus
>
>> 11 maj 2017 kl. 22:51 skrev Kumar Srinivasan <kumar.x.srinivasan at oracle.com>:
>>
>> Hi,
>>
>> Changes in this webrev:
>> * inverted the logic as you suggested
>> * some doc comment changes to reflect the change
>>
>> http://cr.openjdk.java.net/~ksrini/8179915/webrev.1/
>>
>> Thanks
>> Kumar
>>
>>> On 5/10/2017 7:19 PM, David Holmes wrote:
>>>> On 11/05/2017 3:18 AM, Kumar Srinivasan wrote:
>>>>
>>>>> On 5/10/2017 9:51 AM, Erik Joelsson wrote:
>>>>> Should this be set on the javadoc command line somewhere or am I
>>>>> missing something?
>>>> Yes, one would have to set this prop, via the build system, when
>>>> performing a non-oracle build.
>>> Shouldn't that be inverted then - given there is only 1 Oracle build and potentially innumerable non-Oracle builds? The default should be to not link unless the property is set.
>>>
>>> Thanks,
>>> David
>>>
>>>> Kumar
>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>>> On 2017-05-10 09:42, Kumar Srinivasan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review fix for the custom taglet to allow openjdk builds, in
>>>>>> which case
>>>>>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to
>>>>>> inhibit server
>>>>>> side lookups.
>>>>>>
>>>>>> Thanks
>>>>>> Kumar
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915



From magnus.ihse.bursie at oracle.com  Mon May 15 10:32:03 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 15 May 2017 12:32:03 +0200
Subject: RFR: JDK-8180342 fixup path for jtreg
Message-ID: <32b6c1e8-555f-c9cd-093d-6085726f5dcd@oracle.com>

JDK-8180281 caused a regression on certain windows configurations for 
jtreg. We need to clean up the paths.

I have verified that this resolves the issue on the reported configuration.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180342
Patch inline:
diff --git a/common/autoconf/toolchain.m4 b/common/autoconf/toolchain.m4
--- a/common/autoconf/toolchain.m4
+++ b/common/autoconf/toolchain.m4
@@ -1000,6 +1000,8 @@
      fi
    fi

+  BASIC_FIXUP_EXECUTABLE(JTREGEXE)
+  BASIC_FIXUP_PATH(JT_HOME)
    AC_SUBST(JT_HOME)
    AC_SUBST(JTREGEXE)
  ])

/Magnus


From david.holmes at oracle.com  Mon May 15 01:40:52 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 May 2017 11:40:52 +1000
Subject: RFR: 8179915: Update extLink taglet to allow not linking the
 description
In-Reply-To: <755A3DBA-BC9E-433B-82C2-8E2D94DF56B1@oracle.com>
References: <59134312.6070701@oracle.com>
 <9b7edd60-3e19-d971-c869-4325429714a5@oracle.com>
 <59134B6A.7090504@oracle.com>
 <b2689382-8c82-528c-6e03-a598f601d240@oracle.com>
 <5914CEB7.5080505@oracle.com>
 <755A3DBA-BC9E-433B-82C2-8E2D94DF56B1@oracle.com>
Message-ID: <ba6b7b4b-cf4c-5c70-5f9b-673fd26a9419@oracle.com>

On 12/05/2017 5:16 PM, Magnus Ihse Bursie wrote:
> Kumar,
>
> This was not an improvement. This will require additional changes in the build system to avoid a regression. I see no reason for that.
>
> In fact, I propose we close the bug as WNF. Let me elaborate.
>
> The problem here is that Oracle has dual roles: partly as a contributor to OpenJDK, and partly as a independent company that wants to contribute to the Java ecosystem outside of the OpenJDK project.
>
> To Oracle's credit, most of the documentation provided goes into the OpenJDK project (and repositories). For some reason or reasons, Oracle chose to not so so with all Java-related documentation, typically user guides etc.
>
> The crucial question is then: should the OpenJDK documentation point to the (proprietary) Oracle documentation?
>
> From the OpenJDK perspective, the ideal would be if the documentation was included with the OpenJDK distribution, but if that is not going to happen, then what is the best for the project?
>
> I would argue that it is still better to link to the Oracle documents than to not do it. We have no qualms linking to other third party sites where suitable and helpful to the reader, and this is no different.
>
> (Yes, I have changed my opinion about this.)
>
> This is not a question about what the Oracle JDK will do, since it will definitely link to the Oracle guides no matter what. What I'm thinking of is if the OpenJDK in any way would be considered helped by *not* linking to publicly available documentation on Oracle's web site. I can't see any such reason, and therefore, I see no reason not to link, making this addition unnecessary.

Not knowing exactly where this proprietary Oracle documentation will end 
up, I can't say whether it will be truly publicly available or whether 
you will have to log on to the "technical network" to access it?

That aside IIUC the issue/concern is that other members of the OpenJDK 
community may want to produce documentation bundles that do not contain 
links to external sites such as Oracle's.

This is a policy decision that should not be being made by the engineers 
on the front-line so to speak.

David
-----

> That said, I hope that in due time, Oracle will consider adding more of the documentation to the OpenJDK project, if it seems reasonable that it belongs here.
>
> /Magnus
>
>> 11 maj 2017 kl. 22:51 skrev Kumar Srinivasan <kumar.x.srinivasan at oracle.com>:
>>
>> Hi,
>>
>> Changes in this webrev:
>> * inverted the logic as you suggested
>> * some doc comment changes to reflect the change
>>
>> http://cr.openjdk.java.net/~ksrini/8179915/webrev.1/
>>
>> Thanks
>> Kumar
>>
>>> On 5/10/2017 7:19 PM, David Holmes wrote:
>>>> On 11/05/2017 3:18 AM, Kumar Srinivasan wrote:
>>>>
>>>>> On 5/10/2017 9:51 AM, Erik Joelsson wrote:
>>>>> Should this be set on the javadoc command line somewhere or am I
>>>>> missing something?
>>>>
>>>> Yes, one would have to set this prop, via the build system, when
>>>> performing a non-oracle build.
>>>
>>> Shouldn't that be inverted then - given there is only 1 Oracle build and potentially innumerable non-Oracle builds? The default should be to not link unless the property is set.
>>>
>>> Thanks,
>>> David
>>>
>>>> Kumar
>>>>
>>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>>> On 2017-05-10 09:42, Kumar Srinivasan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review fix for the custom taglet to allow openjdk builds, in
>>>>>> which case
>>>>>> the property "build.tools.taglet.ExtLink.NO_LINK" must be set to
>>>>>> inhibit server
>>>>>> side lookups.
>>>>>>
>>>>>> Thanks
>>>>>> Kumar
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179915/webrev.0
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179915
>>
>


From david.holmes at oracle.com  Mon May 15 01:44:57 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 May 2017 11:44:57 +1000
Subject: RFR: JDK-8180178 Restructure existing man pages according to JEP
 299
In-Reply-To: <C39DBA5F-E255-40FA-B343-626AA88A2FEE@oracle.com>
References: <8ef65262-cffe-31f4-8094-0214f256ec13@oracle.com>
 <9B210760-902F-43EB-83C1-06EE78BDF0B1@oracle.com>
 <8e38096d-15bd-46cc-098f-3252891d0e3f@oracle.com>
 <36C75CF6-8F30-4408-A876-3C1B9D9D10DD@oracle.com>
 <CC719FC8-D4DD-4FD1-96D0-055C8D36737F@oracle.com>
 <293e1bda-fc91-8db0-cdb3-039afd20884e@oracle.com>
 <24DFC770-67C5-423B-B806-85B24A7B0A9F@oracle.com>
 <C39DBA5F-E255-40FA-B343-626AA88A2FEE@oracle.com>
Message-ID: <ded6bb4b-bbe6-5635-740c-feb9332e5760@oracle.com>

On 13/05/2017 3:23 AM, Mandy Chung wrote:
> 1a - do nothing in JDK 9 as I mentioned in my reply that answered your part 2 question for Option 1.

If we can't do (2) then (1a) would also be my preference from a set of 
bad options. :(

But again this is a policy decision that someone higher up should be 
making, having regard for both how this impacts the perception of 
OpenJDK as a whole, and how any choice impacts resources need for 9 GA.

Thanks,
David

> Do 1d in JDK 10 (along with modularizing the man pages)
>
> Mandy
>
>> On May 12, 2017, at 9:44 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> I realize I was not very clear in my mail, despite my intentions. :-)
>>
>> What I meant was, given option 1, there are some more choices to be made.
>>
>> 1a) do not do anything, ignore this patch, and ship things just as they are in JDK 8.
>>
>> 1b) apply this patch, move the files in the src tree and the output to the docs image.
>>
>> 1c) do a partial implementation of this patch, e.g. move the man pages in the src tree but do not change the output.
>>
>> 1d) do something differently, e.g start using the man functionality of jlink.
>>
>> From these choices, I prefer 1b.
>>
>> It was not clear to me which you (or Mandy) meant by your expressed support for "option 1".
>>
>> /Magnus
>>
>>> 12 maj 2017 kl. 18:01 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>>
>>> Thanks Magnus, I agree completely with the below.
>>>
>>> Option 1 seems most logical to me, especially since the work to conform to JEP 299 has already been done.
>>>
>>> /Erik
>>>
>>>
>>>> On 2017-05-11 23:51, Magnus Ihse Bursie wrote:
>>>> (Sorry if this is a bit TL, please don't DR though...)
>>>>
>>>> Good we started clearing this up!
>>>>
>>>> Let me start with a recap of the current situation:
>>>>
>>>> The man pages exist in the source code in OpenJDK. During the build, they get copied to the JRE and JDK image, in the normal OpenJDK build. (Let me remind you that this is an OpenJDK list, so what we're discussing here is, by default, OpenJDK.)
>>>>
>>>> In the Oracle JDK, some additional code has been added that actively filters out the man pages from the image.
>>>>
>>>> The net effect is that the OpenJDK build includes these man pages, while the Oracle JDK does not.
>>>>
>>>> At some point in time, during JDK 8 I think, Oracle started doing this filtering. As a consequence, we suggested deleting the man pages. This was, as I remember it, met by opposition from other parts of the community. It ended up with the man pages remaining, and a declaration from Oracle that the man pages will not be updated by Oracle, and that the rest of the community needed to step up to keep this up to date.
>>>>
>>>> As far as I know, no contributions have been made to the man pages during this period.
>>>>
>>>> This leaves us at today. That means that if we do nothing, we (meaning the OpenJDK project) will ship the same man pages as we did in JDK 8. (Note that the discussion what *Oracle* ships is different, and need to be conducted in a different forum.)
>>>>
>>>> Since the rest of the community previously preferred to have any man pages, even if they were out of date, rather than to have none, I presume this still is the case. It would be good to have some input on this assumption, though, from e.g. Red Hat.
>>>>
>>>> So, the first decision we need to make is:
>>>> 1) should we keep the man pages as they are?
>>>> 2) should we remove them completely?
>>>> 3) should we keep the man pages and update them?
>>>>
>>>> Unfortunately, option 3 which should have been the winner, is out of the question due to time constraints.
>>>>
>>>> The default route (doing nothing) is selecting option 1, and so does this patch. Anyone opting for option 2, need to file a bug to remove the man pages.
>>>>
>>>> My vote is definitely for option 1. It's the rare documentation that's completely up to date, and in most cases some documentation is better than none. I know I'd be pissed if I couldn't type "man javac" in my OpenJDK installation on Ubuntu. I acknowledge that there have been some substantial changes in JDK to some of the central tools, but most of the tools are unchanged, and even for java and javac, the vast majority  of the options and descriptions still apply.
>>>>
>>>> The second part of the question is, given that option 1 above is followed, where should the man pages reside in the source tree, and where should it end up in the output? If option 2 is chosen, the rest of this discussion can be skipped.
>>>>
>>>> JEP 299 clearly states a place in the source tree for man pages. While it  says that man pages should be in markdown format, it also includes a caveat saying that actual conversation of the man pages to markdown is a non-goal of the JEP. From a build perspective, it makes sense to look at all files in the $module/man directories, and if the file is in markdown, convert it (I have this code in a sandbox, and I had planned to post that as a follow-up), or if it's in troff format, just copy it.
>>>>
>>>> So this patch is the first step of the build requirements on man pages as stated in JEP 299.
>>>>
>>>> Given that we should keep these files, I see no reason not to move them to the location given by JEP 299. I really hope there is no opposition to this part, at least.
>>>>
>>>> The final question is about where to store the man pages in the output. Previously, they have been part of the JDK and JRE images. Since JEP 299 states that man pages should be part of the docs image, I assume it meant that they should be removed from the JDK/JRE images, since it does not make sense to have it in two places.
>>>>
>>>> The ability of jlink to include man pages was news to me. This is not mentioned in JEP 299, nor used in the current build. I assume this is a remnant from previous thinking, prior to JEP 299.
>>>>
>>>> Frankly, I'm a bit surprised by the buzz this patch has generated. I think most of it stems from the confusion between OpenJDK and Oracle JDK, where it has not been apparent to all Oracle employees that what Oracle ships differs in this respect from what OpenJDK ships. And once again, this patch is not about what Oracle will ship, but OpenJDK.
>>>>
>>>> /Magnus
>>>>
>>>>> 12 maj 2017 kl. 04:57 skrev Mandy Chung <mandy.chung at oracle.com>:
>>>>>
>>>>>
>>>>>> On May 11, 2017, at 5:44 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 2017-05-11 15:38, Mandy Chung wrote:
>>>>>>> Magnus,
>>>>>>>
>>>>>>> I?m surprised to see the man pages are moved to src/$MODULE/share/man directory.  These man pages are not maintained and not updated. It?s agreed that the man pages are specification for the tools that we should write and include in the source under src/$MODULE/share/man directory.  However, it?s not intended to move these unmaintained man page to the source.
>>>>>> My quick skimming through JEP 299 led me to think this was indeed the intention, at least as placeholders until better documentation can be provided.
>>>>> Jon already clarified.  That?s the original intent but had to defer it to JDK 10 due to the time we have.
>>>>>
>>>>>>> Related to copying the man pages to the image, man pages should be packaged in a module (JDK-8167558 [1]).  JMOD file has a man page section specific for man pages. jlink provides an option --no-man-pages to exclude man pages when creating an image.  make/CreateJmods.gmk was modified to include the man pages in creating JMOD files [1].
>>>>>> The jmods will add man pages if there are any in support/modules_man but I know of now part of the build process that ever puts man pages in there. The man pages in the jdk/jre images are still copied into the image using manual makefile copy in Images.gmk.
>>>>> Hmm?  At that time we might have thought to wait for JEP 299 to do the man pages work.  I added the jmod and jlink mechanism and waited for the man pages be converted to the source form.
>>>>>
>>>>>>> If my memory served well, I tested on OpenJDK build that jdk image has the man pages.  For Oracle build, it does not ship with man pages.  Did I remember correctly? Under what build configuration do we include the man pages in the image?   Maybe it?s not doing what it?s supposed to be??
>>>>>> We currently only copy man pages into the jdk/jre images when building OpenJDK and not when building OracleJDK.
>>>>> We have to decide what to do with the man pages for OpenJDK build:
>>>>> 1) copy to jdk/jre image as is.
>>>>> These man pages are out dated.  Copying by default seems not good.
>>>>> 2) a configure option to enable copying man pages.  Default no man page.
>>>>>
>>>>> other options?
>>>>>
>>>>> Mandy
>>>>>
>>>>>> /Erik
>>>>>>> Mandy
>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8167558
>>>>>>>
>>>>>>>> On May 11, 2017, at 5:56 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>>>>>>
>>>>>>>> In preparation for JDK-8178317, the existing man page troff sources will be moved to their corresponding modules, according to the layout determined by JEP 299. During the docs build, they will be copied to the man directory in the docs image, as specified by JEP 299. No markdown conversion will be done for now, though.
>>>>>>>>
>>>>>>>> Note that this will only apply to OpenJDK, not the Oracle JDK, which do not ship the man pages from the OpenJDK repository. (This has not been the case since at least JDK 8.) Also note that the man pages themselves have not been updated. I did update "JDK 8" to "JDK 9", but I have made no other changes. Nevertheless, I believe having man pages (even if outdated) is better for the community than not having man pages.
>>>>>>>>
>>>>>>>> The jhat and jsadebug tools have been removed in JDK 9, so I removed these man pages as well.
>>>>>>>>
>>>>>>>> Prior to this reorganisation, the man pages were duplicated in three directories, one for each of solaris, linux and bsd. I have verified that for the remaining man pages, there were no substantial difference between these versions.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180178
>>>>>>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180178-restructure-man-pages/webrev.01
>>>>>>>>
>>>>>>>> /Magnus
>>>
>>
>


From aph at redhat.com  Tue May 16 08:57:08 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 16 May 2017 09:57:08 +0100
Subject: Graal missing from MacOS Java 9 EA download b167
In-Reply-To: <911130E2-3DD7-48CD-955B-9358F8B6165A@gmail.com>
References: <6CF09D22-D5CC-4459-94BA-65C709523E5B@gmail.com>
 <D90E6F4D-1246-40C9-8FF9-A7D551DB022C@oracle.com>
 <911130E2-3DD7-48CD-955B-9358F8B6165A@gmail.com>
Message-ID: <60449a9b-9d8b-0bf3-416d-a5f9386c5b81@redhat.com>

On 12/05/17 12:30, Lennart B?rjeson wrote:

> As I believe Graal is the most important new thing in jdk9, I?d then
> just want to state my opinion: Even if AOT is available only for
> x86_64 (and I have absolutely no problems with that), I still
> believe Graal should be included on all platforms.

Well, we'd have to write it.  We've done x86 and (partially) AArch64,
but Mac has a different object file format from Linux.  Do you want to
work on it?  Patches welcome.

Andrew.


From lenborje at gmail.com  Tue May 16 09:12:23 2017
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Tue, 16 May 2017 11:12:23 +0200
Subject: Graal missing from MacOS Java 9 EA download b167
In-Reply-To: <60449a9b-9d8b-0bf3-416d-a5f9386c5b81@redhat.com>
References: <6CF09D22-D5CC-4459-94BA-65C709523E5B@gmail.com>
 <D90E6F4D-1246-40C9-8FF9-A7D551DB022C@oracle.com>
 <911130E2-3DD7-48CD-955B-9358F8B6165A@gmail.com>
 <60449a9b-9d8b-0bf3-416d-a5f9386c5b81@redhat.com>
Message-ID: <FCB6CEBE-5FBE-44DB-BD23-BED70ED807B5@gmail.com>

I believe you?re confusing AOT and Graal. I?m not asking for AOT on all platforms (indeed, I have no use for it on any platform!),  but for Graal itself.

Graal works on Mac, you only need to enable it in the configuration of the build. I?m guessing it works on all x86 platforms.

(Using, e.g.,  ./configure --with-jvm-features=compiler1,compiler2,jvmci,graal)

/Lennart

> 16 maj 2017 kl. 10:57 skrev Andrew Haley <aph at redhat.com>:
> 
> On 12/05/17 12:30, Lennart B?rjeson wrote:
> 
>> As I believe Graal is the most important new thing in jdk9, I?d then
>> just want to state my opinion: Even if AOT is available only for
>> x86_64 (and I have absolutely no problems with that), I still
>> believe Graal should be included on all platforms.
> 
> Well, we'd have to write it.  We've done x86 and (partially) AArch64,
> but Mac has a different object file format from Linux.  Do you want to
> work on it?  Patches welcome.
> 
> Andrew.



From aph at redhat.com  Tue May 16 09:29:59 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 16 May 2017 10:29:59 +0100
Subject: Graal missing from MacOS Java 9 EA download b167
In-Reply-To: <FCB6CEBE-5FBE-44DB-BD23-BED70ED807B5@gmail.com>
References: <6CF09D22-D5CC-4459-94BA-65C709523E5B@gmail.com>
 <D90E6F4D-1246-40C9-8FF9-A7D551DB022C@oracle.com>
 <911130E2-3DD7-48CD-955B-9358F8B6165A@gmail.com>
 <60449a9b-9d8b-0bf3-416d-a5f9386c5b81@redhat.com>
 <FCB6CEBE-5FBE-44DB-BD23-BED70ED807B5@gmail.com>
Message-ID: <bc4b2d41-0973-8526-79f8-52f3f0d7ab39@redhat.com>

On 16/05/17 10:12, Lennart B?rjeson wrote:

> I believe you?re confusing AOT and Graal. I?m not asking for AOT on
> all platforms (indeed, I have no use for it on any platform!), but
> for Graal itself.
> 
> Graal works on Mac, you only need to enable it in the configuration
> of the build. I?m guessing it works on all x86 platforms.

Perhaps, but it's only in because of AOT, and given the present state
of flux in Graal development anyone who wants to experiment with it is
better advised to use upstream Graal.  IMO.

Andrew.


From erik.joelsson at oracle.com  Tue May 16 09:43:35 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 16 May 2017 11:43:35 +0200
Subject: RFR: JDK-8180342 fixup path for jtreg
In-Reply-To: <32b6c1e8-555f-c9cd-093d-6085726f5dcd@oracle.com>
References: <32b6c1e8-555f-c9cd-093d-6085726f5dcd@oracle.com>
Message-ID: <a28123d4-9f14-d89e-3fac-451eb852c016@oracle.com>

Looks good.

/Erik


On 2017-05-15 12:32, Magnus Ihse Bursie wrote:
> JDK-8180281 caused a regression on certain windows configurations for 
> jtreg. We need to clean up the paths.
>
> I have verified that this resolves the issue on the reported 
> configuration.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180342
> Patch inline:
> diff --git a/common/autoconf/toolchain.m4 b/common/autoconf/toolchain.m4
> --- a/common/autoconf/toolchain.m4
> +++ b/common/autoconf/toolchain.m4
> @@ -1000,6 +1000,8 @@
>      fi
>    fi
>
> +  BASIC_FIXUP_EXECUTABLE(JTREGEXE)
> +  BASIC_FIXUP_PATH(JT_HOME)
>    AC_SUBST(JT_HOME)
>    AC_SUBST(JTREGEXE)
>  ])
>
> /Magnus



From magnus.ihse.bursie at oracle.com  Tue May 16 09:56:04 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 16 May 2017 11:56:04 +0200
Subject: RFR: JDK-8180420 Set PATH for dot and pandoc in JIB
Message-ID: <ea9b1972-e6c4-aa32-60a0-31e97054dacc@oracle.com>

We should set environment_path in jib-profiles.js to allow for "jib run" 
to use pandoc and dot.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180420
Patch inline:
diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js
--- a/common/conf/jib-profiles.js
+++ b/common/conf/jib-profiles.js
@@ -997,7 +997,8 @@
              ext: "tar.gz",
              revision: "2.38.0-1+1.1",
              module: "graphviz-" + input.target_platform,
-            configure_args: "DOT=" + input.get("graphviz", 
"install_path") + "/dot"
+            configure_args: "DOT=" + input.get("graphviz", 
"install_path") + "/dot",
+            environment_path: input.get("graphviz", "install_path")
          },

          pandoc: {
@@ -1005,7 +1006,8 @@
              ext: "tar.gz",
              revision: "1.17.2+1.0",
              module: "pandoc-" + input.target_platform,
-            configure_args: "PANDOC=" + input.get("pandoc", 
"install_path") + "/pandoc/pandoc"
+            configure_args: "PANDOC=" + input.get("pandoc", 
"install_path") + "/pandoc/pandoc",
+            environment_path: input.get("pandoc", "install_path") + 
"/pandoc"
          },
      };


/Magnus


From magnus.ihse.bursie at oracle.com  Tue May 16 10:01:17 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 16 May 2017 12:01:17 +0200
Subject: RFR: JDK-8180328 Bad links in footer of all javadoc-generated pages
Message-ID: <455f0a04-0edb-960a-f62a-7ba8c69a86b7@oracle.com>

There are 2 problems in the Doc.gmk file with respect to setting up the 
footer option for javadoc.
1. Line 55.
JAVADOC_BASE_URL := 
http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=homepage
The & should be escaped as an entity and should be &amp; by the time the 
string gets passed into javadoc.

2. Line 134
<a href="$(JAVADOC_BASE_URL)/index.html" target="_blank">Java SE \
/index.html is being added to the string being passed into javadoc. That 
is wrong and causes a 404 when you click onthe link in the generated pages.

Also, with the new base URL the -Xdocrootparent does not make sense, 
since you can't append a relative path to it. If a derived version of 
OpenJDK wants to patch Docs.gmk to provide a different JAVADOC_BASE_URL, 
they'll also have to patch it to explicitly provide a -Xdocrootparent 
flag. But as OpenJDK by itself looks, the -Xdocrootparent flag is just 
broken.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180328
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180328-bad-docroot/webrev.01

/Magnus



From erik.joelsson at oracle.com  Tue May 16 10:13:26 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 16 May 2017 12:13:26 +0200
Subject: RFR: JDK-8180420 Set PATH for dot and pandoc in JIB
In-Reply-To: <ea9b1972-e6c4-aa32-60a0-31e97054dacc@oracle.com>
References: <ea9b1972-e6c4-aa32-60a0-31e97054dacc@oracle.com>
Message-ID: <ec81fa43-017c-728d-3774-9a8e4f83c075@oracle.com>

Looks good.

/Erik


On 2017-05-16 11:56, Magnus Ihse Bursie wrote:
> We should set environment_path in jib-profiles.js to allow for "jib 
> run" to use pandoc and dot.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180420
> Patch inline:
> diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js
> --- a/common/conf/jib-profiles.js
> +++ b/common/conf/jib-profiles.js
> @@ -997,7 +997,8 @@
>              ext: "tar.gz",
>              revision: "2.38.0-1+1.1",
>              module: "graphviz-" + input.target_platform,
> -            configure_args: "DOT=" + input.get("graphviz", 
> "install_path") + "/dot"
> +            configure_args: "DOT=" + input.get("graphviz", 
> "install_path") + "/dot",
> +            environment_path: input.get("graphviz", "install_path")
>          },
>
>          pandoc: {
> @@ -1005,7 +1006,8 @@
>              ext: "tar.gz",
>              revision: "1.17.2+1.0",
>              module: "pandoc-" + input.target_platform,
> -            configure_args: "PANDOC=" + input.get("pandoc", 
> "install_path") + "/pandoc/pandoc"
> +            configure_args: "PANDOC=" + input.get("pandoc", 
> "install_path") + "/pandoc/pandoc",
> +            environment_path: input.get("pandoc", "install_path") + 
> "/pandoc"
>          },
>      };
>
>
> /Magnus



From erik.joelsson at oracle.com  Tue May 16 10:15:00 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 16 May 2017 12:15:00 +0200
Subject: RFR: JDK-8180328 Bad links in footer of all javadoc-generated
 pages
In-Reply-To: <455f0a04-0edb-960a-f62a-7ba8c69a86b7@oracle.com>
References: <455f0a04-0edb-960a-f62a-7ba8c69a86b7@oracle.com>
Message-ID: <509c7604-ad27-d922-6547-64804ac16b75@oracle.com>

Looks good.

/Erik


On 2017-05-16 12:01, Magnus Ihse Bursie wrote:
> There are 2 problems in the Doc.gmk file with respect to setting up 
> the footer option for javadoc.
> 1. Line 55.
> JAVADOC_BASE_URL := 
> http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=homepage
> The & should be escaped as an entity and should be &amp; by the time 
> the string gets passed into javadoc.
>
> 2. Line 134
> <a href="$(JAVADOC_BASE_URL)/index.html" target="_blank">Java SE \
> /index.html is being added to the string being passed into javadoc. 
> That is wrong and causes a 404 when you click onthe link in the 
> generated pages.
>
> Also, with the new base URL the -Xdocrootparent does not make sense, 
> since you can't append a relative path to it. If a derived version of 
> OpenJDK wants to patch Docs.gmk to provide a different 
> JAVADOC_BASE_URL, they'll also have to patch it to explicitly provide 
> a -Xdocrootparent flag. But as OpenJDK by itself looks, the 
> -Xdocrootparent flag is just broken.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180328
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180328-bad-docroot/webrev.01
>
> /Magnus
>



From magnus.ihse.bursie at oracle.com  Wed May 17 08:00:56 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 17 May 2017 10:00:56 +0200
Subject: RFR: JDK-8180472 Pandoc should generate html5 from markdown
Message-ID: <78619bdc-7233-738c-309c-9b200b551839@oracle.com>

HTML files created by markdown should adhere to html5, in line with the 
general effort to make all documentation html5 compliant.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180472
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8180472-pandoc-should-use-html5/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Wed May 17 08:16:59 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 17 May 2017 10:16:59 +0200
Subject: RFR: JDK-8180426 Use standard css file for new docs bundle index.html
 page
Message-ID: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>

In JDK-8180208, a new top-level index.html for the entire docs image was 
created.

This should use the common jdk-default.css file, which should move out 
of the specs directory.

Here is an example how the generated page looks like:
http://cr.openjdk.java.net/~ihse/demo-docs-index-with-default-css/

Bug: https://bugs.openjdk.java.net/browse/JDK-8180426
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Wed May 17 08:49:03 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 17 May 2017 10:49:03 +0200
Subject: RFR: JDK-8180318 Enable HTML 5 checking at compile time
Message-ID: <75b91e46-b940-e2c2-a9f8-db571a07cdde@oracle.com>

JDK-8175036 enables HTML 5 when generating the API docs.

javac runs doclint at compile time, but remains configured for HTML 4. 
We should update the compilation steps to use HTML 5 except where 
exceptions are needed.

Note that two modules, java.base and java.desktop, is currently not 
fully html5 compliant, which generates warning which fails the build. In 
this patch, they have still html5 checking disabled.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180318
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8180318-enable-doclint-format-html5/webrev.01

/Magnus


From erik.joelsson at oracle.com  Wed May 17 09:19:06 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 May 2017 11:19:06 +0200
Subject: RFR: JDK-8180472 Pandoc should generate html5 from markdown
In-Reply-To: <78619bdc-7233-738c-309c-9b200b551839@oracle.com>
References: <78619bdc-7233-738c-309c-9b200b551839@oracle.com>
Message-ID: <595361fc-1ae6-9961-4651-177455d82d15@oracle.com>

Looks good.

/Erik


On 2017-05-17 10:00, Magnus Ihse Bursie wrote:
> HTML files created by markdown should adhere to html5, in line with 
> the general effort to make all documentation html5 compliant.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180472
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180472-pandoc-should-use-html5/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Wed May 17 09:23:10 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 May 2017 11:23:10 +0200
Subject: RFR: JDK-8180426 Use standard css file for new docs bundle
 index.html page
In-Reply-To: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>
References: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>
Message-ID: <40338f49-c842-7290-69c0-9a605de58fb4@oracle.com>

Looks ok. Note that adding the global resources copy targets to two 
different top level targets may cause race conditions in rare cases 
depending on OS and file system.

/Erik


On 2017-05-17 10:16, Magnus Ihse Bursie wrote:
> In JDK-8180208, a new top-level index.html for the entire docs image 
> was created.
>
> This should use the common jdk-default.css file, which should move out 
> of the specs directory.
>
> Here is an example how the generated page looks like:
> http://cr.openjdk.java.net/~ihse/demo-docs-index-with-default-css/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180426
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Wed May 17 09:24:26 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 May 2017 11:24:26 +0200
Subject: RFR: JDK-8180318 Enable HTML 5 checking at compile time
In-Reply-To: <75b91e46-b940-e2c2-a9f8-db571a07cdde@oracle.com>
References: <75b91e46-b940-e2c2-a9f8-db571a07cdde@oracle.com>
Message-ID: <3f6ec42d-bdb7-d70d-5d7a-cea652f3d42e@oracle.com>

Looks good.

/Erik


On 2017-05-17 10:49, Magnus Ihse Bursie wrote:
> JDK-8175036 enables HTML 5 when generating the API docs.
>
> javac runs doclint at compile time, but remains configured for HTML 4. 
> We should update the compilation steps to use HTML 5 except where 
> exceptions are needed.
>
> Note that two modules, java.base and java.desktop, is currently not 
> fully html5 compliant, which generates warning which fails the build. 
> In this patch, they have still html5 checking disabled.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180318
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180318-enable-doclint-format-html5/webrev.01
>
> /Magnus



From prasanta.sadhukhan at oracle.com  Wed May 17 10:31:32 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 17 May 2017 16:01:32 +0530
Subject: [10] RFR JDK-6461834: Minimize WindowsLookAndFeel classes included
 with Unix JDKs
Message-ID: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>

Hi All,

Please review a fix for an issue whereby it is seen that 
WindowsLookAndFeel classes are built for non-windows platform,
where it is not needed.
Proposed fix is to remove building these classes for non-windows platform.

JPRT build is successful. Also, fixed the regression tests which expects 
this classes to be available in non-unix platform.

Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/

There are some closed regression test which will be taken care after 
this in a separate crucible review.

Regards
Prasanta


From magnus.ihse.bursie at oracle.com  Wed May 17 10:41:44 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 17 May 2017 12:41:44 +0200
Subject: RFR: JDK-8180426 Use standard css file for new docs bundle
 index.html page
In-Reply-To: <40338f49-c842-7290-69c0-9a605de58fb4@oracle.com>
References: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>
 <40338f49-c842-7290-69c0-9a605de58fb4@oracle.com>
Message-ID: <6cebfe0b-2d10-187e-ae79-19f982ae185a@oracle.com>



On 2017-05-17 11:23, Erik Joelsson wrote:
> Looks ok. Note that adding the global resources copy targets to two 
> different top level targets may cause race conditions in rare cases 
> depending on OS and file system.

Do you propose that I solve it in a different way? I was thinking of 
moving the copy of resources to only the "index" which feels more 
"top-level" than the "specs" target, to avoid this duplication. But this 
also has the unfortunate effect that docs-jdk-specs no longer creates 
correctly working specs. Seems to be no good way out of this. :-(

/Magnus

>
> /Erik
>
>
> On 2017-05-17 10:16, Magnus Ihse Bursie wrote:
>> In JDK-8180208, a new top-level index.html for the entire docs image 
>> was created.
>>
>> This should use the common jdk-default.css file, which should move 
>> out of the specs directory.
>>
>> Here is an example how the generated page looks like:
>> http://cr.openjdk.java.net/~ihse/demo-docs-index-with-default-css/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180426
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.01
>>
>> /Magnus
>



From magnus.ihse.bursie at oracle.com  Wed May 17 10:46:52 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 17 May 2017 12:46:52 +0200
Subject: [10] RFR JDK-6461834: Minimize WindowsLookAndFeel classes
 included with Unix JDKs
In-Reply-To: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
Message-ID: <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>

Build changes looks good. However in 
src/java.desktop/share/classes/module-info.java you are trying to check 
in commented-out code instead of removing it.

/Magnus

On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a fix for an issue whereby it is seen that 
> WindowsLookAndFeel classes are built for non-windows platform,
> where it is not needed.
> Proposed fix is to remove building these classes for non-windows 
> platform.
>
> JPRT build is successful. Also, fixed the regression tests which 
> expects this classes to be available in non-unix platform.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>
> There are some closed regression test which will be taken care after 
> this in a separate crucible review.
>
> Regards
> Prasanta



From prasanta.sadhukhan at oracle.com  Wed May 17 10:49:14 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 17 May 2017 16:19:14 +0530
Subject: [10] RFR JDK-6461834: Minimize WindowsLookAndFeel classes
 included with Unix JDKs
In-Reply-To: <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
Message-ID: <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>

Yes, actually I am bit unsure of how to proceed with that. It is meant 
to open internal java.desktop classes "only" to jdk.jconsole but now 
afer this fix, these classes will only be available in windows platform, 
so it should be a conditional "open" and I am not sure if 
module-info.java allows conditional open.

Regards
Prasanta
On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
> Build changes looks good. However in 
> src/java.desktop/share/classes/module-info.java you are trying to 
> check in commented-out code instead of removing it.
>
> /Magnus
>
> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for an issue whereby it is seen that 
>> WindowsLookAndFeel classes are built for non-windows platform,
>> where it is not needed.
>> Proposed fix is to remove building these classes for non-windows 
>> platform.
>>
>> JPRT build is successful. Also, fixed the regression tests which 
>> expects this classes to be available in non-unix platform.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>
>> There are some closed regression test which will be taken care after 
>> this in a separate crucible review.
>>
>> Regards
>> Prasanta
>



From erik.joelsson at oracle.com  Wed May 17 11:24:28 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 May 2017 13:24:28 +0200
Subject: [10] RFR JDK-6461834: Minimize WindowsLookAndFeel classes
 included with Unix JDKs
In-Reply-To: <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
 <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
Message-ID: <fd2ac322-e9a3-7d9e-9600-59a61e73be4c@oracle.com>

Instead of adding more explicit excludes, I would recommend moving the 
windows specific source files to:

jdk/src/java.desktop/windows/classes

That is the intended way of making sources platform specific.

If you still need to add the qualified export to jdk.jconsole, but just 
for windows, you can achieve this by creating:

jdk/src/java.desktop/windows/classes/module-info.java.extra

With the following content (+copyright header):

opens com.sun.java.swing.plaf.windows to jdk.jconsole

/Erik


On 2017-05-17 12:49, Prasanta Sadhukhan wrote:
> Yes, actually I am bit unsure of how to proceed with that. It is meant 
> to open internal java.desktop classes "only" to jdk.jconsole but now 
> afer this fix, these classes will only be available in windows 
> platform, so it should be a conditional "open" and I am not sure if 
> module-info.java allows conditional open.
>
> Regards
> Prasanta
> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>> Build changes looks good. However in 
>> src/java.desktop/share/classes/module-info.java you are trying to 
>> check in commented-out code instead of removing it.
>>
>> /Magnus
>>
>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue whereby it is seen that 
>>> WindowsLookAndFeel classes are built for non-windows platform,
>>> where it is not needed.
>>> Proposed fix is to remove building these classes for non-windows 
>>> platform.
>>>
>>> JPRT build is successful. Also, fixed the regression tests which 
>>> expects this classes to be available in non-unix platform.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>>
>>> There are some closed regression test which will be taken care after 
>>> this in a separate crucible review.
>>>
>>> Regards
>>> Prasanta
>>
>



From erik.joelsson at oracle.com  Wed May 17 11:27:47 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 May 2017 13:27:47 +0200
Subject: RFR: JDK-8180426 Use standard css file for new docs bundle
 index.html page
In-Reply-To: <6cebfe0b-2d10-187e-ae79-19f982ae185a@oracle.com>
References: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>
 <40338f49-c842-7290-69c0-9a605de58fb4@oracle.com>
 <6cebfe0b-2d10-187e-ae79-19f982ae185a@oracle.com>
Message-ID: <cf5e1f0d-54b1-ada6-8456-562bbcb65da3@oracle.com>

I realize the dilemma. The clean solution is to define yet another top 
level target for just this file. It's also possible that this race will 
never cause problems, I don't know for sure.

/Erik


On 2017-05-17 12:41, Magnus Ihse Bursie wrote:
>
>
> On 2017-05-17 11:23, Erik Joelsson wrote:
>> Looks ok. Note that adding the global resources copy targets to two 
>> different top level targets may cause race conditions in rare cases 
>> depending on OS and file system.
>
> Do you propose that I solve it in a different way? I was thinking of 
> moving the copy of resources to only the "index" which feels more 
> "top-level" than the "specs" target, to avoid this duplication. But 
> this also has the unfortunate effect that docs-jdk-specs no longer 
> creates correctly working specs. Seems to be no good way out of this. :-(
>
> /Magnus
>
>>
>> /Erik
>>
>>
>> On 2017-05-17 10:16, Magnus Ihse Bursie wrote:
>>> In JDK-8180208, a new top-level index.html for the entire docs image 
>>> was created.
>>>
>>> This should use the common jdk-default.css file, which should move 
>>> out of the specs directory.
>>>
>>> Here is an example how the generated page looks like:
>>> http://cr.openjdk.java.net/~ihse/demo-docs-index-with-default-css/
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180426
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.01
>>>
>>> /Magnus
>>
>



From magnus.ihse.bursie at oracle.com  Wed May 17 13:44:22 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 17 May 2017 15:44:22 +0200
Subject: RFR: JDK-8180426 Use standard css file for new docs bundle
 index.html page
In-Reply-To: <cf5e1f0d-54b1-ada6-8456-562bbcb65da3@oracle.com>
References: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>
 <40338f49-c842-7290-69c0-9a605de58fb4@oracle.com>
 <6cebfe0b-2d10-187e-ae79-19f982ae185a@oracle.com>
 <cf5e1f0d-54b1-ada6-8456-562bbcb65da3@oracle.com>
Message-ID: <3a6806be-3728-8e20-be05-b3e92bd4074b@oracle.com>

On 2017-05-17 13:27, Erik Joelsson wrote:
> I realize the dilemma. The clean solution is to define yet another top 
> level target for just this file. It's also possible that this race 
> will never cause problems, I don't know for sure.

Here's an updated version:
http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.02

According to our credo, I prefer:
* not to introduce races
* not to duplicate work
* make sure a make target delivers everything that's needed
* ... even if the above in the end results in executing more build logic

So I've removed the copying from specs and only kept it at the index, 
but then in Main.gmk I made specs depend on index. This will be safe, 
and if, in the future, it turns out to be to burdensome for developers 
just wanting to make specs, we'll have to break out the resource copying 
from the index target.

I also shortened the "index" related variables even more.

/Magnus


>
> /Erik
>
>
> On 2017-05-17 12:41, Magnus Ihse Bursie wrote:
>>
>>
>> On 2017-05-17 11:23, Erik Joelsson wrote:
>>> Looks ok. Note that adding the global resources copy targets to two 
>>> different top level targets may cause race conditions in rare cases 
>>> depending on OS and file system.
>>
>> Do you propose that I solve it in a different way? I was thinking of 
>> moving the copy of resources to only the "index" which feels more 
>> "top-level" than the "specs" target, to avoid this duplication. But 
>> this also has the unfortunate effect that docs-jdk-specs no longer 
>> creates correctly working specs. Seems to be no good way out of this. 
>> :-(
>>
>> /Magnus
>>
>>>
>>> /Erik
>>>
>>>
>>> On 2017-05-17 10:16, Magnus Ihse Bursie wrote:
>>>> In JDK-8180208, a new top-level index.html for the entire docs 
>>>> image was created.
>>>>
>>>> This should use the common jdk-default.css file, which should move 
>>>> out of the specs directory.
>>>>
>>>> Here is an example how the generated page looks like:
>>>> http://cr.openjdk.java.net/~ihse/demo-docs-index-with-default-css/
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180426
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.01
>>>>
>>>> /Magnus
>>>
>>
>



From mandy.chung at oracle.com  Wed May 17 15:03:30 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 17 May 2017 08:03:30 -0700
Subject: RFR: JDK-8180426 Use standard css file for new docs bundle
 index.html page
In-Reply-To: <3a6806be-3728-8e20-be05-b3e92bd4074b@oracle.com>
References: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>
 <40338f49-c842-7290-69c0-9a605de58fb4@oracle.com>
 <6cebfe0b-2d10-187e-ae79-19f982ae185a@oracle.com>
 <cf5e1f0d-54b1-ada6-8456-562bbcb65da3@oracle.com>
 <3a6806be-3728-8e20-be05-b3e92bd4074b@oracle.com>
Message-ID: <4C459C6C-285D-4F80-8353-52A107D5195F@oracle.com>


> On May 17, 2017, at 6:44 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2017-05-17 13:27, Erik Joelsson wrote:
>> I realize the dilemma. The clean solution is to define yet another top level target for just this file. It's also possible that this race will never cause problems, I don't know for sure.
> 
> Here's an updated version:
> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.02

Looks good.

Mandy

From erik.joelsson at oracle.com  Wed May 17 15:14:11 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 May 2017 17:14:11 +0200
Subject: RFR: JDK-8180426 Use standard css file for new docs bundle
 index.html page
In-Reply-To: <3a6806be-3728-8e20-be05-b3e92bd4074b@oracle.com>
References: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>
 <40338f49-c842-7290-69c0-9a605de58fb4@oracle.com>
 <6cebfe0b-2d10-187e-ae79-19f982ae185a@oracle.com>
 <cf5e1f0d-54b1-ada6-8456-562bbcb65da3@oracle.com>
 <3a6806be-3728-8e20-be05-b3e92bd4074b@oracle.com>
Message-ID: <4ed7fbee-62e4-d39f-5bef-fa49560e4df6@oracle.com>

Hah, that seems like a reasonable solution to me. The index page 
generation shouldn't be heavy enough to be a problem here.

Looks good.

/Erik


On 2017-05-17 15:44, Magnus Ihse Bursie wrote:
> On 2017-05-17 13:27, Erik Joelsson wrote:
>> I realize the dilemma. The clean solution is to define yet another 
>> top level target for just this file. It's also possible that this 
>> race will never cause problems, I don't know for sure.
>
> Here's an updated version:
> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.02 
>
>
> According to our credo, I prefer:
> * not to introduce races
> * not to duplicate work
> * make sure a make target delivers everything that's needed
> * ... even if the above in the end results in executing more build logic
>
> So I've removed the copying from specs and only kept it at the index, 
> but then in Main.gmk I made specs depend on index. This will be safe, 
> and if, in the future, it turns out to be to burdensome for developers 
> just wanting to make specs, we'll have to break out the resource 
> copying from the index target.
>
> I also shortened the "index" related variables even more.
>
> /Magnus
>
>
>>
>> /Erik
>>
>>
>> On 2017-05-17 12:41, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2017-05-17 11:23, Erik Joelsson wrote:
>>>> Looks ok. Note that adding the global resources copy targets to two 
>>>> different top level targets may cause race conditions in rare cases 
>>>> depending on OS and file system.
>>>
>>> Do you propose that I solve it in a different way? I was thinking of 
>>> moving the copy of resources to only the "index" which feels more 
>>> "top-level" than the "specs" target, to avoid this duplication. But 
>>> this also has the unfortunate effect that docs-jdk-specs no longer 
>>> creates correctly working specs. Seems to be no good way out of 
>>> this. :-(
>>>
>>> /Magnus
>>>
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-05-17 10:16, Magnus Ihse Bursie wrote:
>>>>> In JDK-8180208, a new top-level index.html for the entire docs 
>>>>> image was created.
>>>>>
>>>>> This should use the common jdk-default.css file, which should move 
>>>>> out of the specs directory.
>>>>>
>>>>> Here is an example how the generated page looks like:
>>>>> http://cr.openjdk.java.net/~ihse/demo-docs-index-with-default-css/
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180426
>>>>> WebRev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.01
>>>>>
>>>>> /Magnus
>>>>
>>>
>>
>



From philip.race at oracle.com  Wed May 17 19:06:51 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 12:06:51 -0700
Subject: [10] RFR JDK-6461834: Minimize WindowsLookAndFeel classes
 included with Unix JDKs
In-Reply-To: <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
 <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
Message-ID: <8acad3b1-1e45-3c69-970b-d492d05790c3@oracle.com>

The way to do this is to create a file
src/java.desktop/windows/classes/module-info.java.extra

and move the opens there.

See for example
src/java.base/windows/classes/module-info.java.extra

But are you sure jdk.jconsole needs these only on Windows ?
Better make sure of it.

-phil.

On 05/17/2017 03:49 AM, Prasanta Sadhukhan wrote:
> Yes, actually I am bit unsure of how to proceed with that. It is meant 
> to open internal java.desktop classes "only" to jdk.jconsole but now 
> afer this fix, these classes will only be available in windows 
> platform, so it should be a conditional "open" and I am not sure if 
> module-info.java allows conditional open.
>
> Regards
> Prasanta
> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>> Build changes looks good. However in 
>> src/java.desktop/share/classes/module-info.java you are trying to 
>> check in commented-out code instead of removing it.
>>
>> /Magnus
>>
>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue whereby it is seen that 
>>> WindowsLookAndFeel classes are built for non-windows platform,
>>> where it is not needed.
>>> Proposed fix is to remove building these classes for non-windows 
>>> platform.
>>>
>>> JPRT build is successful. Also, fixed the regression tests which 
>>> expects this classes to be available in non-unix platform.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>>
>>> There are some closed regression test which will be taken care after 
>>> this in a separate crucible review.
>>>
>>> Regards
>>> Prasanta
>>
>



From bradford.wetmore at oracle.com  Thu May 18 00:07:08 2017
From: bradford.wetmore at oracle.com (Brad R. Wetmore)
Date: Wed, 17 May 2017 17:07:08 -0700
Subject: CR: 8180540: Add pandoc build fix for windows
Message-ID: <77fc2698-3f2b-7461-4960-2954fac1e0f6@oracle.com>

Magnus,

I've added your suggested fix to spec.gmk.in, which is the minor tweak 
to add @FIXPATH@ to allow pandoc to run on windows builds.

     https://bugs.openjdk.java.net/browse/JDK-8180540
     http://cr.openjdk.java.net/~wetmore/8180540/webrev.00/

I put you down as Contributed-by: with myself as reviewer, but thought 
you (and others?) might want to at least check it.

Thanks,

Brad


From david.holmes at oracle.com  Thu May 18 06:25:59 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 16:25:59 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and Parker
 code for POSIX systems
Message-ID: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>

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

webrevs:

Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
       hotspot: http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/

First a big thank you to Thomas Stuefe for testing various versions of 
this on AIX.

This is primarily a refactoring and cleanup exercise (ie lots of deleted 
duplicated code!).

I have taken the PlatformEvent, PlatformParker and Parker::* code, out 
of os_linux and moved it into os_posix for use by Linux, OSX, BSD, AIX 
and perhaps one day Solaris (more on that later).

The Linux code was the most functionally complete, dealing with correct 
use of CLOCK_MONOTONIC for relative timed waits, and the default 
wall-clock for absolute timed waits. That functionality is not, 
unfortunately, supported by all our POSIX platforms so there are some 
configure time build checks to set some #defines, and then some dynamic 
lookup at runtime**. We allow for the runtime environment to be less 
capable than the build environment, but not the other way around 
(without build time support we don't know the runtime types needed to 
make library calls).

** There is some duplication of dynamic lookup code on Linux but this 
can be cleaned up in future work if we refactor the time/clock code into 
os_posix as well.

The cleanup covers a number of things:
- removal of linux anachronisms that got "ported" into the other platforms
   - eg EINTR can not be returned from the wait methods
- removal of solaris anachronisms that got ported into the linux code 
and then on to other platforms
   - eg ETIMEDOUT is what we expect never ETIME
- removal of the ancient/obsolete os::*::allowdebug_blocked_signals() 
from the Parker methods
- consolidation of unpackTime and compute_abstime into one utility function
- use statics for things completely private to the implementation rather 
than making them part of the os* API (eg access to condAttr objects)
- cleanup up commentary and style within methods of the same class
- clean up coding style in places eg not using Names that start with 
capitals.

I have not tried to cleanup every single oddity, nor tried to reconcile 
differences between the very similar in places PlatformEvent and Park 
methods. For example PlatformEvent still examines the 
FilterSpuriousWakeups** flag, and Parker still ignores it.

** Perhaps a candidate for deprecation and future removal.

There is one mini "enhancement" slipped in this. I now explicitly 
initialize mutexes with a mutexAttr object with its type set to 
PTHREAD_MUTEX_NORMAL, instead of relying on the definition of 
PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but 
"error checking" and so is slow. On all other current platforms there is 
no effective change.

Finally, Solaris is excluded from all this (other than the debug signal 
blocking cleanup) because it potentially supports three different 
low-level sync subsystems: UI thr*, Pthread, and direct LWP sync. 
Solaris cleanup would be a separate RFE.

No doubt I've overlooked mentioning something that someone will spot. :)

Thanks,
David


From magnus.ihse.bursie at oracle.com  Thu May 18 07:26:00 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 May 2017 09:26:00 +0200
Subject: RFR: JDK-8180426 Use standard css file for new docs bundle
 index.html page
In-Reply-To: <4ed7fbee-62e4-d39f-5bef-fa49560e4df6@oracle.com>
References: <ddcbf17c-e3ae-60a4-98ac-6bfd14627aa0@oracle.com>
 <40338f49-c842-7290-69c0-9a605de58fb4@oracle.com>
 <6cebfe0b-2d10-187e-ae79-19f982ae185a@oracle.com>
 <cf5e1f0d-54b1-ada6-8456-562bbcb65da3@oracle.com>
 <3a6806be-3728-8e20-be05-b3e92bd4074b@oracle.com>
 <4ed7fbee-62e4-d39f-5bef-fa49560e4df6@oracle.com>
Message-ID: <7355c49d-d9aa-de3d-a0f9-b3317b2ac5f8@oracle.com>

On 2017-05-17 17:14, Erik Joelsson wrote:
> Hah, that seems like a reasonable solution to me. The index page 
> generation shouldn't be heavy enough to be a problem here.

It's not the generation in itself, it's its dependencies that are heavy, 
compared to plain docs-jdk-specs.

But, most use cases will build -api, -specs and -index at the same time 
anyway, so it's probably not a big deal. Otherwise, we'll have to deal 
with it later.

/Magnus

>
> Looks good.
>
> /Erik
>
>
> On 2017-05-17 15:44, Magnus Ihse Bursie wrote:
>> On 2017-05-17 13:27, Erik Joelsson wrote:
>>> I realize the dilemma. The clean solution is to define yet another 
>>> top level target for just this file. It's also possible that this 
>>> race will never cause problems, I don't know for sure.
>>
>> Here's an updated version:
>> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.02 
>>
>>
>> According to our credo, I prefer:
>> * not to introduce races
>> * not to duplicate work
>> * make sure a make target delivers everything that's needed
>> * ... even if the above in the end results in executing more build logic
>>
>> So I've removed the copying from specs and only kept it at the index, 
>> but then in Main.gmk I made specs depend on index. This will be safe, 
>> and if, in the future, it turns out to be to burdensome for 
>> developers just wanting to make specs, we'll have to break out the 
>> resource copying from the index target.
>>
>> I also shortened the "index" related variables even more.
>>
>> /Magnus
>>
>>
>>>
>>> /Erik
>>>
>>>
>>> On 2017-05-17 12:41, Magnus Ihse Bursie wrote:
>>>>
>>>>
>>>> On 2017-05-17 11:23, Erik Joelsson wrote:
>>>>> Looks ok. Note that adding the global resources copy targets to 
>>>>> two different top level targets may cause race conditions in rare 
>>>>> cases depending on OS and file system.
>>>>
>>>> Do you propose that I solve it in a different way? I was thinking 
>>>> of moving the copy of resources to only the "index" which feels 
>>>> more "top-level" than the "specs" target, to avoid this 
>>>> duplication. But this also has the unfortunate effect that 
>>>> docs-jdk-specs no longer creates correctly working specs. Seems to 
>>>> be no good way out of this. :-(
>>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>> On 2017-05-17 10:16, Magnus Ihse Bursie wrote:
>>>>>> In JDK-8180208, a new top-level index.html for the entire docs 
>>>>>> image was created.
>>>>>>
>>>>>> This should use the common jdk-default.css file, which should 
>>>>>> move out of the specs directory.
>>>>>>
>>>>>> Here is an example how the generated page looks like:
>>>>>> http://cr.openjdk.java.net/~ihse/demo-docs-index-with-default-css/
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180426
>>>>>> WebRev: 
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8180426-use-css-for-bundle-index-page/webrev.01
>>>>>>
>>>>>> /Magnus
>>>>>
>>>>
>>>
>>
>



From magnus.ihse.bursie at oracle.com  Thu May 18 07:27:12 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 May 2017 09:27:12 +0200
Subject: CR: 8180540: Add pandoc build fix for windows
In-Reply-To: <77fc2698-3f2b-7461-4960-2954fac1e0f6@oracle.com>
References: <77fc2698-3f2b-7461-4960-2954fac1e0f6@oracle.com>
Message-ID: <03c14885-d07b-96bb-957a-0927b9f6f5b5@oracle.com>

Looks good. Formally, I believe someone else needs to review it.

/Magnus

On 2017-05-18 02:07, Brad R. Wetmore wrote:
> Magnus,
>
> I've added your suggested fix to spec.gmk.in, which is the minor tweak 
> to add @FIXPATH@ to allow pandoc to run on windows builds.
>
>     https://bugs.openjdk.java.net/browse/JDK-8180540
>     http://cr.openjdk.java.net/~wetmore/8180540/webrev.00/
>
> I put you down as Contributed-by: with myself as reviewer, but thought 
> you (and others?) might want to at least check it.
>
> Thanks,
>
> Brad



From magnus.ihse.bursie at oracle.com  Thu May 18 07:32:27 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 May 2017 09:32:27 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
Message-ID: <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>

On 2017-05-18 08:25, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>
> webrevs:
>
> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/

Build changes look  good.

/Magnus

>       hotspot: 
> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>
> First a big thank you to Thomas Stuefe for testing various versions of 
> this on AIX.
>
> This is primarily a refactoring and cleanup exercise (ie lots of 
> deleted duplicated code!).
>
> I have taken the PlatformEvent, PlatformParker and Parker::* code, out 
> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, AIX 
> and perhaps one day Solaris (more on that later).
>
> The Linux code was the most functionally complete, dealing with 
> correct use of CLOCK_MONOTONIC for relative timed waits, and the 
> default wall-clock for absolute timed waits. That functionality is 
> not, unfortunately, supported by all our POSIX platforms so there are 
> some configure time build checks to set some #defines, and then some 
> dynamic lookup at runtime**. We allow for the runtime environment to 
> be less capable than the build environment, but not the other way 
> around (without build time support we don't know the runtime types 
> needed to make library calls).
>
> ** There is some duplication of dynamic lookup code on Linux but this 
> can be cleaned up in future work if we refactor the time/clock code 
> into os_posix as well.
>
> The cleanup covers a number of things:
> - removal of linux anachronisms that got "ported" into the other 
> platforms
>   - eg EINTR can not be returned from the wait methods
> - removal of solaris anachronisms that got ported into the linux code 
> and then on to other platforms
>   - eg ETIMEDOUT is what we expect never ETIME
> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals() 
> from the Parker methods
> - consolidation of unpackTime and compute_abstime into one utility 
> function
> - use statics for things completely private to the implementation 
> rather than making them part of the os* API (eg access to condAttr 
> objects)
> - cleanup up commentary and style within methods of the same class
> - clean up coding style in places eg not using Names that start with 
> capitals.
>
> I have not tried to cleanup every single oddity, nor tried to 
> reconcile differences between the very similar in places PlatformEvent 
> and Park methods. For example PlatformEvent still examines the 
> FilterSpuriousWakeups** flag, and Parker still ignores it.
>
> ** Perhaps a candidate for deprecation and future removal.
>
> There is one mini "enhancement" slipped in this. I now explicitly 
> initialize mutexes with a mutexAttr object with its type set to 
> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of 
> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but 
> "error checking" and so is slow. On all other current platforms there 
> is no effective change.
>
> Finally, Solaris is excluded from all this (other than the debug 
> signal blocking cleanup) because it potentially supports three 
> different low-level sync subsystems: UI thr*, Pthread, and direct LWP 
> sync. Solaris cleanup would be a separate RFE.
>
> No doubt I've overlooked mentioning something that someone will spot. :)
>
> Thanks,
> David



From david.holmes at oracle.com  Thu May 18 07:35:09 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 17:35:09 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
Message-ID: <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>

On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
> On 2017-05-18 08:25, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>
>> webrevs:
>>
>> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>
> Build changes look  good.

Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging 
prints outs - do you want me to remove them? I suppose they may be 
useful if something goes wrong on some platform.

David

> /Magnus
>
>>       hotspot:
>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>
>> First a big thank you to Thomas Stuefe for testing various versions of
>> this on AIX.
>>
>> This is primarily a refactoring and cleanup exercise (ie lots of
>> deleted duplicated code!).
>>
>> I have taken the PlatformEvent, PlatformParker and Parker::* code, out
>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, AIX
>> and perhaps one day Solaris (more on that later).
>>
>> The Linux code was the most functionally complete, dealing with
>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>> default wall-clock for absolute timed waits. That functionality is
>> not, unfortunately, supported by all our POSIX platforms so there are
>> some configure time build checks to set some #defines, and then some
>> dynamic lookup at runtime**. We allow for the runtime environment to
>> be less capable than the build environment, but not the other way
>> around (without build time support we don't know the runtime types
>> needed to make library calls).
>>
>> ** There is some duplication of dynamic lookup code on Linux but this
>> can be cleaned up in future work if we refactor the time/clock code
>> into os_posix as well.
>>
>> The cleanup covers a number of things:
>> - removal of linux anachronisms that got "ported" into the other
>> platforms
>>   - eg EINTR can not be returned from the wait methods
>> - removal of solaris anachronisms that got ported into the linux code
>> and then on to other platforms
>>   - eg ETIMEDOUT is what we expect never ETIME
>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>> from the Parker methods
>> - consolidation of unpackTime and compute_abstime into one utility
>> function
>> - use statics for things completely private to the implementation
>> rather than making them part of the os* API (eg access to condAttr
>> objects)
>> - cleanup up commentary and style within methods of the same class
>> - clean up coding style in places eg not using Names that start with
>> capitals.
>>
>> I have not tried to cleanup every single oddity, nor tried to
>> reconcile differences between the very similar in places PlatformEvent
>> and Park methods. For example PlatformEvent still examines the
>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>
>> ** Perhaps a candidate for deprecation and future removal.
>>
>> There is one mini "enhancement" slipped in this. I now explicitly
>> initialize mutexes with a mutexAttr object with its type set to
>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>> "error checking" and so is slow. On all other current platforms there
>> is no effective change.
>>
>> Finally, Solaris is excluded from all this (other than the debug
>> signal blocking cleanup) because it potentially supports three
>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>> sync. Solaris cleanup would be a separate RFE.
>>
>> No doubt I've overlooked mentioning something that someone will spot. :)
>>
>> Thanks,
>> David
>


From magnus.ihse.bursie at oracle.com  Thu May 18 07:40:56 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 May 2017 09:40:56 +0200
Subject: RFR: JDK-8180486 extLink taglet needs escaped &quot;&amp;&quot;
Message-ID: <b9ab47a3-152e-ebe0-5ed0-6633ed77e8b2@oracle.com>

The extLink taglet that was introduced in JDK-8178725 has a "&" in the 
base URL segment, which needs to be expressed as "&amp;" instead.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180486
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8180486-extLink-taglet-needs-escaped-ampersand/webrev.01

/Magnus



From david.holmes at oracle.com  Thu May 18 07:46:40 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 17:46:40 +1000
Subject: RFR: JDK-8180486 extLink taglet needs escaped &quot;&amp;&quot;
In-Reply-To: <b9ab47a3-152e-ebe0-5ed0-6633ed77e8b2@oracle.com>
References: <b9ab47a3-152e-ebe0-5ed0-6633ed77e8b2@oracle.com>
Message-ID: <9ad0fa97-41dd-ab85-2e04-db1d2ba61e53@oracle.com>

Looks fine.

Thanks,
David

On 18/05/2017 5:40 PM, Magnus Ihse Bursie wrote:
> The extLink taglet that was introduced in JDK-8178725 has a "&" in the
> base URL segment, which needs to be expressed as "&amp;" instead.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180486
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8180486-extLink-taglet-needs-escaped-ampersand/webrev.01
>
>
> /Magnus
>


From magnus.ihse.bursie at oracle.com  Thu May 18 07:54:03 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 May 2017 09:54:03 +0200
Subject: RFR: JDK-8180480 Use "requires transitive" relationship when
 determining modules for javadoc
Message-ID: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>

When the build system tries to figure out which modules that should be 
included by the javadoc build, it locates the set of modules "required" 
by already included modules, starting from an initial set and repeating 
recursively (a method which we unfortunately called "transitive").

However, for javadoc, we should only look at those re-exported modules 
that are classified by a "requires transitive" relationship (which I 
therefore have called "re-exported" to not clash with the established 
term "transitive").

The effect of getting this wrong is e.g. that we copy module graph png 
files that we should not, and that we look at too broad a set of files 
for looking at changes that should trigger a re-build of the javadoc.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180480
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.01

/Magnus


From prasanta.sadhukhan at oracle.com  Thu May 18 08:01:55 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 18 May 2017 13:31:55 +0530
Subject: [10] RFR JDK-6461834: Minimize WindowsLookAndFeel classes
 included with Unix JDKs
In-Reply-To: <8acad3b1-1e45-3c69-970b-d492d05790c3@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
 <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
 <8acad3b1-1e45-3c69-970b-d492d05790c3@oracle.com>
Message-ID: <21fb6605-e4d3-657c-766c-0a93cd15f721@oracle.com>

So far I have looked, it seems jdk.jconsole uses this classes for 
windows only. These classes are specified in
JConsole.java where it checks (for non-windows, it will come as 
GTKLookAndFeel)

String systemLaF = UIManager.getSystemLookAndFeelClassName();
if (systemLaF.equals("com.sun.java.swing.plaf.gtk.GTKLookAndFeel") ||
systemLaF.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel")) {

try {
UIManager.setLookAndFeel(systemLaF); MaximizableInternalFrame.java where 
it checks for this classes in windows only if (JConsole.IS_WIN) {
try {
Class<?> Part =
Class.forName("com.sun.java.swing.plaf.windows.TMSchema$Part"); and 
Utilities.java where it checks LookAndFeel laf = UIManager.getLookAndFeel();
boolean transparent = laf.getClass().getName().equals(windowsLaF);

Modified webrev
http://cr.openjdk.java.net/~psadhukhan/6461834/01/

Regards
Prasanta

On 5/18/2017 12:36 AM, Phil Race wrote:
> The way to do this is to create a file
> src/java.desktop/windows/classes/module-info.java.extra
>
> and move the opens there.
>
> See for example
> src/java.base/windows/classes/module-info.java.extra
>
> But are you sure jdk.jconsole needs these only on Windows ?
> Better make sure of it.
>
> -phil.
>
> On 05/17/2017 03:49 AM, Prasanta Sadhukhan wrote:
>> Yes, actually I am bit unsure of how to proceed with that. It is 
>> meant to open internal java.desktop classes "only" to jdk.jconsole 
>> but now afer this fix, these classes will only be available in 
>> windows platform, so it should be a conditional "open" and I am not 
>> sure if module-info.java allows conditional open.
>>
>> Regards
>> Prasanta
>> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>>> Build changes looks good. However in 
>>> src/java.desktop/share/classes/module-info.java you are trying to 
>>> check in commented-out code instead of removing it.
>>>
>>> /Magnus
>>>
>>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for an issue whereby it is seen that 
>>>> WindowsLookAndFeel classes are built for non-windows platform,
>>>> where it is not needed.
>>>> Proposed fix is to remove building these classes for non-windows 
>>>> platform.
>>>>
>>>> JPRT build is successful. Also, fixed the regression tests which 
>>>> expects this classes to be available in non-unix platform.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>>>
>>>> There are some closed regression test which will be taken care 
>>>> after this in a separate crucible review.
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>



From erik.joelsson at oracle.com  Thu May 18 08:48:14 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 18 May 2017 10:48:14 +0200
Subject: CR: 8180540: Add pandoc build fix for windows
In-Reply-To: <03c14885-d07b-96bb-957a-0927b9f6f5b5@oracle.com>
References: <77fc2698-3f2b-7461-4960-2954fac1e0f6@oracle.com>
 <03c14885-d07b-96bb-957a-0927b9f6f5b5@oracle.com>
Message-ID: <73a7cf78-a836-8545-f154-2449f66ecf0f@oracle.com>

As long as pandoc for windows is always a windows native thing and not 
provided by cygwin this seems good. A quick googling indicates that 
cygwin currently does not provide pandoc so should be fine then.

/Erik


On 2017-05-18 09:27, Magnus Ihse Bursie wrote:
> Looks good. Formally, I believe someone else needs to review it.
>
> /Magnus
>
> On 2017-05-18 02:07, Brad R. Wetmore wrote:
>> Magnus,
>>
>> I've added your suggested fix to spec.gmk.in, which is the minor 
>> tweak to add @FIXPATH@ to allow pandoc to run on windows builds.
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8180540
>>     http://cr.openjdk.java.net/~wetmore/8180540/webrev.00/
>>
>> I put you down as Contributed-by: with myself as reviewer, but 
>> thought you (and others?) might want to at least check it.
>>
>> Thanks,
>>
>> Brad
>



From magnus.ihse.bursie at oracle.com  Thu May 18 10:06:58 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 May 2017 12:06:58 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
Message-ID: <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>



On 2017-05-18 09:35, David Holmes wrote:
> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>> On 2017-05-18 08:25, David Holmes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>
>>> webrevs:
>>>
>>> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>
>> Build changes look  good.
>
> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging 
> prints outs - do you want me to remove them? I suppose they may be 
> useful if something goes wrong on some platform.

I didn't even notice them. :-/

It's a bit unfortunate we don't have a debug level on the logging from 
configure. :-( Otherwise they would have clearly belonged there.

The AC_MSG_NOTICE messages stands out much from the rest of the 
configure log, so maybe it's better that you remove them. The logic 
itself is very simple, if the -D flags are missing then we can surely 
tell what happened. So yes, please remove them.

Alternatively, rewrite them as CHECKING/RESULT, if you want to keep the 
logging. That way they match better the rest of the configure log (and 
also describes what you're doing). Just check if AC_SEARCH_LIBS prints 
some output (likely so, I think), then you can't do it in the middle of 
a CHECKING/RESULT pair, but have to do the CHECKING part after 
AC_SEARCH_LIBS.

/Magnus

>
> David
>
>> /Magnus
>>
>>>       hotspot:
>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>>
>>> First a big thank you to Thomas Stuefe for testing various versions of
>>> this on AIX.
>>>
>>> This is primarily a refactoring and cleanup exercise (ie lots of
>>> deleted duplicated code!).
>>>
>>> I have taken the PlatformEvent, PlatformParker and Parker::* code, out
>>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, AIX
>>> and perhaps one day Solaris (more on that later).
>>>
>>> The Linux code was the most functionally complete, dealing with
>>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>>> default wall-clock for absolute timed waits. That functionality is
>>> not, unfortunately, supported by all our POSIX platforms so there are
>>> some configure time build checks to set some #defines, and then some
>>> dynamic lookup at runtime**. We allow for the runtime environment to
>>> be less capable than the build environment, but not the other way
>>> around (without build time support we don't know the runtime types
>>> needed to make library calls).
>>>
>>> ** There is some duplication of dynamic lookup code on Linux but this
>>> can be cleaned up in future work if we refactor the time/clock code
>>> into os_posix as well.
>>>
>>> The cleanup covers a number of things:
>>> - removal of linux anachronisms that got "ported" into the other
>>> platforms
>>>   - eg EINTR can not be returned from the wait methods
>>> - removal of solaris anachronisms that got ported into the linux code
>>> and then on to other platforms
>>>   - eg ETIMEDOUT is what we expect never ETIME
>>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>>> from the Parker methods
>>> - consolidation of unpackTime and compute_abstime into one utility
>>> function
>>> - use statics for things completely private to the implementation
>>> rather than making them part of the os* API (eg access to condAttr
>>> objects)
>>> - cleanup up commentary and style within methods of the same class
>>> - clean up coding style in places eg not using Names that start with
>>> capitals.
>>>
>>> I have not tried to cleanup every single oddity, nor tried to
>>> reconcile differences between the very similar in places PlatformEvent
>>> and Park methods. For example PlatformEvent still examines the
>>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>>
>>> ** Perhaps a candidate for deprecation and future removal.
>>>
>>> There is one mini "enhancement" slipped in this. I now explicitly
>>> initialize mutexes with a mutexAttr object with its type set to
>>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>>> "error checking" and so is slow. On all other current platforms there
>>> is no effective change.
>>>
>>> Finally, Solaris is excluded from all this (other than the debug
>>> signal blocking cleanup) because it potentially supports three
>>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>>> sync. Solaris cleanup would be a separate RFE.
>>>
>>> No doubt I've overlooked mentioning something that someone will 
>>> spot. :)
>>>
>>> Thanks,
>>> David
>>



From erik.joelsson at oracle.com  Thu May 18 10:33:13 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 18 May 2017 12:33:13 +0200
Subject: RFR: JDK-8180480 Use "requires transitive" relationship when
 determining modules for javadoc
In-Reply-To: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
References: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
Message-ID: <217f167e-7fe1-0c61-f669-1ce9499b87f0@oracle.com>

Looks good.

/Erik


On 2017-05-18 09:54, Magnus Ihse Bursie wrote:
> When the build system tries to figure out which modules that should be 
> included by the javadoc build, it locates the set of modules 
> "required" by already included modules, starting from an initial set 
> and repeating recursively (a method which we unfortunately called 
> "transitive").
>
> However, for javadoc, we should only look at those re-exported modules 
> that are classified by a "requires transitive" relationship (which I 
> therefore have called "re-exported" to not clash with the established 
> term "transitive").
>
> The effect of getting this wrong is e.g. that we copy module graph png 
> files that we should not, and that we look at too broad a set of files 
> for looking at changes that should trigger a re-build of the javadoc.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180480
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Thu May 18 12:18:36 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 18 May 2017 14:18:36 +0200
Subject: JDK-8180600: make run-test does not work with jib test dependencies
Message-ID: <a1ccb1d3-decc-49f5-d16e-e33d88168b2c@oracle.com>

The new run-test target does not work with the new jib test dependencies 
feature in jdk10-hs. The fix is small, just adding JIB_JAR to the 
command line for jtreg if present, as is done in make/TestCommon.gmk.

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

Patch:

diff -r 91ac8096f365 make/RunTests.gmk
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -358,6 +358,10 @@
      $1_JTREG_BASIC_OPTIONS += -nativepath:$$($1_JTREG_NATIVEPATH)
    endif

+  ifneq ($(JIB_JAR), )
+    $1_JTREG_BASIC_OPTIONS += -cpa:$(JIB_JAR)
+  endif
+
    run-test-$1:
      $$(call LogWarn)
      $$(call LogWarn, Running test '$$($1_TEST)')


/Erik



From christian.tornqvist at oracle.com  Thu May 18 12:21:16 2017
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 18 May 2017 08:21:16 -0400
Subject: JDK-8180600: make run-test does not work with jib test
 dependencies
In-Reply-To: <a1ccb1d3-decc-49f5-d16e-e33d88168b2c@oracle.com>
References: <a1ccb1d3-decc-49f5-d16e-e33d88168b2c@oracle.com>
Message-ID: <A8CC70F9-4286-4947-9A19-DF644B4DE025@oracle.com>

Hi Erik,

This looks good, thanks for fixing this.

Thanks,
Christian

> On May 18, 2017, at 8:18 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> The new run-test target does not work with the new jib test dependencies feature in jdk10-hs. The fix is small, just adding JIB_JAR to the command line for jtreg if present, as is done in make/TestCommon.gmk.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180600
> 
> Patch:
> 
> diff -r 91ac8096f365 make/RunTests.gmk
> --- a/make/RunTests.gmk
> +++ b/make/RunTests.gmk
> @@ -358,6 +358,10 @@
>     $1_JTREG_BASIC_OPTIONS += -nativepath:$$($1_JTREG_NATIVEPATH)
>   endif
> 
> +  ifneq ($(JIB_JAR), )
> +    $1_JTREG_BASIC_OPTIONS += -cpa:$(JIB_JAR)
> +  endif
> +
>   run-test-$1:
>     $$(call LogWarn)
>     $$(call LogWarn, Running test '$$($1_TEST)')
> 
> 
> /Erik
> 



From DakshinS at advisory.com  Thu May 18 12:21:08 2017
From: DakshinS at advisory.com (Dakshinamoorthi, Soundararajan)
Date: Thu, 18 May 2017 12:21:08 +0000
Subject: Building Java9 on Mac OSX 
Message-ID: <D188A45E-8B15-4AA2-B922-2D2B256AB4B5@advisory.com>

Hi,

I am trying to build java9 in mac OS X Sierra (10.12). As per the building.md, we need Xcode 6.3 to be installed to build JDK. But this version of the OS doesn?t seem to support it. So i installed the latest Xcode (8.3).  The error i get when running make is 

?Unable to find <JavaNativeFoundation/JavaNativeFoundation.h>

I tried tweaking the -iframework and -F options to the one that is realistically available in the machine . i.e /APplications/Xcode.app/?.., but still no good. 

Any help is much appreciated. 

BR,
Soundararajan

From erik.joelsson at oracle.com  Thu May 18 12:26:25 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 18 May 2017 14:26:25 +0200
Subject: JDK-8180600: make run-test does not work with jib test
 dependencies
In-Reply-To: <a1ccb1d3-decc-49f5-d16e-e33d88168b2c@oracle.com>
References: <a1ccb1d3-decc-49f5-d16e-e33d88168b2c@oracle.com>
Message-ID: <308f0356-b67d-bad7-3170-db2e93f77875@oracle.com>

Did a slight adjustment, adding double dollars when referencing JIB_JAR 
inside a macro body. This makes the code safer in certain cases.

diff -r 91ac8096f365 make/RunTests.gmk
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -358,6 +358,10 @@
      $1_JTREG_BASIC_OPTIONS += -nativepath:$$($1_JTREG_NATIVEPATH)
    endif

+  ifneq ($$(JIB_JAR), )
+    $1_JTREG_BASIC_OPTIONS += -cpa:$$(JIB_JAR)
+  endif
+
    run-test-$1:
      $$(call LogWarn)
      $$(call LogWarn, Running test '$$($1_TEST)')


/Erik


On 2017-05-18 14:18, Erik Joelsson wrote:
> The new run-test target does not work with the new jib test 
> dependencies feature in jdk10-hs. The fix is small, just adding 
> JIB_JAR to the command line for jtreg if present, as is done in 
> make/TestCommon.gmk.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180600
>
> Patch:
>
> diff -r 91ac8096f365 make/RunTests.gmk
> --- a/make/RunTests.gmk
> +++ b/make/RunTests.gmk
> @@ -358,6 +358,10 @@
>      $1_JTREG_BASIC_OPTIONS += -nativepath:$$($1_JTREG_NATIVEPATH)
>    endif
>
> +  ifneq ($(JIB_JAR), )
> +    $1_JTREG_BASIC_OPTIONS += -cpa:$(JIB_JAR)
> +  endif
> +
>    run-test-$1:
>      $$(call LogWarn)
>      $$(call LogWarn, Running test '$$($1_TEST)')
>
>
> /Erik
>



From magnus.ihse.bursie at oracle.com  Thu May 18 12:26:36 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 May 2017 14:26:36 +0200
Subject: JDK-8180600: make run-test does not work with jib test
 dependencies
In-Reply-To: <a1ccb1d3-decc-49f5-d16e-e33d88168b2c@oracle.com>
References: <a1ccb1d3-decc-49f5-d16e-e33d88168b2c@oracle.com>
Message-ID: <f804716a-dcae-aca5-49bb-b00a9688f309@oracle.com>

Looks good to me.

/Magnus

On 2017-05-18 14:18, Erik Joelsson wrote:
> The new run-test target does not work with the new jib test 
> dependencies feature in jdk10-hs. The fix is small, just adding 
> JIB_JAR to the command line for jtreg if present, as is done in 
> make/TestCommon.gmk.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180600
>
> Patch:
>
> diff -r 91ac8096f365 make/RunTests.gmk
> --- a/make/RunTests.gmk
> +++ b/make/RunTests.gmk
> @@ -358,6 +358,10 @@
>      $1_JTREG_BASIC_OPTIONS += -nativepath:$$($1_JTREG_NATIVEPATH)
>    endif
>
> +  ifneq ($(JIB_JAR), )
> +    $1_JTREG_BASIC_OPTIONS += -cpa:$(JIB_JAR)
> +  endif
> +
>    run-test-$1:
>      $$(call LogWarn)
>      $$(call LogWarn, Running test '$$($1_TEST)')
>
>
> /Erik
>



From erik.joelsson at oracle.com  Thu May 18 12:27:35 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 18 May 2017 14:27:35 +0200
Subject: Building Java9 on Mac OSX
In-Reply-To: <D188A45E-8B15-4AA2-B922-2D2B256AB4B5@advisory.com>
References: <D188A45E-8B15-4AA2-B922-2D2B256AB4B5@advisory.com>
Message-ID: <11a3cfb8-9c67-bd18-aecb-61d7b50a1712@oracle.com>

Hello,

I think you should still be able to install some 7.X version of Xcode 
and IIRC that should work better. I have not yet heard of a successful 
build on Xcode 8.

/Erik


On 2017-05-18 14:21, Dakshinamoorthi, Soundararajan wrote:
> Hi,
>
> I am trying to build java9 in mac OS X Sierra (10.12). As per the building.md, we need Xcode 6.3 to be installed to build JDK. But this version of the OS doesn?t seem to support it. So i installed the latest Xcode (8.3).  The error i get when running make is
>
> ?Unable to find <JavaNativeFoundation/JavaNativeFoundation.h>
>
> I tried tweaking the -iframework and -F options to the one that is realistically available in the machine . i.e /APplications/Xcode.app/?.., but still no good.
>
> Any help is much appreciated.
>
> BR,
> Soundararajan



From lenborje at gmail.com  Thu May 18 12:33:59 2017
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Thu, 18 May 2017 14:33:59 +0200
Subject: Building Java9 on Mac OSX
In-Reply-To: <D188A45E-8B15-4AA2-B922-2D2B256AB4B5@advisory.com>
References: <D188A45E-8B15-4AA2-B922-2D2B256AB4B5@advisory.com>
Message-ID: <6D4E7AA8-794F-4EA3-95F6-74A1480C89C7@gmail.com>

Have you installed the Command Line Tools for XCode? That package is essential.

If you haven?t installed it, you can get it by the command:

sudo xcode-select --install


> 18 maj 2017 kl. 14:21 skrev Dakshinamoorthi, Soundararajan <DakshinS at advisory.com>:
> 
> Hi,
> 
> I am trying to build java9 in mac OS X Sierra (10.12). As per the building.md, we need Xcode 6.3 to be installed to build JDK. But this version of the OS doesn?t seem to support it. So i installed the latest Xcode (8.3).  The error i get when running make is 
> 
> ?Unable to find <JavaNativeFoundation/JavaNativeFoundation.h>
> 
> I tried tweaking the -iframework and -F options to the one that is realistically available in the machine . i.e /APplications/Xcode.app/?.., but still no good. 
> 
> Any help is much appreciated. 
> 
> BR,
> Soundararajan



From lenborje at gmail.com  Thu May 18 12:40:06 2017
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Thu, 18 May 2017 14:40:06 +0200
Subject: Building Java9 on Mac OSX
In-Reply-To: <11a3cfb8-9c67-bd18-aecb-61d7b50a1712@oracle.com>
References: <D188A45E-8B15-4AA2-B922-2D2B256AB4B5@advisory.com>
 <11a3cfb8-9c67-bd18-aecb-61d7b50a1712@oracle.com>
Message-ID: <9F079DED-176E-4E6E-BFDC-B9EA5015F006@gmail.com>

I can build on MacOS Sierra (10.12.5), XCode 8.3.2.

I have to disable ?warnings as errors?, though.  (bash configure --disable-warnings-as-errors)

/Lennart

> 18 maj 2017 kl. 14:27 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Hello,
> 
> I think you should still be able to install some 7.X version of Xcode and IIRC that should work better. I have not yet heard of a successful build on Xcode 8.
> 
> /Erik
> 
> 
> On 2017-05-18 14:21, Dakshinamoorthi, Soundararajan wrote:
>> Hi,
>> 
>> I am trying to build java9 in mac OS X Sierra (10.12). As per the building.md, we need Xcode 6.3 to be installed to build JDK. But this version of the OS doesn?t seem to support it. So i installed the latest Xcode (8.3).  The error i get when running make is
>> 
>> ?Unable to find <JavaNativeFoundation/JavaNativeFoundation.h>
>> 
>> I tried tweaking the -iframework and -F options to the one that is realistically available in the machine . i.e /APplications/Xcode.app/?.., but still no good.
>> 
>> Any help is much appreciated.
>> 
>> BR,
>> Soundararajan
> 



From DakshinS at advisory.com  Thu May 18 14:04:05 2017
From: DakshinS at advisory.com (Dakshinamoorthi, Soundararajan)
Date: Thu, 18 May 2017 14:04:05 +0000
Subject: Building Java9 on Mac OSX 
In-Reply-To: <6D4E7AA8-794F-4EA3-95F6-74A1480C89C7@gmail.com>
References: <D188A45E-8B15-4AA2-B922-2D2B256AB4B5@advisory.com>
 <6D4E7AA8-794F-4EA3-95F6-74A1480C89C7@gmail.com>
Message-ID: <BB21C7FC-0B1F-4371-BB24-F89F421CA7F5@advisory.com>

Hi,

Thanks, this worked. The order of installation of Xcode IDE and the Command line tools , seem to make a difference. 

BR,
Soundararajan

> On 18-May-2017, at 18:03, Lennart B?rjeson <lenborje at gmail.com> wrote:
> 
> Have you installed the Command Line Tools for XCode? That package is essential.
> 
> If you haven?t installed it, you can get it by the command:
> 
> sudo xcode-select --install
> 
> 
>> 18 maj 2017 kl. 14:21 skrev Dakshinamoorthi, Soundararajan <DakshinS at advisory.com>:
>> 
>> Hi,
>> 
>> I am trying to build java9 in mac OS X Sierra (10.12). As per the building.md, we need Xcode 6.3 to be installed to build JDK. But this version of the OS doesn?t seem to support it. So i installed the latest Xcode (8.3).  The error i get when running make is 
>> 
>> ?Unable to find <JavaNativeFoundation/JavaNativeFoundation.h>
>> 
>> I tried tweaking the -iframework and -F options to the one that is realistically available in the machine . i.e /APplications/Xcode.app/?.., but still no good. 
>> 
>> Any help is much appreciated. 
>> 
>> BR,
>> Soundararajan
> 


From lenborje at gmail.com  Thu May 18 14:22:46 2017
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Thu, 18 May 2017 16:22:46 +0200
Subject: Building Java9 on Mac OSX
In-Reply-To: <BB21C7FC-0B1F-4371-BB24-F89F421CA7F5@advisory.com>
References: <D188A45E-8B15-4AA2-B922-2D2B256AB4B5@advisory.com>
 <6D4E7AA8-794F-4EA3-95F6-74A1480C89C7@gmail.com>
 <BB21C7FC-0B1F-4371-BB24-F89F421CA7F5@advisory.com>
Message-ID: <71696F26-7361-4300-894D-6B574DCA7448@gmail.com>

Well, sort of. The versions of MacOS, XCode, and Command Line Tools should match, in the sense that any certain version of MacOS requires a compatible version of XCode, which in its turn requires a compatible version of the Command Line Tools.

It is thus not possible to keep an older XCode when you upgrade MacOS.

In practise, I just enable automatic software updates and always run the latest versions. It's the way of Apple, even it sometimes breaks the build of other software. :-/

(If you have automatic updates enabled, your problems should have automatically gone away at the next update?)


Keep on coding,

/Lennart

> 18 maj 2017 kl. 16:04 skrev Dakshinamoorthi, Soundararajan <DakshinS at advisory.com>:
> 
> Hi,
> 
> Thanks, this worked. The order of installation of Xcode IDE and the Command line tools , seem to make a difference. 
> 
> BR,
> Soundararajan
> 
>> On 18-May-2017, at 18:03, Lennart B?rjeson <lenborje at gmail.com> wrote:
>> 
>> Have you installed the Command Line Tools for XCode? That package is essential.
>> 
>> If you haven?t installed it, you can get it by the command:
>> 
>> sudo xcode-select --install
>> 
>> 
>>> 18 maj 2017 kl. 14:21 skrev Dakshinamoorthi, Soundararajan <DakshinS at advisory.com>:
>>> 
>>> Hi,
>>> 
>>> I am trying to build java9 in mac OS X Sierra (10.12). As per the building.md, we need Xcode 6.3 to be installed to build JDK. But this version of the OS doesn?t seem to support it. So i installed the latest Xcode (8.3).  The error i get when running make is 
>>> 
>>> ?Unable to find <JavaNativeFoundation/JavaNativeFoundation.h>
>>> 
>>> I tried tweaking the -iframework and -F options to the one that is realistically available in the machine . i.e /APplications/Xcode.app/?.., but still no good. 
>>> 
>>> Any help is much appreciated. 
>>> 
>>> BR,
>>> Soundararajan
>> 
> 



From thomas.stuefe at gmail.com  Thu May 18 14:40:38 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 18 May 2017 16:40:38 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
Message-ID: <CAA-vtUwfXFTUwXGgU+Hd+GfXzxyyqk0-oDnFEqSL6sq_AOVvgg@mail.gmail.com>

Hi David, Magnus,

compiles and works fine on AIX, but as mentioned before off-list to David I
see this stdout:

configure: No CLOCK_GETTIME_IN_LIBRT
configure: No CLOCK_GETTIME_IN_LIBRT

Also, the -DSUPPORTS_CLOCK_MONOTONIC appears twice on the command line.
Full compile command looks like this:

/bin/xlC_r -q64 -qpic -D_REENTRANT -D__STDC_FORMAT_MACROS
-DSUPPORTS_CLOCK_MONOTONIC -DSUPPORTS_CLOCK_MONOTONIC -DAIX -qtune=balanced
-qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla -qlanglvl=noredefmac
-qnortti -qnoeh -qignerrno -qarch=ppc64 -DASSERT -DTARGET_ARCH_ppc
-DINCLUDE_SUFFIX_OS=_aix -DINCLUDE_SUFFIX_CPU=_ppc -DTARGET_COMPILER_xlc
-DPPC64 -DHOTSPOT_LIB_ARCH='"ppc64"' -DCOMPILER1 -DCOMPILER2
-DINCLUDE_JVMCI=0 -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm
-I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/aix/vm
-I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/posix/vm
-I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/cpu/ppc/vm
-I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/aix_ppc/vm
-I/priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/gensrc
-I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/precompiled
-I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/prims
-DDONT_USE_PRECOMPILED_HEADER -g -qsuppress=1540-0216 -qsuppress=1540-0198
-qsuppress=1540-1090 -qsuppress=1540-1639 -qsuppress=1540-1088
-qsuppress=1500-010 -O3 -qhot=level=1 -qinline -qinlglue
-DTHIS_FILE='"os_posix.cpp"' -c -qmakedep=gcc -MF
/priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/libjvm/objs/os_posix.d
-o /priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/libjvm/objs/os_posix.o
/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/posix/vm/os_posix.cpp

 -DSUPPORTS_CLOCK_MONOTONIC is the only switch appearing twice. I'm
baffled. Do you have any idea?

Regards, Thomas


On Thu, May 18, 2017 at 12:06 PM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

>
>
> On 2017-05-18 09:35, David Holmes wrote:
>
>> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>>
>>> On 2017-05-18 08:25, David Holmes wrote:
>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>>
>>>> webrevs:
>>>>
>>>> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>>>
>>>
>>> Build changes look  good.
>>>
>>
>> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging
>> prints outs - do you want me to remove them? I suppose they may be useful
>> if something goes wrong on some platform.
>>
>
> I didn't even notice them. :-/
>
> It's a bit unfortunate we don't have a debug level on the logging from
> configure. :-( Otherwise they would have clearly belonged there.
>
> The AC_MSG_NOTICE messages stands out much from the rest of the configure
> log, so maybe it's better that you remove them. The logic itself is very
> simple, if the -D flags are missing then we can surely tell what happened.
> So yes, please remove them.
>
> Alternatively, rewrite them as CHECKING/RESULT, if you want to keep the
> logging. That way they match better the rest of the configure log (and also
> describes what you're doing). Just check if AC_SEARCH_LIBS prints some
> output (likely so, I think), then you can't do it in the middle of a
> CHECKING/RESULT pair, but have to do the CHECKING part after AC_SEARCH_LIBS.
>
> /Magnus
>
>
>
>> David
>>
>> /Magnus
>>>
>>>       hotspot:
>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>>>
>>>> First a big thank you to Thomas Stuefe for testing various versions of
>>>> this on AIX.
>>>>
>>>> This is primarily a refactoring and cleanup exercise (ie lots of
>>>> deleted duplicated code!).
>>>>
>>>> I have taken the PlatformEvent, PlatformParker and Parker::* code, out
>>>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, AIX
>>>> and perhaps one day Solaris (more on that later).
>>>>
>>>> The Linux code was the most functionally complete, dealing with
>>>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>>>> default wall-clock for absolute timed waits. That functionality is
>>>> not, unfortunately, supported by all our POSIX platforms so there are
>>>> some configure time build checks to set some #defines, and then some
>>>> dynamic lookup at runtime**. We allow for the runtime environment to
>>>> be less capable than the build environment, but not the other way
>>>> around (without build time support we don't know the runtime types
>>>> needed to make library calls).
>>>>
>>>> ** There is some duplication of dynamic lookup code on Linux but this
>>>> can be cleaned up in future work if we refactor the time/clock code
>>>> into os_posix as well.
>>>>
>>>> The cleanup covers a number of things:
>>>> - removal of linux anachronisms that got "ported" into the other
>>>> platforms
>>>>   - eg EINTR can not be returned from the wait methods
>>>> - removal of solaris anachronisms that got ported into the linux code
>>>> and then on to other platforms
>>>>   - eg ETIMEDOUT is what we expect never ETIME
>>>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>>>> from the Parker methods
>>>> - consolidation of unpackTime and compute_abstime into one utility
>>>> function
>>>> - use statics for things completely private to the implementation
>>>> rather than making them part of the os* API (eg access to condAttr
>>>> objects)
>>>> - cleanup up commentary and style within methods of the same class
>>>> - clean up coding style in places eg not using Names that start with
>>>> capitals.
>>>>
>>>> I have not tried to cleanup every single oddity, nor tried to
>>>> reconcile differences between the very similar in places PlatformEvent
>>>> and Park methods. For example PlatformEvent still examines the
>>>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>>>
>>>> ** Perhaps a candidate for deprecation and future removal.
>>>>
>>>> There is one mini "enhancement" slipped in this. I now explicitly
>>>> initialize mutexes with a mutexAttr object with its type set to
>>>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>>>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>>>> "error checking" and so is slow. On all other current platforms there
>>>> is no effective change.
>>>>
>>>> Finally, Solaris is excluded from all this (other than the debug
>>>> signal blocking cleanup) because it potentially supports three
>>>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>>>> sync. Solaris cleanup would be a separate RFE.
>>>>
>>>> No doubt I've overlooked mentioning something that someone will spot. :)
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>
>>>
>


From magnus.ihse.bursie at oracle.com  Thu May 18 15:09:42 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 18 May 2017 17:09:42 +0200
Subject: JDK-8180600: make run-test does not work with jib test
 dependencies
In-Reply-To: <308f0356-b67d-bad7-3170-db2e93f77875@oracle.com>
References: <a1ccb1d3-decc-49f5-d16e-e33d88168b2c@oracle.com>
 <308f0356-b67d-bad7-3170-db2e93f77875@oracle.com>
Message-ID: <C7EB61C1-B8A0-4FE3-8EC5-B73D6B783F70@oracle.com>

Even better! :)

/Magnus

> 18 maj 2017 kl. 14:26 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Did a slight adjustment, adding double dollars when referencing JIB_JAR inside a macro body. This makes the code safer in certain cases.
> 
> diff -r 91ac8096f365 make/RunTests.gmk
> --- a/make/RunTests.gmk
> +++ b/make/RunTests.gmk
> @@ -358,6 +358,10 @@
>     $1_JTREG_BASIC_OPTIONS += -nativepath:$$($1_JTREG_NATIVEPATH)
>   endif
> 
> +  ifneq ($$(JIB_JAR), )
> +    $1_JTREG_BASIC_OPTIONS += -cpa:$$(JIB_JAR)
> +  endif
> +
>   run-test-$1:
>     $$(call LogWarn)
>     $$(call LogWarn, Running test '$$($1_TEST)')
> 
> 
> /Erik
> 
> 
>> On 2017-05-18 14:18, Erik Joelsson wrote:
>> The new run-test target does not work with the new jib test dependencies feature in jdk10-hs. The fix is small, just adding JIB_JAR to the command line for jtreg if present, as is done in make/TestCommon.gmk.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180600
>> 
>> Patch:
>> 
>> diff -r 91ac8096f365 make/RunTests.gmk
>> --- a/make/RunTests.gmk
>> +++ b/make/RunTests.gmk
>> @@ -358,6 +358,10 @@
>>     $1_JTREG_BASIC_OPTIONS += -nativepath:$$($1_JTREG_NATIVEPATH)
>>   endif
>> 
>> +  ifneq ($(JIB_JAR), )
>> +    $1_JTREG_BASIC_OPTIONS += -cpa:$(JIB_JAR)
>> +  endif
>> +
>>   run-test-$1:
>>     $$(call LogWarn)
>>     $$(call LogWarn, Running test '$$($1_TEST)')
>> 
>> 
>> /Erik
> 



From mandy.chung at oracle.com  Thu May 18 15:30:04 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 May 2017 08:30:04 -0700
Subject: RFR: JDK-8180480 Use "requires transitive" relationship when
 determining modules for javadoc
In-Reply-To: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
References: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
Message-ID: <BE441833-AF38-468A-BBEA-622E80C3A95C@oracle.com>


> On May 18, 2017, at 12:54 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> When the build system tries to figure out which modules that should be included by the javadoc build, it locates the set of modules "required" by already included modules, starting from an initial set and repeating recursively (a method which we unfortunately called "transitive?).

Which module has this name clash?

> However, for javadoc, we should only look at those re-exported modules that are classified by a "requires transitive" relationship (which I therefore have called "re-exported" to not clash with the established term "transitive?).

Javadoc uses the ?Indirect Exports? term for the exported API packages are from the ?requires transitive? modules.

I suggest to rename ?ReExported? to ?IndirectRequires? or ?Indirect?.

Mandy

> The effect of getting this wrong is e.g. that we copy module graph png files that we should not, and that we look at too broad a set of files for looking at changes that should trigger a re-build of the javadoc.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180480
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.01
> 
> /Magnus



From jonathan.gibbons at oracle.com  Thu May 18 15:55:56 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 18 May 2017 08:55:56 -0700
Subject: RFR: JDK-8180480 Use "requires transitive" relationship when
 determining modules for javadoc
In-Reply-To: <BE441833-AF38-468A-BBEA-622E80C3A95C@oracle.com>
References: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
 <BE441833-AF38-468A-BBEA-622E80C3A95C@oracle.com>
Message-ID: <c7776bd3-13df-0105-a38a-510717be9b5c@oracle.com>



On 5/18/17 8:30 AM, Mandy Chung wrote:
>> On May 18, 2017, at 12:54 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> When the build system tries to figure out which modules that should be included by the javadoc build, it locates the set of modules "required" by already included modules, starting from an initial set and repeating recursively (a method which we unfortunately called "transitive?).
> Which module has this name clash?
>
>> However, for javadoc, we should only look at those re-exported modules that are classified by a "requires transitive" relationship (which I therefore have called "re-exported" to not clash with the established term "transitive?).
> Javadoc uses the ?Indirect Exports? term for the exported API packages are from the ?requires transitive? modules.
>
> I suggest to rename ?ReExported? to ?IndirectRequires? or ?Indirect?.
>
> Mandy
Agreed, re-exports is not the correct terminology here.
>
>> The effect of getting this wrong is e.g. that we copy module graph png files that we should not, and that we look at too broad a set of files for looking at changes that should trigger a re-build of the javadoc.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180480
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.01
>>
>> /Magnus



From bradford.wetmore at oracle.com  Thu May 18 17:10:33 2017
From: bradford.wetmore at oracle.com (Brad R. Wetmore)
Date: Thu, 18 May 2017 10:10:33 -0700
Subject: CR: 8180540: Add pandoc build fix for windows
In-Reply-To: <03c14885-d07b-96bb-957a-0927b9f6f5b5@oracle.com>
References: <77fc2698-3f2b-7461-4960-2954fac1e0f6@oracle.com>
 <03c14885-d07b-96bb-957a-0927b9f6f5b5@oracle.com>
Message-ID: <51f2d707-a5a0-9b4b-6cb0-fd2ef5a26442@oracle.com>



On 5/18/2017 12:27 AM, Magnus Ihse Bursie wrote:
> Looks good. Formally, I believe someone else needs to review it.

Hm...I would have expected your "Contributed-by" and my review would be 
sufficient (what we do for sponsoring an "author" change), but looks 
like Erik did review also so we should be fine.

Erik wrote:

 > As long as pandoc for windows is always a windows native thing and
 > not provided by cygwin this seems good. A quick googling indicates
 > that cygwin currently does not provide pandoc so should be fine then.

You are correct in that pandoc is not provded by cygwin, I had to 
download/install cygdrive separately (grrr...), then set the PANDOC 
configure option:

      bash configure \
         PANDOC=c:/Users/mydir/bin/pandoc.exe \

That said, I'm not quite following your point about cygwin's 
noninclusion of pandoc here.

The underlying issue is that the arguments being passed to pandoc aren't 
being processed correctly.

     ...deleted...
     --toc 
'/cygdrive/d/java/ws/dev/jdk/src/closed/java.base/share/specs/security/standard-names.md'
     -o 
'/cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/support/javadoc/specs/security/standard-names.html' 


pandoc.exe: 
/cygdrive/d/java/ws/dev/jdk/src/closed/java.base/share/specs/security/standard-names.md: 
openFile: does not exist (No such file or directory)

Changing to the following worked:

     --toc 
'd:/java/ws/dev/jdk/src/closed/java.base/share/specs/security/standard-names.md'
     -o 
'd:/java/ws/dev/build/windows-x86_64-normal-server-release/support/javadoc/specs/security/standard-names.html' 


which is what FIXPATH does, IIUC.

Thanks for the review.

Brad


> /Magnus
>
> On 2017-05-18 02:07, Brad R. Wetmore wrote:
>> Magnus,
>>
>> I've added your suggested fix to spec.gmk.in, which is the minor tweak
>> to add @FIXPATH@ to allow pandoc to run on windows builds.
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8180540
>>     http://cr.openjdk.java.net/~wetmore/8180540/webrev.00/
>>
>> I put you down as Contributed-by: with myself as reviewer, but thought
>> you (and others?) might want to at least check it.
>>
>> Thanks,
>>
>> Brad
>


From bradford.wetmore at oracle.com  Thu May 18 17:14:43 2017
From: bradford.wetmore at oracle.com (Brad R. Wetmore)
Date: Thu, 18 May 2017 10:14:43 -0700
Subject: CR: 8180540: Add pandoc build fix for windows
In-Reply-To: <51f2d707-a5a0-9b4b-6cb0-fd2ef5a26442@oracle.com>
References: <77fc2698-3f2b-7461-4960-2954fac1e0f6@oracle.com>
 <03c14885-d07b-96bb-957a-0927b9f6f5b5@oracle.com>
 <51f2d707-a5a0-9b4b-6cb0-fd2ef5a26442@oracle.com>
Message-ID: <19d19539-324f-25ac-f346-06defabb2888@oracle.com>



On 5/18/2017 10:10 AM, Brad R. Wetmore wrote:

>> As long as pandoc for windows is always a windows native thing and
>> not provided by cygwin this seems good. A quick googling indicates
>> that cygwin currently does not provide pandoc so should be fine then.
>
> You are correct in that pandoc is not provded by cygwin, I had to
> download/install cygdrive

s/cygdrive/pandoc/

> separately (grrr...)

+1 more grrr for stupid PEBKAC/PEBCAK errors...  ;)

Brad




From thomas.stuefe at gmail.com  Thu May 18 18:39:47 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 18 May 2017 20:39:47 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <CAA-vtUwfXFTUwXGgU+Hd+GfXzxyyqk0-oDnFEqSL6sq_AOVvgg@mail.gmail.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
 <CAA-vtUwfXFTUwXGgU+Hd+GfXzxyyqk0-oDnFEqSL6sq_AOVvgg@mail.gmail.com>
Message-ID: <CAA-vtUysSsaNfxsdpXk3-tb7=9xH-KvZoksm0pizjpnaULLrog@mail.gmail.com>

Okay, I regenerated the generated-configure.sh and the double definitions
for -DSUPPORTS_CLOCK_MONOTONIC disappeared. So the generated-configure.sh
you posted was just outdated.

However, the debug output still appears twice: configure: No
CLOCK_GETTIME_IN_LIBRT

AC_MSG_NOTICE([No CLOCK_GETTIME_IN_LIBRT]) expands to two invocations of
ac_echo(..). I am out of my depth here, not sure what the background is.
But as you want to remove the debug output anyway, I think this is not an
issue.

I will take more time for a full review later. Just adding that I really
like this fix, it takes a lot of coding off our (platform specific) backs,
which is a good thing!

Kind Regards, Thomas

On Thu, May 18, 2017 at 4:40 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi David, Magnus,
>
> compiles and works fine on AIX, but as mentioned before off-list to David
> I see this stdout:
>
> configure: No CLOCK_GETTIME_IN_LIBRT
> configure: No CLOCK_GETTIME_IN_LIBRT
>
> Also, the -DSUPPORTS_CLOCK_MONOTONIC appears twice on the command line.
> Full compile command looks like this:
>
> /bin/xlC_r -q64 -qpic -D_REENTRANT -D__STDC_FORMAT_MACROS
> -DSUPPORTS_CLOCK_MONOTONIC -DSUPPORTS_CLOCK_MONOTONIC -DAIX -qtune=balanced
> -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla -qlanglvl=noredefmac
> -qnortti -qnoeh -qignerrno -qarch=ppc64 -DASSERT -DTARGET_ARCH_ppc
> -DINCLUDE_SUFFIX_OS=_aix -DINCLUDE_SUFFIX_CPU=_ppc -DTARGET_COMPILER_xlc
> -DPPC64 -DHOTSPOT_LIB_ARCH='"ppc64"' -DCOMPILER1 -DCOMPILER2
> -DINCLUDE_JVMCI=0 -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm
> -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/aix/vm
> -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/posix/vm
> -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/cpu/ppc/vm
> -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/aix_ppc/vm
> -I/priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/gensrc
> -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/precompiled
> -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/prims
> -DDONT_USE_PRECOMPILED_HEADER -g -qsuppress=1540-0216 -qsuppress=1540-0198
> -qsuppress=1540-1090 -qsuppress=1540-1639 -qsuppress=1540-1088
> -qsuppress=1500-010 -O3 -qhot=level=1 -qinline -qinlglue
> -DTHIS_FILE='"os_posix.cpp"' -c -qmakedep=gcc -MF
> /priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/libjvm/objs/os_posix.d
> -o /priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/libjvm/objs/os_posix.o
> /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/posix/vm/os_posix.cpp
>
>  -DSUPPORTS_CLOCK_MONOTONIC is the only switch appearing twice. I'm
> baffled. Do you have any idea?
>
> Regards, Thomas
>
>
> On Thu, May 18, 2017 at 12:06 PM, Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
>>
>>
>> On 2017-05-18 09:35, David Holmes wrote:
>>
>>> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>>>
>>>> On 2017-05-18 08:25, David Holmes wrote:
>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>>>
>>>>> webrevs:
>>>>>
>>>>> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>>>>
>>>>
>>>> Build changes look  good.
>>>>
>>>
>>> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging
>>> prints outs - do you want me to remove them? I suppose they may be useful
>>> if something goes wrong on some platform.
>>>
>>
>> I didn't even notice them. :-/
>>
>> It's a bit unfortunate we don't have a debug level on the logging from
>> configure. :-( Otherwise they would have clearly belonged there.
>>
>> The AC_MSG_NOTICE messages stands out much from the rest of the configure
>> log, so maybe it's better that you remove them. The logic itself is very
>> simple, if the -D flags are missing then we can surely tell what happened.
>> So yes, please remove them.
>>
>> Alternatively, rewrite them as CHECKING/RESULT, if you want to keep the
>> logging. That way they match better the rest of the configure log (and also
>> describes what you're doing). Just check if AC_SEARCH_LIBS prints some
>> output (likely so, I think), then you can't do it in the middle of a
>> CHECKING/RESULT pair, but have to do the CHECKING part after AC_SEARCH_LIBS.
>>
>> /Magnus
>>
>>
>>
>>> David
>>>
>>> /Magnus
>>>>
>>>>       hotspot:
>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>>>>
>>>>> First a big thank you to Thomas Stuefe for testing various versions of
>>>>> this on AIX.
>>>>>
>>>>> This is primarily a refactoring and cleanup exercise (ie lots of
>>>>> deleted duplicated code!).
>>>>>
>>>>> I have taken the PlatformEvent, PlatformParker and Parker::* code, out
>>>>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, AIX
>>>>> and perhaps one day Solaris (more on that later).
>>>>>
>>>>> The Linux code was the most functionally complete, dealing with
>>>>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>>>>> default wall-clock for absolute timed waits. That functionality is
>>>>> not, unfortunately, supported by all our POSIX platforms so there are
>>>>> some configure time build checks to set some #defines, and then some
>>>>> dynamic lookup at runtime**. We allow for the runtime environment to
>>>>> be less capable than the build environment, but not the other way
>>>>> around (without build time support we don't know the runtime types
>>>>> needed to make library calls).
>>>>>
>>>>> ** There is some duplication of dynamic lookup code on Linux but this
>>>>> can be cleaned up in future work if we refactor the time/clock code
>>>>> into os_posix as well.
>>>>>
>>>>> The cleanup covers a number of things:
>>>>> - removal of linux anachronisms that got "ported" into the other
>>>>> platforms
>>>>>   - eg EINTR can not be returned from the wait methods
>>>>> - removal of solaris anachronisms that got ported into the linux code
>>>>> and then on to other platforms
>>>>>   - eg ETIMEDOUT is what we expect never ETIME
>>>>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>>>>> from the Parker methods
>>>>> - consolidation of unpackTime and compute_abstime into one utility
>>>>> function
>>>>> - use statics for things completely private to the implementation
>>>>> rather than making them part of the os* API (eg access to condAttr
>>>>> objects)
>>>>> - cleanup up commentary and style within methods of the same class
>>>>> - clean up coding style in places eg not using Names that start with
>>>>> capitals.
>>>>>
>>>>> I have not tried to cleanup every single oddity, nor tried to
>>>>> reconcile differences between the very similar in places PlatformEvent
>>>>> and Park methods. For example PlatformEvent still examines the
>>>>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>>>>
>>>>> ** Perhaps a candidate for deprecation and future removal.
>>>>>
>>>>> There is one mini "enhancement" slipped in this. I now explicitly
>>>>> initialize mutexes with a mutexAttr object with its type set to
>>>>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>>>>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>>>>> "error checking" and so is slow. On all other current platforms there
>>>>> is no effective change.
>>>>>
>>>>> Finally, Solaris is excluded from all this (other than the debug
>>>>> signal blocking cleanup) because it potentially supports three
>>>>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>>>>> sync. Solaris cleanup would be a separate RFE.
>>>>>
>>>>> No doubt I've overlooked mentioning something that someone will spot.
>>>>> :)
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>
>>>>
>>
>


From david.holmes at oracle.com  Thu May 18 21:39:29 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 May 2017 07:39:29 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <CAA-vtUysSsaNfxsdpXk3-tb7=9xH-KvZoksm0pizjpnaULLrog@mail.gmail.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
 <CAA-vtUwfXFTUwXGgU+Hd+GfXzxyyqk0-oDnFEqSL6sq_AOVvgg@mail.gmail.com>
 <CAA-vtUysSsaNfxsdpXk3-tb7=9xH-KvZoksm0pizjpnaULLrog@mail.gmail.com>
Message-ID: <b52080ec-5098-6b41-3630-916a69c55477@oracle.com>

Hi Thomas,

On 19/05/2017 4:39 AM, Thomas St?fe wrote:
> Okay, I regenerated the generated-configure.sh and the double
> definitions for -DSUPPORTS_CLOCK_MONOTONIC disappeared. So the
> generated-configure.sh you posted was just outdated.

Not sure how but as long as it is fixed. :)

> However, the debug output still appears twice: configure: No
> CLOCK_GETTIME_IN_LIBRT

Yes that's a side-effect of the flag helper routine being called twice: 
once for build platform and once for target.

> AC_MSG_NOTICE([No CLOCK_GETTIME_IN_LIBRT]) expands to two invocations of
> ac_echo(..). I am out of my depth here, not sure what the background is.
> But as you want to remove the debug output anyway, I think this is not
> an issue.

Right the messages will be gone.

> I will take more time for a full review later. Just adding that I really
> like this fix, it takes a lot of coding off our (platform specific)
> backs, which is a good thing!

Thanks for looking at this in so much detail already.

Cheers,
David

> Kind Regards, Thomas
>
> On Thu, May 18, 2017 at 4:40 PM, Thomas St?fe <thomas.stuefe at gmail.com
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi David, Magnus,
>
>     compiles and works fine on AIX, but as mentioned before off-list to
>     David I see this stdout:
>
>     configure: No CLOCK_GETTIME_IN_LIBRT
>     configure: No CLOCK_GETTIME_IN_LIBRT
>
>     Also, the -DSUPPORTS_CLOCK_MONOTONIC appears twice on the command
>     line. Full compile command looks like this:
>
>     /bin/xlC_r -q64 -qpic -D_REENTRANT -D__STDC_FORMAT_MACROS
>     -DSUPPORTS_CLOCK_MONOTONIC -DSUPPORTS_CLOCK_MONOTONIC -DAIX
>     -qtune=balanced -qalias=noansi -qstrict -qtls=default
>     -qlanglvl=c99vla -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno
>     -qarch=ppc64 -DASSERT -DTARGET_ARCH_ppc -DINCLUDE_SUFFIX_OS=_aix
>     -DINCLUDE_SUFFIX_CPU=_ppc -DTARGET_COMPILER_xlc -DPPC64
>     -DHOTSPOT_LIB_ARCH='"ppc64"' -DCOMPILER1 -DCOMPILER2
>     -DINCLUDE_JVMCI=0
>     -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm
>     -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/aix/vm
>     -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/posix/vm
>     -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/cpu/ppc/vm
>     -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/aix_ppc/vm -I/priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/gensrc
>     -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/precompiled
>     -I/priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/prims
>     -DDONT_USE_PRECOMPILED_HEADER -g -qsuppress=1540-0216
>     -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1540-1639
>     -qsuppress=1540-1088 -qsuppress=1500-010 -O3 -qhot=level=1 -qinline
>     -qinlglue -DTHIS_FILE='"os_posix.cpp"' -c -qmakedep=gcc -MF
>     /priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/libjvm/objs/os_posix.d
>     -o
>     /priv/d031900/openjdk/jdk10-hs/output/hotspot/variant-server/libjvm/objs/os_posix.o
>     /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os/posix/vm/os_posix.cpp
>
>      -DSUPPORTS_CLOCK_MONOTONIC is the only switch appearing twice. I'm
>     baffled. Do you have any idea?
>
>     Regards, Thomas
>
>
>     On Thu, May 18, 2017 at 12:06 PM, Magnus Ihse Bursie
>     <magnus.ihse.bursie at oracle.com
>     <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>
>
>
>         On 2017-05-18 09:35, David Holmes wrote:
>
>             On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>
>                 On 2017-05-18 08:25, David Holmes wrote:
>
>                     Bug:
>                     https://bugs.openjdk.java.net/browse/JDK-8174231
>                     <https://bugs.openjdk.java.net/browse/JDK-8174231>
>
>                     webrevs:
>
>                     Build-related:
>                     http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>                     <http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/>
>
>
>                 Build changes look  good.
>
>
>             Thanks Magnus! I just realized I left in the AC_MSG_NOTICE
>             debugging prints outs - do you want me to remove them? I
>             suppose they may be useful if something goes wrong on some
>             platform.
>
>
>         I didn't even notice them. :-/
>
>         It's a bit unfortunate we don't have a debug level on the
>         logging from configure. :-( Otherwise they would have clearly
>         belonged there.
>
>         The AC_MSG_NOTICE messages stands out much from the rest of the
>         configure log, so maybe it's better that you remove them. The
>         logic itself is very simple, if the -D flags are missing then we
>         can surely tell what happened. So yes, please remove them.
>
>         Alternatively, rewrite them as CHECKING/RESULT, if you want to
>         keep the logging. That way they match better the rest of the
>         configure log (and also describes what you're doing). Just check
>         if AC_SEARCH_LIBS prints some output (likely so, I think), then
>         you can't do it in the middle of a CHECKING/RESULT pair, but
>         have to do the CHECKING part after AC_SEARCH_LIBS.
>
>         /Magnus
>
>
>
>             David
>
>                 /Magnus
>
>                           hotspot:
>                     http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>                     <http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/>
>
>                     First a big thank you to Thomas Stuefe for testing
>                     various versions of
>                     this on AIX.
>
>                     This is primarily a refactoring and cleanup exercise
>                     (ie lots of
>                     deleted duplicated code!).
>
>                     I have taken the PlatformEvent, PlatformParker and
>                     Parker::* code, out
>                     of os_linux and moved it into os_posix for use by
>                     Linux, OSX, BSD, AIX
>                     and perhaps one day Solaris (more on that later).
>
>                     The Linux code was the most functionally complete,
>                     dealing with
>                     correct use of CLOCK_MONOTONIC for relative timed
>                     waits, and the
>                     default wall-clock for absolute timed waits. That
>                     functionality is
>                     not, unfortunately, supported by all our POSIX
>                     platforms so there are
>                     some configure time build checks to set some
>                     #defines, and then some
>                     dynamic lookup at runtime**. We allow for the
>                     runtime environment to
>                     be less capable than the build environment, but not
>                     the other way
>                     around (without build time support we don't know the
>                     runtime types
>                     needed to make library calls).
>
>                     ** There is some duplication of dynamic lookup code
>                     on Linux but this
>                     can be cleaned up in future work if we refactor the
>                     time/clock code
>                     into os_posix as well.
>
>                     The cleanup covers a number of things:
>                     - removal of linux anachronisms that got "ported"
>                     into the other
>                     platforms
>                       - eg EINTR can not be returned from the wait methods
>                     - removal of solaris anachronisms that got ported
>                     into the linux code
>                     and then on to other platforms
>                       - eg ETIMEDOUT is what we expect never ETIME
>                     - removal of the ancient/obsolete
>                     os::*::allowdebug_blocked_signals()
>                     from the Parker methods
>                     - consolidation of unpackTime and compute_abstime
>                     into one utility
>                     function
>                     - use statics for things completely private to the
>                     implementation
>                     rather than making them part of the os* API (eg
>                     access to condAttr
>                     objects)
>                     - cleanup up commentary and style within methods of
>                     the same class
>                     - clean up coding style in places eg not using Names
>                     that start with
>                     capitals.
>
>                     I have not tried to cleanup every single oddity, nor
>                     tried to
>                     reconcile differences between the very similar in
>                     places PlatformEvent
>                     and Park methods. For example PlatformEvent still
>                     examines the
>                     FilterSpuriousWakeups** flag, and Parker still
>                     ignores it.
>
>                     ** Perhaps a candidate for deprecation and future
>                     removal.
>
>                     There is one mini "enhancement" slipped in this. I
>                     now explicitly
>                     initialize mutexes with a mutexAttr object with its
>                     type set to
>                     PTHREAD_MUTEX_NORMAL, instead of relying on the
>                     definition of
>                     PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is
>                     not "normal" but
>                     "error checking" and so is slow. On all other
>                     current platforms there
>                     is no effective change.
>
>                     Finally, Solaris is excluded from all this (other
>                     than the debug
>                     signal blocking cleanup) because it potentially
>                     supports three
>                     different low-level sync subsystems: UI thr*,
>                     Pthread, and direct LWP
>                     sync. Solaris cleanup would be a separate RFE.
>
>                     No doubt I've overlooked mentioning something that
>                     someone will spot. :)
>
>                     Thanks,
>                     David
>
>
>
>
>


From doko at ubuntu.com  Thu May 18 23:12:16 2017
From: doko at ubuntu.com (Matthias Klose)
Date: Thu, 18 May 2017 16:12:16 -0700
Subject: 9-b170 breaks the jtreg detection on FHS based systems
Message-ID: <9ce161dc-b569-4447-47e9-abe03c0bd9ef@ubuntu.com>

Hi, I don't know why the jtreg check was tightened or changes, however it breaks
the build on FHS based systems, like on most Linux distros.

  /usr/bin/jtreg
  /usr/share/java/jtreg.jar

What is this supposed to check? Currenlty it expects a JT_HOME, but apparently
only uses the locaton of the jar file.

Matthias


From jonathan.gibbons at oracle.com  Thu May 18 23:19:57 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 18 May 2017 16:19:57 -0700
Subject: 9-b170 breaks the jtreg detection on FHS based systems
In-Reply-To: <9ce161dc-b569-4447-47e9-abe03c0bd9ef@ubuntu.com>
References: <9ce161dc-b569-4447-47e9-abe03c0bd9ef@ubuntu.com>
Message-ID: <591E2C1D.8080100@oracle.com>



On 05/18/2017 04:12 PM, Matthias Klose wrote:
> Hi, I don't know why the jtreg check was tightened or changes, however it breaks
> the build on FHS based systems, like on most Linux distros.
>
>    /usr/bin/jtreg
>    /usr/share/java/jtreg.jar
>
> What is this supposed to check? Currenlty it expects a JT_HOME, but apparently
> only uses the locaton of the jar file.
>
> Matthias

Without commenting on the build changes, I note that jtreg normally 
expects to live in
the following sort of hierarchy, unless you are prepared to use options 
to specify the
locations of other jar files.

bin/jtreg
lib/asmtools.jar
lib/testng.jar
lib/jcov_network_saver.jar
lib/jh.jar
lib/junit.jar
lib/jcov.jar
lib/jtreg.jar
lib/javatest.jar

-- Jon


From david.holmes at oracle.com  Fri May 19 07:15:46 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 May 2017 17:15:46 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
Message-ID: <1ef68ed4-91ca-b52d-2a75-1d66226ad21b@oracle.com>

Hi Magnus,

On 18/05/2017 8:06 PM, Magnus Ihse Bursie wrote:
> 
> 
> On 2017-05-18 09:35, David Holmes wrote:
>> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>>> On 2017-05-18 08:25, David Holmes wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>>
>>>> webrevs:
>>>>
>>>> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>>
>>> Build changes look  good.
>>
>> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging 
>> prints outs - do you want me to remove them? I suppose they may be 
>> useful if something goes wrong on some platform.
> 
> I didn't even notice them. :-/
> 
> It's a bit unfortunate we don't have a debug level on the logging from 
> configure. :-( Otherwise they would have clearly belonged there.
> 
> The AC_MSG_NOTICE messages stands out much from the rest of the 
> configure log, so maybe it's better that you remove them. The logic 
> itself is very simple, if the -D flags are missing then we can surely 
> tell what happened. So yes, please remove them.

Webrev updated in place.

I have removed them to avoid noise - particularly as they get executed 
twice.

I also made an adjustment to AC_SEARCH_LIBS as I don't want to pass the 
saved_LIBS value in explicitly, but want it to use the LIBS value - 
which is no longer cleared before the call. I've verified all platforms 
are okay - except AIX which I'll need Thomas to recheck when he can.

I also discovered an oddity in that our ARM64 builds seem to use 
different system libraries in that librt.so is not needed for 
clock_gettime. This still seems to work ok. Of more of a concern if we 
were expand this kind of function-existence check is that libc seems to 
contain "dummy" (or at least dysfunctional) versions of a number of the 
core pthread APIs!

Thanks,
David

> Alternatively, rewrite them as CHECKING/RESULT, if you want to keep the 
> logging. That way they match better the rest of the configure log (and 
> also describes what you're doing). Just check if AC_SEARCH_LIBS prints 
> some output (likely so, I think), then you can't do it in the middle of 
> a CHECKING/RESULT pair, but have to do the CHECKING part after 
> AC_SEARCH_LIBS.
> 
> /Magnus
> 
>>
>> David
>>
>>> /Magnus
>>>
>>>>       hotspot:
>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>>>
>>>> First a big thank you to Thomas Stuefe for testing various versions of
>>>> this on AIX.
>>>>
>>>> This is primarily a refactoring and cleanup exercise (ie lots of
>>>> deleted duplicated code!).
>>>>
>>>> I have taken the PlatformEvent, PlatformParker and Parker::* code, out
>>>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, AIX
>>>> and perhaps one day Solaris (more on that later).
>>>>
>>>> The Linux code was the most functionally complete, dealing with
>>>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>>>> default wall-clock for absolute timed waits. That functionality is
>>>> not, unfortunately, supported by all our POSIX platforms so there are
>>>> some configure time build checks to set some #defines, and then some
>>>> dynamic lookup at runtime**. We allow for the runtime environment to
>>>> be less capable than the build environment, but not the other way
>>>> around (without build time support we don't know the runtime types
>>>> needed to make library calls).
>>>>
>>>> ** There is some duplication of dynamic lookup code on Linux but this
>>>> can be cleaned up in future work if we refactor the time/clock code
>>>> into os_posix as well.
>>>>
>>>> The cleanup covers a number of things:
>>>> - removal of linux anachronisms that got "ported" into the other
>>>> platforms
>>>>   - eg EINTR can not be returned from the wait methods
>>>> - removal of solaris anachronisms that got ported into the linux code
>>>> and then on to other platforms
>>>>   - eg ETIMEDOUT is what we expect never ETIME
>>>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>>>> from the Parker methods
>>>> - consolidation of unpackTime and compute_abstime into one utility
>>>> function
>>>> - use statics for things completely private to the implementation
>>>> rather than making them part of the os* API (eg access to condAttr
>>>> objects)
>>>> - cleanup up commentary and style within methods of the same class
>>>> - clean up coding style in places eg not using Names that start with
>>>> capitals.
>>>>
>>>> I have not tried to cleanup every single oddity, nor tried to
>>>> reconcile differences between the very similar in places PlatformEvent
>>>> and Park methods. For example PlatformEvent still examines the
>>>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>>>
>>>> ** Perhaps a candidate for deprecation and future removal.
>>>>
>>>> There is one mini "enhancement" slipped in this. I now explicitly
>>>> initialize mutexes with a mutexAttr object with its type set to
>>>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>>>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>>>> "error checking" and so is slow. On all other current platforms there
>>>> is no effective change.
>>>>
>>>> Finally, Solaris is excluded from all this (other than the debug
>>>> signal blocking cleanup) because it potentially supports three
>>>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>>>> sync. Solaris cleanup would be a separate RFE.
>>>>
>>>> No doubt I've overlooked mentioning something that someone will 
>>>> spot. :)
>>>>
>>>> Thanks,
>>>> David
>>>
> 


From erik.joelsson at oracle.com  Fri May 19 08:01:32 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 19 May 2017 10:01:32 +0200
Subject: CR: 8180540: Add pandoc build fix for windows
In-Reply-To: <51f2d707-a5a0-9b4b-6cb0-fd2ef5a26442@oracle.com>
References: <77fc2698-3f2b-7461-4960-2954fac1e0f6@oracle.com>
 <03c14885-d07b-96bb-957a-0927b9f6f5b5@oracle.com>
 <51f2d707-a5a0-9b4b-6cb0-fd2ef5a26442@oracle.com>
Message-ID: <94ef1e6a-af36-5b00-dde7-64f7b6035cdf@oracle.com>

Hello,


On 2017-05-18 19:10, Brad R. Wetmore wrote:
>
>
> On 5/18/2017 12:27 AM, Magnus Ihse Bursie wrote:
>> Looks good. Formally, I believe someone else needs to review it.
>
> Hm...I would have expected your "Contributed-by" and my review would 
> be sufficient (what we do for sponsoring an "author" change), but 
> looks like Erik did review also so we should be fine.
>
> Erik wrote:
>
> > As long as pandoc for windows is always a windows native thing and
> > not provided by cygwin this seems good. A quick googling indicates
> > that cygwin currently does not provide pandoc so should be fine then.
>
> You are correct in that pandoc is not provded by cygwin, I had to 
> download/install cygdrive separately (grrr...), then set the PANDOC 
> configure option:
>
>      bash configure \
>         PANDOC=c:/Users/mydir/bin/pandoc.exe \
>
> That said, I'm not quite following your point about cygwin's 
> noninclusion of pandoc here.
>
> The underlying issue is that the arguments being passed to pandoc 
> aren't being processed correctly.
>
>     ...deleted...
>     --toc 
> '/cygdrive/d/java/ws/dev/jdk/src/closed/java.base/share/specs/security/standard-names.md'
>     -o 
> '/cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/support/javadoc/specs/security/standard-names.html' 
>
>
> pandoc.exe: 
> /cygdrive/d/java/ws/dev/jdk/src/closed/java.base/share/specs/security/standard-names.md: 
> openFile: does not exist (No such file or directory)
>
> Changing to the following worked:
>
>     --toc 
> 'd:/java/ws/dev/jdk/src/closed/java.base/share/specs/security/standard-names.md'
>     -o 
> 'd:/java/ws/dev/build/windows-x86_64-normal-server-release/support/javadoc/specs/security/standard-names.html' 
>
>
> which is what FIXPATH does, IIUC.
>
That is indeed what fixpath does, but if pandoc was a cygwin native app, 
it would accept /cygdrive/x paths. It would probably work fine with x:/ 
paths as well, but in some cases those windows paths do weird things.

/Erik
> Thanks for the review.
>
> Brad
>
>
>> /Magnus
>>
>> On 2017-05-18 02:07, Brad R. Wetmore wrote:
>>> Magnus,
>>>
>>> I've added your suggested fix to spec.gmk.in, which is the minor tweak
>>> to add @FIXPATH@ to allow pandoc to run on windows builds.
>>>
>>>     https://bugs.openjdk.java.net/browse/JDK-8180540
>>>     http://cr.openjdk.java.net/~wetmore/8180540/webrev.00/
>>>
>>> I put you down as Contributed-by: with myself as reviewer, but thought
>>> you (and others?) might want to at least check it.
>>>
>>> Thanks,
>>>
>>> Brad
>>



From erik.joelsson at oracle.com  Fri May 19 08:07:35 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 19 May 2017 10:07:35 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <1ef68ed4-91ca-b52d-2a75-1d66226ad21b@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
 <1ef68ed4-91ca-b52d-2a75-1d66226ad21b@oracle.com>
Message-ID: <48795ff4-1b3e-0919-d008-93c3e0def878@oracle.com>

Build changes look good to me.

/Erik


On 2017-05-19 09:15, David Holmes wrote:
> Hi Magnus,
>
> On 18/05/2017 8:06 PM, Magnus Ihse Bursie wrote:
>>
>>
>> On 2017-05-18 09:35, David Holmes wrote:
>>> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>>>> On 2017-05-18 08:25, David Holmes wrote:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>>>
>>>>> webrevs:
>>>>>
>>>>> Build-related: 
>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>>>
>>>> Build changes look  good.
>>>
>>> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging 
>>> prints outs - do you want me to remove them? I suppose they may be 
>>> useful if something goes wrong on some platform.
>>
>> I didn't even notice them. :-/
>>
>> It's a bit unfortunate we don't have a debug level on the logging 
>> from configure. :-( Otherwise they would have clearly belonged there.
>>
>> The AC_MSG_NOTICE messages stands out much from the rest of the 
>> configure log, so maybe it's better that you remove them. The logic 
>> itself is very simple, if the -D flags are missing then we can surely 
>> tell what happened. So yes, please remove them.
>
> Webrev updated in place.
>
> I have removed them to avoid noise - particularly as they get executed 
> twice.
>
> I also made an adjustment to AC_SEARCH_LIBS as I don't want to pass 
> the saved_LIBS value in explicitly, but want it to use the LIBS value 
> - which is no longer cleared before the call. I've verified all 
> platforms are okay - except AIX which I'll need Thomas to recheck when 
> he can.
>
> I also discovered an oddity in that our ARM64 builds seem to use 
> different system libraries in that librt.so is not needed for 
> clock_gettime. This still seems to work ok. Of more of a concern if we 
> were expand this kind of function-existence check is that libc seems 
> to contain "dummy" (or at least dysfunctional) versions of a number of 
> the core pthread APIs!
>
> Thanks,
> David
>
>> Alternatively, rewrite them as CHECKING/RESULT, if you want to keep 
>> the logging. That way they match better the rest of the configure log 
>> (and also describes what you're doing). Just check if AC_SEARCH_LIBS 
>> prints some output (likely so, I think), then you can't do it in the 
>> middle of a CHECKING/RESULT pair, but have to do the CHECKING part 
>> after AC_SEARCH_LIBS.
>>
>> /Magnus
>>
>>>
>>> David
>>>
>>>> /Magnus
>>>>
>>>>>       hotspot:
>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>>>>
>>>>> First a big thank you to Thomas Stuefe for testing various 
>>>>> versions of
>>>>> this on AIX.
>>>>>
>>>>> This is primarily a refactoring and cleanup exercise (ie lots of
>>>>> deleted duplicated code!).
>>>>>
>>>>> I have taken the PlatformEvent, PlatformParker and Parker::* code, 
>>>>> out
>>>>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, 
>>>>> AIX
>>>>> and perhaps one day Solaris (more on that later).
>>>>>
>>>>> The Linux code was the most functionally complete, dealing with
>>>>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>>>>> default wall-clock for absolute timed waits. That functionality is
>>>>> not, unfortunately, supported by all our POSIX platforms so there are
>>>>> some configure time build checks to set some #defines, and then some
>>>>> dynamic lookup at runtime**. We allow for the runtime environment to
>>>>> be less capable than the build environment, but not the other way
>>>>> around (without build time support we don't know the runtime types
>>>>> needed to make library calls).
>>>>>
>>>>> ** There is some duplication of dynamic lookup code on Linux but this
>>>>> can be cleaned up in future work if we refactor the time/clock code
>>>>> into os_posix as well.
>>>>>
>>>>> The cleanup covers a number of things:
>>>>> - removal of linux anachronisms that got "ported" into the other
>>>>> platforms
>>>>>   - eg EINTR can not be returned from the wait methods
>>>>> - removal of solaris anachronisms that got ported into the linux code
>>>>> and then on to other platforms
>>>>>   - eg ETIMEDOUT is what we expect never ETIME
>>>>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>>>>> from the Parker methods
>>>>> - consolidation of unpackTime and compute_abstime into one utility
>>>>> function
>>>>> - use statics for things completely private to the implementation
>>>>> rather than making them part of the os* API (eg access to condAttr
>>>>> objects)
>>>>> - cleanup up commentary and style within methods of the same class
>>>>> - clean up coding style in places eg not using Names that start with
>>>>> capitals.
>>>>>
>>>>> I have not tried to cleanup every single oddity, nor tried to
>>>>> reconcile differences between the very similar in places 
>>>>> PlatformEvent
>>>>> and Park methods. For example PlatformEvent still examines the
>>>>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>>>>
>>>>> ** Perhaps a candidate for deprecation and future removal.
>>>>>
>>>>> There is one mini "enhancement" slipped in this. I now explicitly
>>>>> initialize mutexes with a mutexAttr object with its type set to
>>>>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>>>>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>>>>> "error checking" and so is slow. On all other current platforms there
>>>>> is no effective change.
>>>>>
>>>>> Finally, Solaris is excluded from all this (other than the debug
>>>>> signal blocking cleanup) because it potentially supports three
>>>>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>>>>> sync. Solaris cleanup would be a separate RFE.
>>>>>
>>>>> No doubt I've overlooked mentioning something that someone will 
>>>>> spot. :)
>>>>>
>>>>> Thanks,
>>>>> David
>>>>
>>



From magnus.ihse.bursie at oracle.com  Fri May 19 08:08:43 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 19 May 2017 10:08:43 +0200
Subject: RFR: JDK-8180480 Use "requires transitive" relationship when
 determining modules for javadoc
In-Reply-To: <BE441833-AF38-468A-BBEA-622E80C3A95C@oracle.com>
References: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
 <BE441833-AF38-468A-BBEA-622E80C3A95C@oracle.com>
Message-ID: <e9b8c2ac-60a6-4aad-0d85-3cb69e525d9a@oracle.com>



On 2017-05-18 17:30, Mandy Chung wrote:
>> On May 18, 2017, at 12:54 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> When the build system tries to figure out which modules that should be included by the javadoc build, it locates the set of modules "required" by already included modules, starting from an initial set and repeating recursively (a method which we unfortunately called "transitive?).
> Which module has this name clash?
>
>> However, for javadoc, we should only look at those re-exported modules that are classified by a "requires transitive" relationship (which I therefore have called "re-exported" to not clash with the established term "transitive?).
> Javadoc uses the ?Indirect Exports? term for the exported API packages are from the ?requires transitive? modules.

"Indirect exports" was a good term. I dropped the "Deps" part of the 
name and it all became much clearer.

Here's an updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.02

/Magnus

>
> I suggest to rename ?ReExported? to ?IndirectRequires? or ?Indirect?.
>
> Mandy
>
>> The effect of getting this wrong is e.g. that we copy module graph png files that we should not, and that we look at too broad a set of files for looking at changes that should trigger a re-build of the javadoc.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180480
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.01
>>
>> /Magnus



From erik.joelsson at oracle.com  Fri May 19 08:16:52 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 19 May 2017 10:16:52 +0200
Subject: RFR: JDK-8180480 Use "requires transitive" relationship when
 determining modules for javadoc
In-Reply-To: <e9b8c2ac-60a6-4aad-0d85-3cb69e525d9a@oracle.com>
References: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
 <BE441833-AF38-468A-BBEA-622E80C3A95C@oracle.com>
 <e9b8c2ac-60a6-4aad-0d85-3cb69e525d9a@oracle.com>
Message-ID: <759b6b92-567f-8854-d8d3-46298aceb33b@oracle.com>

Looks good.

/Erik


On 2017-05-19 10:08, Magnus Ihse Bursie wrote:
>
>
> On 2017-05-18 17:30, Mandy Chung wrote:
>>> On May 18, 2017, at 12:54 AM, Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> When the build system tries to figure out which modules that should 
>>> be included by the javadoc build, it locates the set of modules 
>>> "required" by already included modules, starting from an initial set 
>>> and repeating recursively (a method which we unfortunately called 
>>> "transitive?).
>> Which module has this name clash?
>>
>>> However, for javadoc, we should only look at those re-exported 
>>> modules that are classified by a "requires transitive" relationship 
>>> (which I therefore have called "re-exported" to not clash with the 
>>> established term "transitive?).
>> Javadoc uses the ?Indirect Exports? term for the exported API 
>> packages are from the ?requires transitive? modules.
>
> "Indirect exports" was a good term. I dropped the "Deps" part of the 
> name and it all became much clearer.
>
> Here's an updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.02 
>
>
> /Magnus
>
>>
>> I suggest to rename ?ReExported? to ?IndirectRequires? or ?Indirect?.
>>
>> Mandy
>>
>>> The effect of getting this wrong is e.g. that we copy module graph 
>>> png files that we should not, and that we look at too broad a set of 
>>> files for looking at changes that should trigger a re-build of the 
>>> javadoc.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180480
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.01
>>>
>>> /Magnus
>



From robbin.ehn at oracle.com  Fri May 19 08:36:29 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 19 May 2017 10:36:29 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
Message-ID: <ab704c9c-9f3d-a6a8-df8e-269e719ae46d@oracle.com>

Hi David,

On 05/18/2017 08:25 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
> 
> webrevs:
> 
> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>        hotspot: http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
> 

I like this, with neg delta of 700 loc, nice!

It's hard to see if you broken anything, since you combined 4 separate implementation into 1.
I guess you have tested this proper?

What stands out in os_posix.cpp is the
static void to_abstime(timespec* abstime, jlong timeout, bool isAbsolute)

The ifdef scopes of SUPPORTS_CLOCK_MONOTONIC is large and calculations are repeated 3 times.

Please consider something like:

#ifdef SUPPORTS_CLOCK_MONOTONIC
   if (_use_clock_monotonic_condattr  && !isAbsolute) { // Why aren't we using this when not isAbsolute is set?
						       // I suggest removing that check from this if and use monotonic for that also.
      struct timespec now;
      int status = _clock_gettime(CLOCK_MONOTONIC, &now);
      assert_status(status == 0, status, "clock_gettime");
      calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_nsec, NANOUNITS);
   } else {
#else
   {
#endif
      struct timeval now;
      int status = gettimeofday(&now, NULL);
      assert(status == 0, "gettimeofday");
      calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_usec, MICROUNITS);
   }
#endif

Thanks for fixing this!

/Robbin


From david.holmes at oracle.com  Fri May 19 08:53:18 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 May 2017 18:53:18 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <48795ff4-1b3e-0919-d008-93c3e0def878@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
 <1ef68ed4-91ca-b52d-2a75-1d66226ad21b@oracle.com>
 <48795ff4-1b3e-0919-d008-93c3e0def878@oracle.com>
Message-ID: <6cee21b8-bb88-8f3f-cf8f-698735eee456@oracle.com>

Thanks Erik!

David

On 19/05/2017 6:07 PM, Erik Joelsson wrote:
> Build changes look good to me.
> 
> /Erik
> 
> 
> On 2017-05-19 09:15, David Holmes wrote:
>> Hi Magnus,
>>
>> On 18/05/2017 8:06 PM, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2017-05-18 09:35, David Holmes wrote:
>>>> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>>>>> On 2017-05-18 08:25, David Holmes wrote:
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>>>>
>>>>>> webrevs:
>>>>>>
>>>>>> Build-related: 
>>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>>>>
>>>>> Build changes look  good.
>>>>
>>>> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging 
>>>> prints outs - do you want me to remove them? I suppose they may be 
>>>> useful if something goes wrong on some platform.
>>>
>>> I didn't even notice them. :-/
>>>
>>> It's a bit unfortunate we don't have a debug level on the logging 
>>> from configure. :-( Otherwise they would have clearly belonged there.
>>>
>>> The AC_MSG_NOTICE messages stands out much from the rest of the 
>>> configure log, so maybe it's better that you remove them. The logic 
>>> itself is very simple, if the -D flags are missing then we can surely 
>>> tell what happened. So yes, please remove them.
>>
>> Webrev updated in place.
>>
>> I have removed them to avoid noise - particularly as they get executed 
>> twice.
>>
>> I also made an adjustment to AC_SEARCH_LIBS as I don't want to pass 
>> the saved_LIBS value in explicitly, but want it to use the LIBS value 
>> - which is no longer cleared before the call. I've verified all 
>> platforms are okay - except AIX which I'll need Thomas to recheck when 
>> he can.
>>
>> I also discovered an oddity in that our ARM64 builds seem to use 
>> different system libraries in that librt.so is not needed for 
>> clock_gettime. This still seems to work ok. Of more of a concern if we 
>> were expand this kind of function-existence check is that libc seems 
>> to contain "dummy" (or at least dysfunctional) versions of a number of 
>> the core pthread APIs!
>>
>> Thanks,
>> David
>>
>>> Alternatively, rewrite them as CHECKING/RESULT, if you want to keep 
>>> the logging. That way they match better the rest of the configure log 
>>> (and also describes what you're doing). Just check if AC_SEARCH_LIBS 
>>> prints some output (likely so, I think), then you can't do it in the 
>>> middle of a CHECKING/RESULT pair, but have to do the CHECKING part 
>>> after AC_SEARCH_LIBS.
>>>
>>> /Magnus
>>>
>>>>
>>>> David
>>>>
>>>>> /Magnus
>>>>>
>>>>>>       hotspot:
>>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>>>>>
>>>>>> First a big thank you to Thomas Stuefe for testing various 
>>>>>> versions of
>>>>>> this on AIX.
>>>>>>
>>>>>> This is primarily a refactoring and cleanup exercise (ie lots of
>>>>>> deleted duplicated code!).
>>>>>>
>>>>>> I have taken the PlatformEvent, PlatformParker and Parker::* code, 
>>>>>> out
>>>>>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, 
>>>>>> AIX
>>>>>> and perhaps one day Solaris (more on that later).
>>>>>>
>>>>>> The Linux code was the most functionally complete, dealing with
>>>>>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>>>>>> default wall-clock for absolute timed waits. That functionality is
>>>>>> not, unfortunately, supported by all our POSIX platforms so there are
>>>>>> some configure time build checks to set some #defines, and then some
>>>>>> dynamic lookup at runtime**. We allow for the runtime environment to
>>>>>> be less capable than the build environment, but not the other way
>>>>>> around (without build time support we don't know the runtime types
>>>>>> needed to make library calls).
>>>>>>
>>>>>> ** There is some duplication of dynamic lookup code on Linux but this
>>>>>> can be cleaned up in future work if we refactor the time/clock code
>>>>>> into os_posix as well.
>>>>>>
>>>>>> The cleanup covers a number of things:
>>>>>> - removal of linux anachronisms that got "ported" into the other
>>>>>> platforms
>>>>>>   - eg EINTR can not be returned from the wait methods
>>>>>> - removal of solaris anachronisms that got ported into the linux code
>>>>>> and then on to other platforms
>>>>>>   - eg ETIMEDOUT is what we expect never ETIME
>>>>>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>>>>>> from the Parker methods
>>>>>> - consolidation of unpackTime and compute_abstime into one utility
>>>>>> function
>>>>>> - use statics for things completely private to the implementation
>>>>>> rather than making them part of the os* API (eg access to condAttr
>>>>>> objects)
>>>>>> - cleanup up commentary and style within methods of the same class
>>>>>> - clean up coding style in places eg not using Names that start with
>>>>>> capitals.
>>>>>>
>>>>>> I have not tried to cleanup every single oddity, nor tried to
>>>>>> reconcile differences between the very similar in places 
>>>>>> PlatformEvent
>>>>>> and Park methods. For example PlatformEvent still examines the
>>>>>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>>>>>
>>>>>> ** Perhaps a candidate for deprecation and future removal.
>>>>>>
>>>>>> There is one mini "enhancement" slipped in this. I now explicitly
>>>>>> initialize mutexes with a mutexAttr object with its type set to
>>>>>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>>>>>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>>>>>> "error checking" and so is slow. On all other current platforms there
>>>>>> is no effective change.
>>>>>>
>>>>>> Finally, Solaris is excluded from all this (other than the debug
>>>>>> signal blocking cleanup) because it potentially supports three
>>>>>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>>>>>> sync. Solaris cleanup would be a separate RFE.
>>>>>>
>>>>>> No doubt I've overlooked mentioning something that someone will 
>>>>>> spot. :)
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>
>>>
> 


From david.holmes at oracle.com  Fri May 19 09:07:46 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 May 2017 19:07:46 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <ab704c9c-9f3d-a6a8-df8e-269e719ae46d@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <ab704c9c-9f3d-a6a8-df8e-269e719ae46d@oracle.com>
Message-ID: <6ce9d6d2-d448-f571-0d73-ad6518c92834@oracle.com>

Hi Robbin,

Thanks for looking at this.

On 19/05/2017 6:36 PM, Robbin Ehn wrote:
> Hi David,
> 
> On 05/18/2017 08:25 AM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>
>> webrevs:
>>
>> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>        hotspot: 
>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>
> 
> I like this, with neg delta of 700 loc, nice!
> 
> It's hard to see if you broken anything, since you combined 4 separate 
> implementation into 1.

Well not really. As I said this is basically a cleaned up version of the 
Linux code. The BSD and AIX versions were already based on earlier 
versions of the Linux code, minus the proper handling of CLOCK_MONOTONIC 
and absolute timeouts.

> I guess you have tested this proper?

Only JPRT so far. I should have mentioned that I'm not expecting this to 
be reviewed in pushed within a couple of days, so some refinements and 
continual testing will occur.

> What stands out in os_posix.cpp is the
> static void to_abstime(timespec* abstime, jlong timeout, bool isAbsolute)
> 
> The ifdef scopes of SUPPORTS_CLOCK_MONOTONIC is large and calculations 
> are repeated 3 times.

They have to be as there are three cases:

1. Relative wait using CLOCK_MONOTONIC
2. Relative wait using gettimeofday()
3. Absolute wait using gettimeofday()

> Please consider something like:
> 
> #ifdef SUPPORTS_CLOCK_MONOTONIC
>    if (_use_clock_monotonic_condattr  && !isAbsolute) { // Why aren't we 
> using this when not isAbsolute is set?
>                                 // I suggest removing that check from 
> this if and use monotonic for that also.

Absolute waits have to be based on wall-clock time and follow any 
adjustments made to wall clock time. In contrast relative waits should 
never be affected by wall-clock time adjustments hence the use of 
CLOCK_MONOTONIC when available.

In Java the relative timed-waits are:
- Thread.sleep(ms)
- Object.wait(ms)/wait(ms,ns)
- LockSupport.parkNanos(ns) (and all the j.u.c blocking methods built on 
top of it)

While the only absolute timed-wait we have is the LockSupport.parkUntil 
method(s).

Hope that clarifies things.

Thanks,
David
-----

>       struct timespec now;
>       int status = _clock_gettime(CLOCK_MONOTONIC, &now);
>       assert_status(status == 0, status, "clock_gettime");
>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_nsec, 
> NANOUNITS);
>    } else {
> #else
>    {
> #endif
>       struct timeval now;
>       int status = gettimeofday(&now, NULL);
>       assert(status == 0, "gettimeofday");
>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_usec, 
> MICROUNITS);
>    }
> #endif
> 
> Thanks for fixing this!
> 
> /Robbin


From magnus.ihse.bursie at oracle.com  Fri May 19 09:15:21 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 19 May 2017 11:15:21 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <1ef68ed4-91ca-b52d-2a75-1d66226ad21b@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
 <1ef68ed4-91ca-b52d-2a75-1d66226ad21b@oracle.com>
Message-ID: <4d2113c5-e3a0-b6be-4a12-ecb6462a75df@oracle.com>


On 2017-05-19 09:15, David Holmes wrote:
> Hi Magnus,
>
> On 18/05/2017 8:06 PM, Magnus Ihse Bursie wrote:
>>
>>
>> On 2017-05-18 09:35, David Holmes wrote:
>>> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>>>> On 2017-05-18 08:25, David Holmes wrote:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>>>
>>>>> webrevs:
>>>>>
>>>>> Build-related: 
>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>>>
>>>> Build changes look  good.
>>>
>>> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging 
>>> prints outs - do you want me to remove them? I suppose they may be 
>>> useful if something goes wrong on some platform.
>>
>> I didn't even notice them. :-/
>>
>> It's a bit unfortunate we don't have a debug level on the logging 
>> from configure. :-( Otherwise they would have clearly belonged there.
>>
>> The AC_MSG_NOTICE messages stands out much from the rest of the 
>> configure log, so maybe it's better that you remove them. The logic 
>> itself is very simple, if the -D flags are missing then we can surely 
>> tell what happened. So yes, please remove them.
>
> Webrev updated in place.
Code looks good!

In the future, I very much prefer if you do not update webrevs in place. 
It's hopeless if you start reading a thread after some updates have 
occured, the mails don't make any sense, and it's hard to follow 
after-the-fact how the patch evolved.

>
> I have removed them to avoid noise - particularly as they get executed 
> twice.
>
> I also made an adjustment to AC_SEARCH_LIBS as I don't want to pass 
> the saved_LIBS value in explicitly, but want it to use the LIBS value 
> - which is no longer cleared before the call. I've verified all 
> platforms are okay - except AIX which I'll need Thomas to recheck when 
> he can.
>
> I also discovered an oddity in that our ARM64 builds seem to use 
> different system libraries in that librt.so is not needed for 
> clock_gettime. This still seems to work ok. Of more of a concern if we 
> were expand this kind of function-existence check is that libc seems 
> to contain "dummy" (or at least dysfunctional) versions of a number of 
> the core pthread APIs!
That's good to know.

/Magnus
>
> Thanks,
> David
>
>> Alternatively, rewrite them as CHECKING/RESULT, if you want to keep 
>> the logging. That way they match better the rest of the configure log 
>> (and also describes what you're doing). Just check if AC_SEARCH_LIBS 
>> prints some output (likely so, I think), then you can't do it in the 
>> middle of a CHECKING/RESULT pair, but have to do the CHECKING part 
>> after AC_SEARCH_LIBS.
>>
>> /Magnus
>>
>>>
>>> David
>>>
>>>> /Magnus
>>>>
>>>>>       hotspot:
>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>>>>
>>>>> First a big thank you to Thomas Stuefe for testing various 
>>>>> versions of
>>>>> this on AIX.
>>>>>
>>>>> This is primarily a refactoring and cleanup exercise (ie lots of
>>>>> deleted duplicated code!).
>>>>>
>>>>> I have taken the PlatformEvent, PlatformParker and Parker::* code, 
>>>>> out
>>>>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, 
>>>>> AIX
>>>>> and perhaps one day Solaris (more on that later).
>>>>>
>>>>> The Linux code was the most functionally complete, dealing with
>>>>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>>>>> default wall-clock for absolute timed waits. That functionality is
>>>>> not, unfortunately, supported by all our POSIX platforms so there are
>>>>> some configure time build checks to set some #defines, and then some
>>>>> dynamic lookup at runtime**. We allow for the runtime environment to
>>>>> be less capable than the build environment, but not the other way
>>>>> around (without build time support we don't know the runtime types
>>>>> needed to make library calls).
>>>>>
>>>>> ** There is some duplication of dynamic lookup code on Linux but this
>>>>> can be cleaned up in future work if we refactor the time/clock code
>>>>> into os_posix as well.
>>>>>
>>>>> The cleanup covers a number of things:
>>>>> - removal of linux anachronisms that got "ported" into the other
>>>>> platforms
>>>>>   - eg EINTR can not be returned from the wait methods
>>>>> - removal of solaris anachronisms that got ported into the linux code
>>>>> and then on to other platforms
>>>>>   - eg ETIMEDOUT is what we expect never ETIME
>>>>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>>>>> from the Parker methods
>>>>> - consolidation of unpackTime and compute_abstime into one utility
>>>>> function
>>>>> - use statics for things completely private to the implementation
>>>>> rather than making them part of the os* API (eg access to condAttr
>>>>> objects)
>>>>> - cleanup up commentary and style within methods of the same class
>>>>> - clean up coding style in places eg not using Names that start with
>>>>> capitals.
>>>>>
>>>>> I have not tried to cleanup every single oddity, nor tried to
>>>>> reconcile differences between the very similar in places 
>>>>> PlatformEvent
>>>>> and Park methods. For example PlatformEvent still examines the
>>>>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>>>>
>>>>> ** Perhaps a candidate for deprecation and future removal.
>>>>>
>>>>> There is one mini "enhancement" slipped in this. I now explicitly
>>>>> initialize mutexes with a mutexAttr object with its type set to
>>>>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>>>>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>>>>> "error checking" and so is slow. On all other current platforms there
>>>>> is no effective change.
>>>>>
>>>>> Finally, Solaris is excluded from all this (other than the debug
>>>>> signal blocking cleanup) because it potentially supports three
>>>>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>>>>> sync. Solaris cleanup would be a separate RFE.
>>>>>
>>>>> No doubt I've overlooked mentioning something that someone will 
>>>>> spot. :)
>>>>>
>>>>> Thanks,
>>>>> David
>>>>
>>



From david.holmes at oracle.com  Fri May 19 09:18:21 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 May 2017 19:18:21 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <4d2113c5-e3a0-b6be-4a12-ecb6462a75df@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
 <1ef68ed4-91ca-b52d-2a75-1d66226ad21b@oracle.com>
 <4d2113c5-e3a0-b6be-4a12-ecb6462a75df@oracle.com>
Message-ID: <e7c4716d-40da-97f4-cccf-6c6c615b7ee4@oracle.com>

Replying to all this time :)

On 19/05/2017 7:15 PM, Magnus Ihse Bursie wrote:
> 
> On 2017-05-19 09:15, David Holmes wrote:
>> Hi Magnus,
>>
>> On 18/05/2017 8:06 PM, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2017-05-18 09:35, David Holmes wrote:
>>>> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>>>>> On 2017-05-18 08:25, David Holmes wrote:
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>>>>
>>>>>> webrevs:
>>>>>>
>>>>>> Build-related: 
>>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>>>>
>>>>> Build changes look  good.
>>>>
>>>> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging 
>>>> prints outs - do you want me to remove them? I suppose they may be 
>>>> useful if something goes wrong on some platform.
>>>
>>> I didn't even notice them. :-/
>>>
>>> It's a bit unfortunate we don't have a debug level on the logging 
>>> from configure. :-( Otherwise they would have clearly belonged there.
>>>
>>> The AC_MSG_NOTICE messages stands out much from the rest of the 
>>> configure log, so maybe it's better that you remove them. The logic 
>>> itself is very simple, if the -D flags are missing then we can surely 
>>> tell what happened. So yes, please remove them.
>>
>> Webrev updated in place.
> Code looks good!

Thanks for the re-review.

> In the future, I very much prefer if you do not update webrevs in place. 
> It's hopeless if you start reading a thread after some updates have 
> occured, the mails don't make any sense, and it's hard to follow 
> after-the-fact how the patch evolved.

Sorry. Point taken.

David
-----


>>
>> I have removed them to avoid noise - particularly as they get executed 
>> twice.
>>
>> I also made an adjustment to AC_SEARCH_LIBS as I don't want to pass 
>> the saved_LIBS value in explicitly, but want it to use the LIBS value 
>> - which is no longer cleared before the call. I've verified all 
>> platforms are okay - except AIX which I'll need Thomas to recheck when 
>> he can.
>>
>> I also discovered an oddity in that our ARM64 builds seem to use 
>> different system libraries in that librt.so is not needed for 
>> clock_gettime. This still seems to work ok. Of more of a concern if we 
>> were expand this kind of function-existence check is that libc seems 
>> to contain "dummy" (or at least dysfunctional) versions of a number of 
>> the core pthread APIs!
> That's good to know.
> 
> /Magnus
>>
>> Thanks,
>> David
>>
>>> Alternatively, rewrite them as CHECKING/RESULT, if you want to keep 
>>> the logging. That way they match better the rest of the configure log 
>>> (and also describes what you're doing). Just check if AC_SEARCH_LIBS 
>>> prints some output (likely so, I think), then you can't do it in the 
>>> middle of a CHECKING/RESULT pair, but have to do the CHECKING part 
>>> after AC_SEARCH_LIBS.
>>>
>>> /Magnus
>>>
>>>>
>>>> David
>>>>
>>>>> /Magnus
>>>>>
>>>>>>       hotspot:
>>>>>> http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
>>>>>>
>>>>>> First a big thank you to Thomas Stuefe for testing various 
>>>>>> versions of
>>>>>> this on AIX.
>>>>>>
>>>>>> This is primarily a refactoring and cleanup exercise (ie lots of
>>>>>> deleted duplicated code!).
>>>>>>
>>>>>> I have taken the PlatformEvent, PlatformParker and Parker::* code, 
>>>>>> out
>>>>>> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, 
>>>>>> AIX
>>>>>> and perhaps one day Solaris (more on that later).
>>>>>>
>>>>>> The Linux code was the most functionally complete, dealing with
>>>>>> correct use of CLOCK_MONOTONIC for relative timed waits, and the
>>>>>> default wall-clock for absolute timed waits. That functionality is
>>>>>> not, unfortunately, supported by all our POSIX platforms so there are
>>>>>> some configure time build checks to set some #defines, and then some
>>>>>> dynamic lookup at runtime**. We allow for the runtime environment to
>>>>>> be less capable than the build environment, but not the other way
>>>>>> around (without build time support we don't know the runtime types
>>>>>> needed to make library calls).
>>>>>>
>>>>>> ** There is some duplication of dynamic lookup code on Linux but this
>>>>>> can be cleaned up in future work if we refactor the time/clock code
>>>>>> into os_posix as well.
>>>>>>
>>>>>> The cleanup covers a number of things:
>>>>>> - removal of linux anachronisms that got "ported" into the other
>>>>>> platforms
>>>>>>   - eg EINTR can not be returned from the wait methods
>>>>>> - removal of solaris anachronisms that got ported into the linux code
>>>>>> and then on to other platforms
>>>>>>   - eg ETIMEDOUT is what we expect never ETIME
>>>>>> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals()
>>>>>> from the Parker methods
>>>>>> - consolidation of unpackTime and compute_abstime into one utility
>>>>>> function
>>>>>> - use statics for things completely private to the implementation
>>>>>> rather than making them part of the os* API (eg access to condAttr
>>>>>> objects)
>>>>>> - cleanup up commentary and style within methods of the same class
>>>>>> - clean up coding style in places eg not using Names that start with
>>>>>> capitals.
>>>>>>
>>>>>> I have not tried to cleanup every single oddity, nor tried to
>>>>>> reconcile differences between the very similar in places 
>>>>>> PlatformEvent
>>>>>> and Park methods. For example PlatformEvent still examines the
>>>>>> FilterSpuriousWakeups** flag, and Parker still ignores it.
>>>>>>
>>>>>> ** Perhaps a candidate for deprecation and future removal.
>>>>>>
>>>>>> There is one mini "enhancement" slipped in this. I now explicitly
>>>>>> initialize mutexes with a mutexAttr object with its type set to
>>>>>> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of
>>>>>> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but
>>>>>> "error checking" and so is slow. On all other current platforms there
>>>>>> is no effective change.
>>>>>>
>>>>>> Finally, Solaris is excluded from all this (other than the debug
>>>>>> signal blocking cleanup) because it potentially supports three
>>>>>> different low-level sync subsystems: UI thr*, Pthread, and direct LWP
>>>>>> sync. Solaris cleanup would be a separate RFE.
>>>>>>
>>>>>> No doubt I've overlooked mentioning something that someone will 
>>>>>> spot. :)
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>
>>>
> 


From doug.simon at oracle.com  Fri May 19 09:19:42 2017
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 19 May 2017 11:19:42 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <4d2113c5-e3a0-b6be-4a12-ecb6462a75df@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <1c0a1da9-0c45-785c-9393-e79aad985746@oracle.com>
 <c274323d-6301-3bc4-5012-d22e84ad7807@oracle.com>
 <b9edff60-e311-06b1-9377-4a4c084751d7@oracle.com>
 <1ef68ed4-91ca-b52d-2a75-1d66226ad21b@oracle.com>
 <4d2113c5-e3a0-b6be-4a12-ecb6462a75df@oracle.com>
Message-ID: <51717D86-1BCB-4C6F-947F-65A43E67554D@oracle.com>


> On 19 May 2017, at 11:15, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> 
> On 2017-05-19 09:15, David Holmes wrote:
>> Hi Magnus,
>> 
>> On 18/05/2017 8:06 PM, Magnus Ihse Bursie wrote:
>>> 
>>> 
>>> On 2017-05-18 09:35, David Holmes wrote:
>>>> On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
>>>>> On 2017-05-18 08:25, David Holmes wrote:
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>>>>>> 
>>>>>> webrevs:
>>>>>> 
>>>>>> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
>>>>> 
>>>>> Build changes look  good.
>>>> 
>>>> Thanks Magnus! I just realized I left in the AC_MSG_NOTICE debugging prints outs - do you want me to remove them? I suppose they may be useful if something goes wrong on some platform.
>>> 
>>> I didn't even notice them. :-/
>>> 
>>> It's a bit unfortunate we don't have a debug level on the logging from configure. :-( Otherwise they would have clearly belonged there.
>>> 
>>> The AC_MSG_NOTICE messages stands out much from the rest of the configure log, so maybe it's better that you remove them. The logic itself is very simple, if the -D flags are missing then we can surely tell what happened. So yes, please remove them.
>> 
>> Webrev updated in place.
> Code looks good!
> 
> In the future, I very much prefer if you do not update webrevs in place. It's hopeless if you start reading a thread after some updates have occured, the mails don't make any sense, and it's hard to follow after-the-fact how the patch evolved.

Is there any chance openjdk code reviewing will adopt a slightly more modern process than webrevs such as Crucible where a full history of code evolution during a review is preserved?

-Doug

From robbin.ehn at oracle.com  Fri May 19 09:25:13 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 19 May 2017 11:25:13 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <6ce9d6d2-d448-f571-0d73-ad6518c92834@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <ab704c9c-9f3d-a6a8-df8e-269e719ae46d@oracle.com>
 <6ce9d6d2-d448-f571-0d73-ad6518c92834@oracle.com>
Message-ID: <16450c53-7032-72aa-116e-b8757db2786c@oracle.com>

On 05/19/2017 11:07 AM, David Holmes wrote:
> 
> They have to be as there are three cases:
> 
> 1. Relative wait using CLOCK_MONOTONIC
> 2. Relative wait using gettimeofday()
> 3. Absolute wait using gettimeofday()
> 
>> Please consider something like:
>>
>> #ifdef SUPPORTS_CLOCK_MONOTONIC
>>    if (_use_clock_monotonic_condattr  && !isAbsolute) { // Why aren't we using this when not isAbsolute is set?
>>                                 // I suggest removing that check from this if and use monotonic for that also.
> 
> Absolute waits have to be based on wall-clock time and follow any adjustments made to wall clock time. In contrast relative waits should never be affected by wall-clock 
> time adjustments hence the use of CLOCK_MONOTONIC when available.
> 
> In Java the relative timed-waits are:
> - Thread.sleep(ms)
> - Object.wait(ms)/wait(ms,ns)
> - LockSupport.parkNanos(ns) (and all the j.u.c blocking methods built on top of it)
> 
> While the only absolute timed-wait we have is the LockSupport.parkUntil method(s).
> 
> Hope that clarifies things.

Yes thanks!

But you can still re-factoring to something similar to what I suggested and two of the calculation should be the same just ns vs us, correct?
Leaving the if statement with the "!isAbsolute" check, in my head calc_time is something like:

void calc_time(...) {
   if (isAbsolute) {
     calc_abs_time(...);
   } else {
     calc_rel_time(...);
   }
}

I do not see a problem with this, only better readability?

/Robbin

> 
> Thanks,
> David
> -----
> 
>>       struct timespec now;
>>       int status = _clock_gettime(CLOCK_MONOTONIC, &now);
>>       assert_status(status == 0, status, "clock_gettime");
>>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_nsec, NANOUNITS);
>>    } else {
>> #else
>>    {
>> #endif
>>       struct timeval now;
>>       int status = gettimeofday(&now, NULL);
>>       assert(status == 0, "gettimeofday");
>>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_usec, MICROUNITS);
>>    }
>> #endif
>>
>> Thanks for fixing this!
>>
>> /Robbin


From erik.joelsson at oracle.com  Fri May 19 09:26:31 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 19 May 2017 11:26:31 +0200
Subject: RFR: JDK-8180651: Make target to run tests on exploded image
Message-ID: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>

In most cases, when running regression tests, you want to run them on 
the jdk image because that's the correct image and some tests will not 
work on other variants. However, many tests can be run successfully on 
the exploded image and since building the full jdk image takes quite a 
bit of extra time, especially when running a slowdebug build, enabling 
this as an option can significantly improve developer efficiency.

I therefor propose the new target "exploded-run-test". It will work just 
like run-test but it depends on and runs on the exploded image.

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

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

/Erik



From magnus.ihse.bursie at oracle.com  Fri May 19 09:28:19 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 19 May 2017 11:28:19 +0200
Subject: RFR: JDK-8175824 Adapt javadoc generation to different requirements
 for JDK and JavaSE
Message-ID: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>

javadoc allows a file to be specified to provide content for the top 
level "overview" page.

As we move towards a unified docs bundle, we need to be able to vary the 
content of that file depending on the content of the bundle. This does 
not mean providing or including lists of modules, but should reflect 
whether the bundle contains Java SE modules, JDK modules and JavaFX 
modules.

This patch also includes support for (and relies on) the new usage of 
the -group option from JDK-8180336.

Note that when JDK-8180480 (Use "requires transitive" relationship when 
determining modules for javadoc) is pushed, the call to 
FindTransitiveDepsForModules for JavaSE_MODULES should be updated to the 
new FindTransitiveIndirectExportsForModules (or whatever it'll end up 
being called). I'll fix that in whichever of the two bugs I push last.

This patch also contains some accumulated cleanup in Docs.gmk after all 
the piecemeal patches this file has recieved for the last few weeks.

Note: While I'm willing to make minor changes to the actual contents of 
the generated overview.html, I'd prefer if any larger (or potentially 
controversial) issues are handled as separate follow-up bugs. With this 
framework in place, it's easy to modify whatever gets written to the file.

An example how this looks like for the JDK and Java SE documentation 
collections (stripped down to the summary page of the javadoc output, 
and the JDK top-level index.html) is here:
http://cr.openjdk.java.net/~ihse/demo-generated-overview/

Bug: https://bugs.openjdk.java.net/browse/JDK-8175824
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.01



From robbin.ehn at oracle.com  Fri May 19 09:30:24 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 19 May 2017 11:30:24 +0200
Subject: RFR: JDK-8180651: Make target to run tests on exploded image
In-Reply-To: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
References: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
Message-ID: <56ad68c4-7020-2591-4484-e758d74f95b6@oracle.com>

Thank you Erik for doing this!

/Robbin

On 05/19/2017 11:26 AM, Erik Joelsson wrote:
> In most cases, when running regression tests, you want to run them on the jdk image because that's the correct image and some tests will not work on other variants. 
> However, many tests can be run successfully on the exploded image and since building the full jdk image takes quite a bit of extra time, especially when running a slowdebug 
> build, enabling this as an option can significantly improve developer efficiency.
> 
> I therefor propose the new target "exploded-run-test". It will work just like run-test but it depends on and runs on the exploded image.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180651
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8180651/webrev.01/
> 
> /Erik
> 


From magnus.ihse.bursie at oracle.com  Fri May 19 09:45:17 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 19 May 2017 11:45:17 +0200
Subject: RFR: JDK-8180651: Make target to run tests on exploded image
In-Reply-To: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
References: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
Message-ID: <0a0507d7-3f02-377c-9b8b-94d4e8e52b10@oracle.com>

I like the idea, the changes in itself look good, but I really *really* 
do not like the name "exploded". It was not good before as in 
"exploded-image", but this is even worse. :-(

Can we pause this one for just a while and try really hard to come up 
with a better name? If we fail to do that in a couple of days, I'll 
admit defeat and accept the patch as it is. OK?

What about "local" image? "simple"? "quick"? "bare"?

/Magnus

On 2017-05-19 11:26, Erik Joelsson wrote:
> In most cases, when running regression tests, you want to run them on 
> the jdk image because that's the correct image and some tests will not 
> work on other variants. However, many tests can be run successfully on 
> the exploded image and since building the full jdk image takes quite a 
> bit of extra time, especially when running a slowdebug build, enabling 
> this as an option can significantly improve developer efficiency.
>
> I therefor propose the new target "exploded-run-test". It will work 
> just like run-test but it depends on and runs on the exploded image.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180651
>
> Webrev: http://cr.openjdk.java.net/~erikj/8180651/webrev.01/
>
> /Erik
>



From david.holmes at oracle.com  Fri May 19 10:53:50 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 May 2017 20:53:50 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <16450c53-7032-72aa-116e-b8757db2786c@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <ab704c9c-9f3d-a6a8-df8e-269e719ae46d@oracle.com>
 <6ce9d6d2-d448-f571-0d73-ad6518c92834@oracle.com>
 <16450c53-7032-72aa-116e-b8757db2786c@oracle.com>
Message-ID: <bab94f72-120e-1007-bedb-762b81e7972e@oracle.com>

On 19/05/2017 7:25 PM, Robbin Ehn wrote:
> On 05/19/2017 11:07 AM, David Holmes wrote:
>>
>> They have to be as there are three cases:
>>
>> 1. Relative wait using CLOCK_MONOTONIC
>> 2. Relative wait using gettimeofday()
>> 3. Absolute wait using gettimeofday()
>>
>>> Please consider something like:
>>>
>>> #ifdef SUPPORTS_CLOCK_MONOTONIC
>>>    if (_use_clock_monotonic_condattr  && !isAbsolute) { // Why aren't 
>>> we using this when not isAbsolute is set?
>>>                                 // I suggest removing that check from 
>>> this if and use monotonic for that also.
>>
>> Absolute waits have to be based on wall-clock time and follow any 
>> adjustments made to wall clock time. In contrast relative waits should 
>> never be affected by wall-clock time adjustments hence the use of 
>> CLOCK_MONOTONIC when available.
>>
>> In Java the relative timed-waits are:
>> - Thread.sleep(ms)
>> - Object.wait(ms)/wait(ms,ns)
>> - LockSupport.parkNanos(ns) (and all the j.u.c blocking methods built 
>> on top of it)
>>
>> While the only absolute timed-wait we have is the 
>> LockSupport.parkUntil method(s).
>>
>> Hope that clarifies things.
> 
> Yes thanks!
> 
> But you can still re-factoring to something similar to what I suggested 
> and two of the calculation should be the same just ns vs us, correct?

There are three different forms of the calculation. The two relative 
time versions use a different time function and so a different time 
structure (timeval vs timespec) and a different calculation.

> Leaving the if statement with the "!isAbsolute" check, in my head 
> calc_time is something like:
> 
> void calc_time(...) {
>    if (isAbsolute) {
>      calc_abs_time(...);
>    } else {
#ifdef SUPPORTS_CLOCK_MONOTONIC
>      calc_rel_time_from_clock_monotonic(...);
#else
 >      calc_rel_time_from_gettimeofday(...);
#endif
>    }
> }

David
-----

> I do not see a problem with this, only better readability?
> 
> /Robbin
> 
>>
>> Thanks,
>> David
>> -----
>>
>>>       struct timespec now;
>>>       int status = _clock_gettime(CLOCK_MONOTONIC, &now);
>>>       assert_status(status == 0, status, "clock_gettime");
>>>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, 
>>> now.tv_nsec, NANOUNITS);
>>>    } else {
>>> #else
>>>    {
>>> #endif
>>>       struct timeval now;
>>>       int status = gettimeofday(&now, NULL);
>>>       assert(status == 0, "gettimeofday");
>>>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, 
>>> now.tv_usec, MICROUNITS);
>>>    }
>>> #endif
>>>
>>> Thanks for fixing this!
>>>
>>> /Robbin


From erik.joelsson at oracle.com  Fri May 19 10:55:47 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 19 May 2017 12:55:47 +0200
Subject: RFR: JDK-8180651: Make target to run tests on exploded image
In-Reply-To: <0a0507d7-3f02-377c-9b8b-94d4e8e52b10@oracle.com>
References: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
 <0a0507d7-3f02-377c-9b8b-94d4e8e52b10@oracle.com>
Message-ID: <aa3109cc-2156-9e1a-9170-e3462df0d863@oracle.com>

Sure we can pause this. Robbin has a local patch to play with for now.

If you want another name, then we should also rename exploded-image. As 
I understand it, the name exploded is well established. It refers to the 
java class files/resources not being in jars/jimage format, but exploded 
as separate files in a directory structure.

/Erik


On 2017-05-19 11:45, Magnus Ihse Bursie wrote:
> I like the idea, the changes in itself look good, but I really 
> *really* do not like the name "exploded". It was not good before as in 
> "exploded-image", but this is even worse. :-(
>
> Can we pause this one for just a while and try really hard to come up 
> with a better name? If we fail to do that in a couple of days, I'll 
> admit defeat and accept the patch as it is. OK?
>
> What about "local" image? "simple"? "quick"? "bare"?
>
> /Magnus
>
> On 2017-05-19 11:26, Erik Joelsson wrote:
>> In most cases, when running regression tests, you want to run them on 
>> the jdk image because that's the correct image and some tests will 
>> not work on other variants. However, many tests can be run 
>> successfully on the exploded image and since building the full jdk 
>> image takes quite a bit of extra time, especially when running a 
>> slowdebug build, enabling this as an option can significantly improve 
>> developer efficiency.
>>
>> I therefor propose the new target "exploded-run-test". It will work 
>> just like run-test but it depends on and runs on the exploded image.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180651
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8180651/webrev.01/
>>
>> /Erik
>>
>



From erik.joelsson at oracle.com  Fri May 19 11:10:16 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 19 May 2017 13:10:16 +0200
Subject: RFR: JDK-8175824 Adapt javadoc generation to different
 requirements for JDK and JavaSE
In-Reply-To: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>
References: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>
Message-ID: <3c199017-f282-f309-161c-8789bc81c2eb@oracle.com>

Looks good.

Minor nit. There are variables named JavaSE_MODULES as well as 
JAVASE_MODULES which can be a bit confusing. Perhaps the latter can be 
inlined at this point? Or the first should perhaps be called 
JavaSE_GROUP_MODULES?

/Erik


On 2017-05-19 11:28, Magnus Ihse Bursie wrote:
> javadoc allows a file to be specified to provide content for the top 
> level "overview" page.
>
> As we move towards a unified docs bundle, we need to be able to vary 
> the content of that file depending on the content of the bundle. This 
> does not mean providing or including lists of modules, but should 
> reflect whether the bundle contains Java SE modules, JDK modules and 
> JavaFX modules.
>
> This patch also includes support for (and relies on) the new usage of 
> the -group option from JDK-8180336.
>
> Note that when JDK-8180480 (Use "requires transitive" relationship 
> when determining modules for javadoc) is pushed, the call to 
> FindTransitiveDepsForModules for JavaSE_MODULES should be updated to 
> the new FindTransitiveIndirectExportsForModules (or whatever it'll end 
> up being called). I'll fix that in whichever of the two bugs I push last.
>
> This patch also contains some accumulated cleanup in Docs.gmk after 
> all the piecemeal patches this file has recieved for the last few weeks.
>
> Note: While I'm willing to make minor changes to the actual contents 
> of the generated overview.html, I'd prefer if any larger (or 
> potentially controversial) issues are handled as separate follow-up 
> bugs. With this framework in place, it's easy to modify whatever gets 
> written to the file.
>
> An example how this looks like for the JDK and Java SE documentation 
> collections (stripped down to the summary page of the javadoc output, 
> and the JDK top-level index.html) is here:
> http://cr.openjdk.java.net/~ihse/demo-generated-overview/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175824
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.01
>



From david.holmes at oracle.com  Fri May 19 11:36:11 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 May 2017 21:36:11 +1000
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <bab94f72-120e-1007-bedb-762b81e7972e@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <ab704c9c-9f3d-a6a8-df8e-269e719ae46d@oracle.com>
 <6ce9d6d2-d448-f571-0d73-ad6518c92834@oracle.com>
 <16450c53-7032-72aa-116e-b8757db2786c@oracle.com>
 <bab94f72-120e-1007-bedb-762b81e7972e@oracle.com>
Message-ID: <bcd593fc-463d-df41-ed62-2081eb260585@oracle.com>

Correction ...

On 19/05/2017 8:53 PM, David Holmes wrote:
> On 19/05/2017 7:25 PM, Robbin Ehn wrote:
>> On 05/19/2017 11:07 AM, David Holmes wrote:
>>>
>>> They have to be as there are three cases:
>>>
>>> 1. Relative wait using CLOCK_MONOTONIC
>>> 2. Relative wait using gettimeofday()
>>> 3. Absolute wait using gettimeofday()
>>>
>>>> Please consider something like:
>>>>
>>>> #ifdef SUPPORTS_CLOCK_MONOTONIC
>>>>    if (_use_clock_monotonic_condattr  && !isAbsolute) { // Why 
>>>> aren't we using this when not isAbsolute is set?
>>>>                                 // I suggest removing that check 
>>>> from this if and use monotonic for that also.
>>>
>>> Absolute waits have to be based on wall-clock time and follow any 
>>> adjustments made to wall clock time. In contrast relative waits 
>>> should never be affected by wall-clock time adjustments hence the use 
>>> of CLOCK_MONOTONIC when available.
>>>
>>> In Java the relative timed-waits are:
>>> - Thread.sleep(ms)
>>> - Object.wait(ms)/wait(ms,ns)
>>> - LockSupport.parkNanos(ns) (and all the j.u.c blocking methods built 
>>> on top of it)
>>>
>>> While the only absolute timed-wait we have is the 
>>> LockSupport.parkUntil method(s).
>>>
>>> Hope that clarifies things.
>>
>> Yes thanks!
>>
>> But you can still re-factoring to something similar to what I 
>> suggested and two of the calculation should be the same just ns vs us, 
>> correct?
> 
> There are three different forms of the calculation. The two relative 
> time versions use a different time function and so a different time 
> structure (timeval vs timespec) and a different calculation.
> 
>> Leaving the if statement with the "!isAbsolute" check, in my head 
>> calc_time is something like:
>>
>> void calc_time(...) {
>>    if (isAbsolute) {
>>      calc_abs_time(...);
>>    } else {
> #ifdef SUPPORTS_CLOCK_MONOTONIC
>>      calc_rel_time_from_clock_monotonic(...);
> #else
>  >      calc_rel_time_from_gettimeofday(...);
> #endif
>>    }
>> }

It's more complicated than that because we may have build time 
SUPPORTS_CLOCK_MONOTONIC but we still need the runtime check as well.

to_abstime is the old linux unpackTime with the addition of the build 
time conditionals.

David

> David
> -----
> 
>> I do not see a problem with this, only better readability?
>>
>> /Robbin
>>
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>>       struct timespec now;
>>>>       int status = _clock_gettime(CLOCK_MONOTONIC, &now);
>>>>       assert_status(status == 0, status, "clock_gettime");
>>>>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, 
>>>> now.tv_nsec, NANOUNITS);
>>>>    } else {
>>>> #else
>>>>    {
>>>> #endif
>>>>       struct timeval now;
>>>>       int status = gettimeofday(&now, NULL);
>>>>       assert(status == 0, "gettimeofday");
>>>>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, 
>>>> now.tv_usec, MICROUNITS);
>>>>    }
>>>> #endif
>>>>
>>>> Thanks for fixing this!
>>>>
>>>> /Robbin


From robbin.ehn at oracle.com  Fri May 19 12:33:46 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 19 May 2017 14:33:46 +0200
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <bcd593fc-463d-df41-ed62-2081eb260585@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
 <ab704c9c-9f3d-a6a8-df8e-269e719ae46d@oracle.com>
 <6ce9d6d2-d448-f571-0d73-ad6518c92834@oracle.com>
 <16450c53-7032-72aa-116e-b8757db2786c@oracle.com>
 <bab94f72-120e-1007-bedb-762b81e7972e@oracle.com>
 <bcd593fc-463d-df41-ed62-2081eb260585@oracle.com>
Message-ID: <9bd7dd4b-b513-88b4-92fb-0c815b479252@oracle.com>

Hi David

On 05/19/2017 01:36 PM, David Holmes wrote:
>>
>> There are three different forms of the calculation. The two relative time versions use a different time function and so a different time structure (timeval vs timespec) 
>> and a different calculation.

Yes that's why I included unit in my example signature.

> 
> It's more complicated than that because we may have build time SUPPORTS_CLOCK_MONOTONIC but we still need the runtime check as well.
> 
> to_abstime is the old linux unpackTime with the addition of the build time conditionals.

I'm not changing that, I'm not sure how to explain better,
so here is the patch (only compiled and silly naming convention):
http://cr.openjdk.java.net/~rehn/8174231/webrev/

This makes the calculation independent of source/unit.

Thanks!

/Robbin



> 
> David
> 
>> David
>> -----
>>
>>> I do not see a problem with this, only better readability?
>>>
>>> /Robbin
>>>
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>>       struct timespec now;
>>>>>       int status = _clock_gettime(CLOCK_MONOTONIC, &now);
>>>>>       assert_status(status == 0, status, "clock_gettime");
>>>>>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_nsec, NANOUNITS);
>>>>>    } else {
>>>>> #else
>>>>>    {
>>>>> #endif
>>>>>       struct timeval now;
>>>>>       int status = gettimeofday(&now, NULL);
>>>>>       assert(status == 0, "gettimeofday");
>>>>>       calc_time(abstime, timeout, isAbsolute, now.tv_sec, now.tv_usec, MICROUNITS);
>>>>>    }
>>>>> #endif
>>>>>
>>>>> Thanks for fixing this!
>>>>>
>>>>> /Robbin


From mandy.chung at oracle.com  Fri May 19 14:47:43 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 19 May 2017 07:47:43 -0700
Subject: RFR: JDK-8180480 Use "requires transitive" relationship when
 determining modules for javadoc
In-Reply-To: <e9b8c2ac-60a6-4aad-0d85-3cb69e525d9a@oracle.com>
References: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
 <BE441833-AF38-468A-BBEA-622E80C3A95C@oracle.com>
 <e9b8c2ac-60a6-4aad-0d85-3cb69e525d9a@oracle.com>
Message-ID: <52FEC3AF-1084-4146-A460-377357B12E38@oracle.com>


> On May 19, 2017, at 1:08 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> 
> "Indirect exports" was a good term. I dropped the "Deps" part of the name and it all became much clearer.
> 
> Here's an updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.02
> 

+  $1_INDIRECT_EXPORTS := $$(call FindTransitiveIndirectExportsForModules, $$($1_MODULES))

Nit: ?exported? term is for API but not for dependency.  

s/$1_INDIRECT_EXPORTS/$1_TRANSITIVE_MODULES
s/FindTransitiveIndirectExportsForModules/FindTransitiveIndirectDepsForModules

Otherwise, looks good.  No need for a new webrev:

Mandy

From mandy.chung at oracle.com  Fri May 19 15:09:11 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 19 May 2017 08:09:11 -0700
Subject: RFR: JDK-8175824 Adapt javadoc generation to different
 requirements for JDK and JavaSE
In-Reply-To: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>
References: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>
Message-ID: <BE689606-C778-4A22-A83E-EF5D9DFE339F@oracle.com>

Magnus,

Iris and Kevin provides the description for each group.  The overview page
can look like this:

This document is the Java? Platform, Standard Edition Development Kit (JDK?) 9  API Specification.

Java SE
        The Java Platform, Standard Edition (?Java SE?) APIs define 
	the core Java platform for general-purpose computing. These APIs
	are in modules with names starting with the string ?java.?.

JDK
	The Java Development Kit (?JDK?) APIs define an implementation
	of the Java SE Platform which may include platform-specific details. 
	These APIs are in modules with names starting with the string ?jdk.?.

JavaFX
	The JavaFX APIs define a set of user interface (UI) controls,
	graphics, media, and web packages for developing rich client 
	applications. These APIs are in modules with names starting with 
	the string "javafx.?.

Java SE, JDK, JavaFX links to the corresponding table.

Mandy

> On May 19, 2017, at 2:28 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> javadoc allows a file to be specified to provide content for the top level "overview" page.
> 
> As we move towards a unified docs bundle, we need to be able to vary the content of that file depending on the content of the bundle. This does not mean providing or including lists of modules, but should reflect whether the bundle contains Java SE modules, JDK modules and JavaFX modules.
> 
> This patch also includes support for (and relies on) the new usage of the -group option from JDK-8180336.
> 
> Note that when JDK-8180480 (Use "requires transitive" relationship when determining modules for javadoc) is pushed, the call to FindTransitiveDepsForModules for JavaSE_MODULES should be updated to the new FindTransitiveIndirectExportsForModules (or whatever it'll end up being called). I'll fix that in whichever of the two bugs I push last.
> 
> This patch also contains some accumulated cleanup in Docs.gmk after all the piecemeal patches this file has recieved for the last few weeks.
> 
> Note: While I'm willing to make minor changes to the actual contents of the generated overview.html, I'd prefer if any larger (or potentially controversial) issues are handled as separate follow-up bugs. With this framework in place, it's easy to modify whatever gets written to the file.
> 
> An example how this looks like for the JDK and Java SE documentation collections (stripped down to the summary page of the javadoc output, and the JDK top-level index.html) is here:
> http://cr.openjdk.java.net/~ihse/demo-generated-overview/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175824
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.01
> 



From robbin.ehn at oracle.com  Fri May 19 15:36:22 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 19 May 2017 17:36:22 +0200
Subject: RFR: JDK-8180651: Make target to run tests on exploded image
In-Reply-To: <aa3109cc-2156-9e1a-9170-e3462df0d863@oracle.com>
References: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
 <0a0507d7-3f02-377c-9b8b-94d4e8e52b10@oracle.com>
 <aa3109cc-2156-9e1a-9170-e3462df0d863@oracle.com>
Message-ID: <ec6822ca-88e6-e0cf-f358-b57c635625b7@oracle.com>

Hi,

On 05/19/2017 12:55 PM, Erik Joelsson wrote:
> Sure we can pause this. Robbin has a local patch to play with for now.

Yes, no rush for me.

> 
> If you want another name, then we should also rename exploded-image. As I understand it, the name exploded is well established. It refers to the java class files/resources 
> not being in jars/jimage format, but exploded as separate files in a directory structure.

I would prefer to keep the name exploded for these reasons.

/Robbin

> 
> /Erik
> 
> 
> On 2017-05-19 11:45, Magnus Ihse Bursie wrote:
>> I like the idea, the changes in itself look good, but I really *really* do not like the name "exploded". It was not good before as in "exploded-image", but this is even 
>> worse. :-(
>>
>> Can we pause this one for just a while and try really hard to come up with a better name? If we fail to do that in a couple of days, I'll admit defeat and accept the 
>> patch as it is. OK?
>>
>> What about "local" image? "simple"? "quick"? "bare"?
>>
>> /Magnus
>>
>> On 2017-05-19 11:26, Erik Joelsson wrote:
>>> In most cases, when running regression tests, you want to run them on the jdk image because that's the correct image and some tests will not work on other variants. 
>>> However, many tests can be run successfully on the exploded image and since building the full jdk image takes quite a bit of extra time, especially when running a 
>>> slowdebug build, enabling this as an option can significantly improve developer efficiency.
>>>
>>> I therefor propose the new target "exploded-run-test". It will work just like run-test but it depends on and runs on the exploded image.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180651
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8180651/webrev.01/
>>>
>>> /Erik
>>>
>>
> 


From mandy.chung at oracle.com  Fri May 19 20:48:56 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 19 May 2017 13:48:56 -0700
Subject: Review Request: JDK-8180717:  Upgrade the docs bundle index page
Message-ID: <5376BFBA-EFB8-4FE5-9DCE-1590957FFE29@oracle.com>

This patch updates the build tool to generate an improved presentation of the module groupings.  A sample page: 
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180717/docs/index.html

Webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180717/webrev.00/	

Thanks
Mandy

From jonathan.gibbons at oracle.com  Sat May 20 00:21:23 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 19 May 2017 17:21:23 -0700
Subject: Review Request: JDK-8180717:  Upgrade the docs bundle index page
In-Reply-To: <5376BFBA-EFB8-4FE5-9DCE-1590957FFE29@oracle.com>
References: <5376BFBA-EFB8-4FE5-9DCE-1590957FFE29@oracle.com>
Message-ID: <591F8C03.2090200@oracle.com>

Look good to me.

-- Jon

On 05/19/2017 01:48 PM, Mandy Chung wrote:
> This patch updates the build tool to generate an improved presentation of the module groupings.  A sample page:
>     http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180717/docs/index.html
>
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180717/webrev.00/	
>
> Thanks
> Mandy



From jonathan.gibbons at oracle.com  Sat May 20 00:25:57 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 19 May 2017 17:25:57 -0700
Subject: RFR: JDK-8180651: Make target to run tests on exploded image
In-Reply-To: <ec6822ca-88e6-e0cf-f358-b57c635625b7@oracle.com>
References: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
 <0a0507d7-3f02-377c-9b8b-94d4e8e52b10@oracle.com>
 <aa3109cc-2156-9e1a-9170-e3462df0d863@oracle.com>
 <ec6822ca-88e6-e0cf-f358-b57c635625b7@oracle.com>
Message-ID: <591F8D15.7040005@oracle.com>

"exploded" as an adjective applies well enough to "image" but not to the 
imperative "run-test".

At the risk of a long name, can you move exploded to the end, with 
something like
     run-test-exploded-image

-- Jon

On 05/19/2017 08:36 AM, Robbin Ehn wrote:
> Hi,
>
> On 05/19/2017 12:55 PM, Erik Joelsson wrote:
>> Sure we can pause this. Robbin has a local patch to play with for now.
>
> Yes, no rush for me.
>
>>
>> If you want another name, then we should also rename exploded-image. 
>> As I understand it, the name exploded is well established. It refers 
>> to the java class files/resources not being in jars/jimage format, 
>> but exploded as separate files in a directory structure.
>
> I would prefer to keep the name exploded for these reasons.
>
> /Robbin
>
>>
>> /Erik
>>
>>
>> On 2017-05-19 11:45, Magnus Ihse Bursie wrote:
>>> I like the idea, the changes in itself look good, but I really 
>>> *really* do not like the name "exploded". It was not good before as 
>>> in "exploded-image", but this is even worse. :-(
>>>
>>> Can we pause this one for just a while and try really hard to come 
>>> up with a better name? If we fail to do that in a couple of days, 
>>> I'll admit defeat and accept the patch as it is. OK?
>>>
>>> What about "local" image? "simple"? "quick"? "bare"?
>>>
>>> /Magnus
>>>
>>> On 2017-05-19 11:26, Erik Joelsson wrote:
>>>> In most cases, when running regression tests, you want to run them 
>>>> on the jdk image because that's the correct image and some tests 
>>>> will not work on other variants. However, many tests can be run 
>>>> successfully on the exploded image and since building the full jdk 
>>>> image takes quite a bit of extra time, especially when running a 
>>>> slowdebug build, enabling this as an option can significantly 
>>>> improve developer efficiency.
>>>>
>>>> I therefor propose the new target "exploded-run-test". It will work 
>>>> just like run-test but it depends on and runs on the exploded image.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180651
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8180651/webrev.01/
>>>>
>>>> /Erik
>>>>
>>>
>>



From erik.joelsson at oracle.com  Mon May 22 07:33:54 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 22 May 2017 09:33:54 +0200
Subject: RFR: JDK-8180651: Make target to run tests on exploded image
In-Reply-To: <591F8D15.7040005@oracle.com>
References: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
 <0a0507d7-3f02-377c-9b8b-94d4e8e52b10@oracle.com>
 <aa3109cc-2156-9e1a-9170-e3462df0d863@oracle.com>
 <ec6822ca-88e6-e0cf-f358-b57c635625b7@oracle.com>
 <591F8D15.7040005@oracle.com>
Message-ID: <0c9c67b6-43f1-06eb-bc1f-10e82fd77480@oracle.com>

Hello,

That works for me.

The drawback is that run-test already has a big set of automatic 
suffixes for different tests to run. By using a prefix, those are more 
easily separated during tab completion. On the other hand, this 
suggestion makes it very clear what is being asked for, which is good.

/Erik


On 2017-05-20 02:25, Jonathan Gibbons wrote:
> "exploded" as an adjective applies well enough to "image" but not to 
> the imperative "run-test".
>
> At the risk of a long name, can you move exploded to the end, with 
> something like
>     run-test-exploded-image
>
> -- Jon
>
> On 05/19/2017 08:36 AM, Robbin Ehn wrote:
>> Hi,
>>
>> On 05/19/2017 12:55 PM, Erik Joelsson wrote:
>>> Sure we can pause this. Robbin has a local patch to play with for now.
>>
>> Yes, no rush for me.
>>
>>>
>>> If you want another name, then we should also rename exploded-image. 
>>> As I understand it, the name exploded is well established. It refers 
>>> to the java class files/resources not being in jars/jimage format, 
>>> but exploded as separate files in a directory structure.
>>
>> I would prefer to keep the name exploded for these reasons.
>>
>> /Robbin
>>
>>>
>>> /Erik
>>>
>>>
>>> On 2017-05-19 11:45, Magnus Ihse Bursie wrote:
>>>> I like the idea, the changes in itself look good, but I really 
>>>> *really* do not like the name "exploded". It was not good before as 
>>>> in "exploded-image", but this is even worse. :-(
>>>>
>>>> Can we pause this one for just a while and try really hard to come 
>>>> up with a better name? If we fail to do that in a couple of days, 
>>>> I'll admit defeat and accept the patch as it is. OK?
>>>>
>>>> What about "local" image? "simple"? "quick"? "bare"?
>>>>
>>>> /Magnus
>>>>
>>>> On 2017-05-19 11:26, Erik Joelsson wrote:
>>>>> In most cases, when running regression tests, you want to run them 
>>>>> on the jdk image because that's the correct image and some tests 
>>>>> will not work on other variants. However, many tests can be run 
>>>>> successfully on the exploded image and since building the full jdk 
>>>>> image takes quite a bit of extra time, especially when running a 
>>>>> slowdebug build, enabling this as an option can significantly 
>>>>> improve developer efficiency.
>>>>>
>>>>> I therefor propose the new target "exploded-run-test". It will 
>>>>> work just like run-test but it depends on and runs on the exploded 
>>>>> image.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180651
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8180651/webrev.01/
>>>>>
>>>>> /Erik
>>>>>
>>>>
>>>
>



From magnus.ihse.bursie at oracle.com  Mon May 22 07:50:30 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 22 May 2017 09:50:30 +0200
Subject: RFR: JDK-8180480 Use "requires transitive" relationship when
 determining modules for javadoc
In-Reply-To: <52FEC3AF-1084-4146-A460-377357B12E38@oracle.com>
References: <c8194e57-8f1c-5ccd-4873-f1b21e14a4b8@oracle.com>
 <BE441833-AF38-468A-BBEA-622E80C3A95C@oracle.com>
 <e9b8c2ac-60a6-4aad-0d85-3cb69e525d9a@oracle.com>
 <52FEC3AF-1084-4146-A460-377357B12E38@oracle.com>
Message-ID: <3c87c3f4-0fd0-4af8-a5a9-1dea391e0e9c@oracle.com>

On 2017-05-19 16:47, Mandy Chung wrote:
>> On May 19, 2017, at 1:08 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>>
>> "Indirect exports" was a good term. I dropped the "Deps" part of the name and it all became much clearer.
>>
>> Here's an updated webrev:
>> http://cr.openjdk.java.net/~ihse/JDK-8180480-docs-should-use-requires-transitive/webrev.02
>>
> +  $1_INDIRECT_EXPORTS := $$(call FindTransitiveIndirectExportsForModules, $$($1_MODULES))
>
> Nit: ?exported? term is for API but not for dependency.
>
> s/$1_INDIRECT_EXPORTS/$1_TRANSITIVE_MODULES
> s/FindTransitiveIndirectExportsForModules/FindTransitiveIndirectDepsForModules
>
> Otherwise, looks good.  No need for a new webrev:

Well, but that's not really just a "nit", is it? The problem here was 
that "transitive deps" had been used in the names of our macros in a 
different way than "requires transitive" from module-info.java implies, 
and now we're just back in that confusion anyway.

Oh well. I'll settle for those names (but under some protest!) for jdk 
9, and then we'll have to make sure we get a better naming scheme that 
aligns all the way for jdk 10.

/Magnus

>
> Mandy



From magnus.ihse.bursie at oracle.com  Mon May 22 07:53:23 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 22 May 2017 09:53:23 +0200
Subject: RFR: JDK-8180651: Make target to run tests on exploded image
In-Reply-To: <0c9c67b6-43f1-06eb-bc1f-10e82fd77480@oracle.com>
References: <b361d366-d7db-2da4-1e3c-96902fc316f4@oracle.com>
 <0a0507d7-3f02-377c-9b8b-94d4e8e52b10@oracle.com>
 <aa3109cc-2156-9e1a-9170-e3462df0d863@oracle.com>
 <ec6822ca-88e6-e0cf-f358-b57c635625b7@oracle.com>
 <591F8D15.7040005@oracle.com>
 <0c9c67b6-43f1-06eb-bc1f-10e82fd77480@oracle.com>
Message-ID: <af9ab948-44b9-b304-03c6-273a9964eb87@oracle.com>


On 2017-05-22 09:33, Erik Joelsson wrote:
> Hello,
>
> That works for me.
>
> The drawback is that run-test already has a big set of automatic 
> suffixes for different tests to run. By using a prefix, those are more 
> easily separated during tab completion.

I agree, prefix is better. Go with your original patch, it's fine.

I still think the "exploded image" sounds weird (somewhat like calling 
source files "uncompiled binaries"), but apparently I'm alone with that 
so I'll just have to learn and live with it. ;-)

/Magnus


> On the other hand, this suggestion makes it very clear what is being 
> asked for, which is good.
>
> /Erik
>
>
> On 2017-05-20 02:25, Jonathan Gibbons wrote:
>> "exploded" as an adjective applies well enough to "image" but not to 
>> the imperative "run-test".
>>
>> At the risk of a long name, can you move exploded to the end, with 
>> something like
>>     run-test-exploded-image
>>
>> -- Jon
>>
>> On 05/19/2017 08:36 AM, Robbin Ehn wrote:
>>> Hi,
>>>
>>> On 05/19/2017 12:55 PM, Erik Joelsson wrote:
>>>> Sure we can pause this. Robbin has a local patch to play with for now.
>>>
>>> Yes, no rush for me.
>>>
>>>>
>>>> If you want another name, then we should also rename 
>>>> exploded-image. As I understand it, the name exploded is well 
>>>> established. It refers to the java class files/resources not being 
>>>> in jars/jimage format, but exploded as separate files in a 
>>>> directory structure.
>>>
>>> I would prefer to keep the name exploded for these reasons.
>>>
>>> /Robbin
>>>
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-05-19 11:45, Magnus Ihse Bursie wrote:
>>>>> I like the idea, the changes in itself look good, but I really 
>>>>> *really* do not like the name "exploded". It was not good before 
>>>>> as in "exploded-image", but this is even worse. :-(
>>>>>
>>>>> Can we pause this one for just a while and try really hard to come 
>>>>> up with a better name? If we fail to do that in a couple of days, 
>>>>> I'll admit defeat and accept the patch as it is. OK?
>>>>>
>>>>> What about "local" image? "simple"? "quick"? "bare"?
>>>>>
>>>>> /Magnus
>>>>>
>>>>> On 2017-05-19 11:26, Erik Joelsson wrote:
>>>>>> In most cases, when running regression tests, you want to run 
>>>>>> them on the jdk image because that's the correct image and some 
>>>>>> tests will not work on other variants. However, many tests can be 
>>>>>> run successfully on the exploded image and since building the 
>>>>>> full jdk image takes quite a bit of extra time, especially when 
>>>>>> running a slowdebug build, enabling this as an option can 
>>>>>> significantly improve developer efficiency.
>>>>>>
>>>>>> I therefor propose the new target "exploded-run-test". It will 
>>>>>> work just like run-test but it depends on and runs on the 
>>>>>> exploded image.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180651
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8180651/webrev.01/
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>
>>>>
>>
>



From magnus.ihse.bursie at oracle.com  Mon May 22 08:02:37 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 22 May 2017 10:02:37 +0200
Subject: Review Request: JDK-8180717: Upgrade the docs bundle index page
In-Reply-To: <5376BFBA-EFB8-4FE5-9DCE-1590957FFE29@oracle.com>
References: <5376BFBA-EFB8-4FE5-9DCE-1590957FFE29@oracle.com>
Message-ID: <41c5044c-9abf-c716-8dea-b52c3f22e373@oracle.com>

On 2017-05-19 22:48, Mandy Chung wrote:
> This patch updates the build tool to generate an improved presentation of the module groupings.  A sample page:
>     http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180717/docs/index.html
>
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180717/webrev.00/	
>
> Thanks
> Mandy

This does not really affect the build system, so if you want to push 
this, go ahead. However, I do have some opinions:

1) You are re-adding a lot of css rules. This will make it harder to 
align this page with an common overall look-and-feel using the shared 
css file.

2) I don't want to sound harsh, but, but is this really an improvement? 
I find this page almost as bad as the old "brick wall". :-( It's 
incomprehensible until you read the small print legend at the bottom.

Also, one of the first things I learned in my human-computer interaction 
classes was to *never* use color as the single discriminating feature. A 
large minority of the population is color-blind and cannot tell the 
difference between e.g. red and green, and it's especielly hard if it's 
like those low saturation colors that you've picked.

/Magnus


From magnus.ihse.bursie at oracle.com  Mon May 22 08:12:22 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 22 May 2017 10:12:22 +0200
Subject: RFR: JDK-8175824 Adapt javadoc generation to different
 requirements for JDK and JavaSE
In-Reply-To: <3c199017-f282-f309-161c-8789bc81c2eb@oracle.com>
References: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>
 <3c199017-f282-f309-161c-8789bc81c2eb@oracle.com>
Message-ID: <e680b392-f09b-0ec5-13c6-876668d62095@oracle.com>

On 2017-05-19 13:10, Erik Joelsson wrote:
> Looks good.
>
> Minor nit. There are variables named JavaSE_MODULES as well as 
> JAVASE_MODULES which can be a bit confusing. Perhaps the latter can be 
> inlined at this point? Or the first should perhaps be called 
> JavaSE_GROUP_MODULES?
I agree, that was confusing. I inlined it instead.

/Magnus

>
> /Erik
>
>
> On 2017-05-19 11:28, Magnus Ihse Bursie wrote:
>> javadoc allows a file to be specified to provide content for the top 
>> level "overview" page.
>>
>> As we move towards a unified docs bundle, we need to be able to vary 
>> the content of that file depending on the content of the bundle. This 
>> does not mean providing or including lists of modules, but should 
>> reflect whether the bundle contains Java SE modules, JDK modules and 
>> JavaFX modules.
>>
>> This patch also includes support for (and relies on) the new usage of 
>> the -group option from JDK-8180336.
>>
>> Note that when JDK-8180480 (Use "requires transitive" relationship 
>> when determining modules for javadoc) is pushed, the call to 
>> FindTransitiveDepsForModules for JavaSE_MODULES should be updated to 
>> the new FindTransitiveIndirectExportsForModules (or whatever it'll 
>> end up being called). I'll fix that in whichever of the two bugs I 
>> push last.
>>
>> This patch also contains some accumulated cleanup in Docs.gmk after 
>> all the piecemeal patches this file has recieved for the last few weeks.
>>
>> Note: While I'm willing to make minor changes to the actual contents 
>> of the generated overview.html, I'd prefer if any larger (or 
>> potentially controversial) issues are handled as separate follow-up 
>> bugs. With this framework in place, it's easy to modify whatever gets 
>> written to the file.
>>
>> An example how this looks like for the JDK and Java SE documentation 
>> collections (stripped down to the summary page of the javadoc output, 
>> and the JDK top-level index.html) is here:
>> http://cr.openjdk.java.net/~ihse/demo-generated-overview/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175824
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.01
>>
>



From magnus.ihse.bursie at oracle.com  Mon May 22 08:31:38 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 22 May 2017 10:31:38 +0200
Subject: RFR: JDK-8175824 Adapt javadoc generation to different
 requirements for JDK and JavaSE
In-Reply-To: <BE689606-C778-4A22-A83E-EF5D9DFE339F@oracle.com>
References: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>
 <BE689606-C778-4A22-A83E-EF5D9DFE339F@oracle.com>
Message-ID: <d2a9fe16-0b60-2116-227c-c617cebcd160@oracle.com>


On 2017-05-19 17:09, Mandy Chung wrote:
> Magnus,
>
> Iris and Kevin provides the description for each group.  The overview page
> can look like this:
>
> This document is the Java? Platform, Standard Edition Development Kit (JDK?) 9  API Specification.
>
> Java SE
>          The Java Platform, Standard Edition (?Java SE?) APIs define
> 	the core Java platform for general-purpose computing. These APIs
> 	are in modules with names starting with the string ?java.?.
>
> JDK
> 	The Java Development Kit (?JDK?) APIs define an implementation
> 	of the Java SE Platform which may include platform-specific details.
> 	These APIs are in modules with names starting with the string ?jdk.?.
>
> JavaFX
> 	The JavaFX APIs define a set of user interface (UI) controls,
> 	graphics, media, and web packages for developing rich client
> 	applications. These APIs are in modules with names starting with
> 	the string "javafx.?.
>
> Java SE, JDK, JavaFX links to the corresponding table.

Updated version:

http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.02

/Magnus
>
> Mandy
>
>> On May 19, 2017, at 2:28 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> javadoc allows a file to be specified to provide content for the top level "overview" page.
>>
>> As we move towards a unified docs bundle, we need to be able to vary the content of that file depending on the content of the bundle. This does not mean providing or including lists of modules, but should reflect whether the bundle contains Java SE modules, JDK modules and JavaFX modules.
>>
>> This patch also includes support for (and relies on) the new usage of the -group option from JDK-8180336.
>>
>> Note that when JDK-8180480 (Use "requires transitive" relationship when determining modules for javadoc) is pushed, the call to FindTransitiveDepsForModules for JavaSE_MODULES should be updated to the new FindTransitiveIndirectExportsForModules (or whatever it'll end up being called). I'll fix that in whichever of the two bugs I push last.
>>
>> This patch also contains some accumulated cleanup in Docs.gmk after all the piecemeal patches this file has recieved for the last few weeks.
>>
>> Note: While I'm willing to make minor changes to the actual contents of the generated overview.html, I'd prefer if any larger (or potentially controversial) issues are handled as separate follow-up bugs. With this framework in place, it's easy to modify whatever gets written to the file.
>>
>> An example how this looks like for the JDK and Java SE documentation collections (stripped down to the summary page of the javadoc output, and the JDK top-level index.html) is here:
>> http://cr.openjdk.java.net/~ihse/demo-generated-overview/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175824
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.01
>>



From erik.joelsson at oracle.com  Mon May 22 12:06:33 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 22 May 2017 14:06:33 +0200
Subject: RFR: JDK-8175824 Adapt javadoc generation to different
 requirements for JDK and JavaSE
In-Reply-To: <d2a9fe16-0b60-2116-227c-c617cebcd160@oracle.com>
References: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>
 <BE689606-C778-4A22-A83E-EF5D9DFE339F@oracle.com>
 <d2a9fe16-0b60-2116-227c-c617cebcd160@oracle.com>
Message-ID: <c627de16-e8b0-5427-af44-f231a3105943@oracle.com>

Looks good to me.

/Erik


On 2017-05-22 10:31, Magnus Ihse Bursie wrote:
>
> On 2017-05-19 17:09, Mandy Chung wrote:
>> Magnus,
>>
>> Iris and Kevin provides the description for each group.  The overview 
>> page
>> can look like this:
>>
>> This document is the Java? Platform, Standard Edition Development Kit 
>> (JDK?) 9  API Specification.
>>
>> Java SE
>>          The Java Platform, Standard Edition (?Java SE?) APIs define
>>     the core Java platform for general-purpose computing. These APIs
>>     are in modules with names starting with the string ?java.?.
>>
>> JDK
>>     The Java Development Kit (?JDK?) APIs define an implementation
>>     of the Java SE Platform which may include platform-specific details.
>>     These APIs are in modules with names starting with the string 
>> ?jdk.?.
>>
>> JavaFX
>>     The JavaFX APIs define a set of user interface (UI) controls,
>>     graphics, media, and web packages for developing rich client
>>     applications. These APIs are in modules with names starting with
>>     the string "javafx.?.
>>
>> Java SE, JDK, JavaFX links to the corresponding table.
>
> Updated version:
>
> http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.02 
>
>
> /Magnus
>>
>> Mandy
>>
>>> On May 19, 2017, at 2:28 AM, Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> javadoc allows a file to be specified to provide content for the top 
>>> level "overview" page.
>>>
>>> As we move towards a unified docs bundle, we need to be able to vary 
>>> the content of that file depending on the content of the bundle. 
>>> This does not mean providing or including lists of modules, but 
>>> should reflect whether the bundle contains Java SE modules, JDK 
>>> modules and JavaFX modules.
>>>
>>> This patch also includes support for (and relies on) the new usage 
>>> of the -group option from JDK-8180336.
>>>
>>> Note that when JDK-8180480 (Use "requires transitive" relationship 
>>> when determining modules for javadoc) is pushed, the call to 
>>> FindTransitiveDepsForModules for JavaSE_MODULES should be updated to 
>>> the new FindTransitiveIndirectExportsForModules (or whatever it'll 
>>> end up being called). I'll fix that in whichever of the two bugs I 
>>> push last.
>>>
>>> This patch also contains some accumulated cleanup in Docs.gmk after 
>>> all the piecemeal patches this file has recieved for the last few 
>>> weeks.
>>>
>>> Note: While I'm willing to make minor changes to the actual contents 
>>> of the generated overview.html, I'd prefer if any larger (or 
>>> potentially controversial) issues are handled as separate follow-up 
>>> bugs. With this framework in place, it's easy to modify whatever 
>>> gets written to the file.
>>>
>>> An example how this looks like for the JDK and Java SE documentation 
>>> collections (stripped down to the summary page of the javadoc 
>>> output, and the JDK top-level index.html) is here:
>>> http://cr.openjdk.java.net/~ihse/demo-generated-overview/
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175824
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.01
>>>
>



From mandy.chung at oracle.com  Mon May 22 16:45:14 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 22 May 2017 09:45:14 -0700
Subject: RFR: JDK-8175824 Adapt javadoc generation to different
 requirements for JDK and JavaSE
In-Reply-To: <d2a9fe16-0b60-2116-227c-c617cebcd160@oracle.com>
References: <b85ad314-1a52-c689-beac-db9e6ca2b126@oracle.com>
 <BE689606-C778-4A22-A83E-EF5D9DFE339F@oracle.com>
 <d2a9fe16-0b60-2116-227c-c617cebcd160@oracle.com>
Message-ID: <CBAC6913-B3E3-4288-ADBB-26122ACACB57@oracle.com>


> On May 22, 2017, at 1:31 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> Updated version:
> 
> http://cr.openjdk.java.net/~ihse/JDK-8175824-javadoc-dynamic-overview-and-groups/webrev.02


 207       <p>This is a list of all modules included in the $$($1_FULL_NAME) API Specification.</p> \

I suggest to keep the original sentence:

  "This document is the API specification for $$($1_FULL_NAME)."

Otherwise looks good.

Do you have a generated page to check out?

Mandy

From mandy.chung at oracle.com  Mon May 22 17:16:07 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 22 May 2017 10:16:07 -0700
Subject: Review Request: JDK-8180717: Upgrade the docs bundle index page
In-Reply-To: <41c5044c-9abf-c716-8dea-b52c3f22e373@oracle.com>
References: <5376BFBA-EFB8-4FE5-9DCE-1590957FFE29@oracle.com>
 <41c5044c-9abf-c716-8dea-b52c3f22e373@oracle.com>
Message-ID: <054DB1BA-8F98-426B-863B-25B2A18584E8@oracle.com>


> On May 22, 2017, at 1:02 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2017-05-19 22:48, Mandy Chung wrote:
>> This patch updates the build tool to generate an improved presentation of the module groupings.  A sample page:
>>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180717/docs/index.html
>> 
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180717/webrev.00/	
>> 
>> Thanks
>> Mandy
> 
> This does not really affect the build system, so if you want to push this, go ahead. However, I do have some opinions:
> 
> 1) You are re-adding a lot of css rules. This will make it harder to align this page with an common overall look-and-feel using the shared css file.
> 

We should share the common overall L&F when it makes sense.  With this new presentation this may be better to keep the local css rules unless they are applicable to other documents.  This page will likely be tweaked and improved or redesigned by UE experts in the future.

> 2) I don't want to sound harsh, but, but is this really an improvement? I find this page almost as bad as the old "brick wall". :-( It's incomprehensible until you read the small print legend at the bottom.
> 
> Also, one of the first things I learned in my human-computer interaction classes was to *never* use color as the single discriminating feature. A large minority of the population is color-blind and cannot tell the difference between e.g. red and green, and it's especielly hard if it's like those low saturation colors that you've picked.

This page gives users an easy entrance to navigate to the appropriate documentation/modules.  The categorization into Java SE, JDK, etc is not the primary importance to most users of this page and so removing the separate columns would simplify the presentation.  Yes color-blind is one known concern.  This would need UE experts to help here.  Our primary goal is to replace the layer cake with a reasonable top-level page in JDK 9 and hand this to appropriate experts/designers to work on it.

Mandy

From prasanta.sadhukhan at oracle.com  Tue May 23 08:59:16 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 23 May 2017 14:29:16 +0530
Subject: [10] RFR JDK-6461834: Minimize WindowsLookAndFeel classes
 included with Unix JDKs
In-Reply-To: <21fb6605-e4d3-657c-766c-0a93cd15f721@oracle.com>
References: <641374b9-9f9f-edfa-1b8a-11d2798d241a@oracle.com>
 <d567b7b8-f4d1-f46c-0f37-ee7941c0e89f@oracle.com>
 <7471c39c-8d3e-b90b-bfc1-36f389c5c3c8@oracle.com>
 <8acad3b1-1e45-3c69-970b-d492d05790c3@oracle.com>
 <21fb6605-e4d3-657c-766c-0a93cd15f721@oracle.com>
Message-ID: <2f126747-6659-813a-f006-a6d5433912e2@oracle.com>

I got +1 from build. I need one more +1.

Any further comment/objection on this changeset? else Can I commit this?

Regards
Prasanta
On 5/18/2017 1:31 PM, Prasanta Sadhukhan wrote:
> So far I have looked, it seems jdk.jconsole uses this classes for 
> windows only. These classes are specified in
> JConsole.java where it checks (for non-windows, it will come as 
> GTKLookAndFeel)
>
> String systemLaF = UIManager.getSystemLookAndFeelClassName();
> if (systemLaF.equals("com.sun.java.swing.plaf.gtk.GTKLookAndFeel") ||
> systemLaF.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel")) {
>
> try {
> UIManager.setLookAndFeel(systemLaF); MaximizableInternalFrame.java 
> where it checks for this classes in windows only if (JConsole.IS_WIN) {
> try {
> Class<?> Part =
> Class.forName("com.sun.java.swing.plaf.windows.TMSchema$Part"); and 
> Utilities.java where it checks LookAndFeel laf = 
> UIManager.getLookAndFeel();
> boolean transparent = laf.getClass().getName().equals(windowsLaF);
>
> Modified webrev
> http://cr.openjdk.java.net/~psadhukhan/6461834/01/
>
> Regards
> Prasanta
>
> On 5/18/2017 12:36 AM, Phil Race wrote:
>> The way to do this is to create a file
>> src/java.desktop/windows/classes/module-info.java.extra
>>
>> and move the opens there.
>>
>> See for example
>> src/java.base/windows/classes/module-info.java.extra
>>
>> But are you sure jdk.jconsole needs these only on Windows ?
>> Better make sure of it.
>>
>> -phil.
>>
>> On 05/17/2017 03:49 AM, Prasanta Sadhukhan wrote:
>>> Yes, actually I am bit unsure of how to proceed with that. It is 
>>> meant to open internal java.desktop classes "only" to jdk.jconsole 
>>> but now afer this fix, these classes will only be available in 
>>> windows platform, so it should be a conditional "open" and I am not 
>>> sure if module-info.java allows conditional open.
>>>
>>> Regards
>>> Prasanta
>>> On 5/17/2017 4:16 PM, Magnus Ihse Bursie wrote:
>>>> Build changes looks good. However in 
>>>> src/java.desktop/share/classes/module-info.java you are trying to 
>>>> check in commented-out code instead of removing it.
>>>>
>>>> /Magnus
>>>>
>>>> On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for an issue whereby it is seen that 
>>>>> WindowsLookAndFeel classes are built for non-windows platform,
>>>>> where it is not needed.
>>>>> Proposed fix is to remove building these classes for non-windows 
>>>>> platform.
>>>>>
>>>>> JPRT build is successful. Also, fixed the regression tests which 
>>>>> expects this classes to be available in non-unix platform.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6461834
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6461834/00/
>>>>>
>>>>> There are some closed regression test which will be taken care 
>>>>> after this in a separate crucible review.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>
>>>
>>
>



From david.holmes at oracle.com  Tue May 23 23:44:26 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 May 2017 09:44:26 +1000
Subject: Missing separator on macro call ?
Message-ID: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>

I just sync'd my local project with jdk10/hs and am getting a strange 
build error:

Building targets 'images test-image' in configuration 'linux-x64-debug'
lib/CompileJvm.gmk:207: *** missing separator.  Stop.

Line 207 is:

$(eval $(call SetupNativeCompilation, BUILD_LIBJVM, \

so it can't in itself have a missing separator!

I don't know how to try and debug this - any suggestions?

Thanks,
David


From erik.joelsson at oracle.com  Wed May 24 06:44:19 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 24 May 2017 08:44:19 +0200
Subject: Missing separator on macro call ?
In-Reply-To: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
References: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
Message-ID: <64efe20b-fab6-f384-88a5-b5efc1f57bcc@oracle.com>

Hello David,

That error means something goes wrong when evaluating the macro body. 
Unfortunately make will not give you any better message than that. If 
you didn't change anything in make/common/NativeCompilation.gmk, the 
most likely cause is that you have changed a variable that is used in 
there, or in one of the parameters in that call, and that variable now 
has some character in it that gets misinterpreted, typically a comma or 
dollar would be the culprits.

/Erik


On 2017-05-24 01:44, David Holmes wrote:
> I just sync'd my local project with jdk10/hs and am getting a strange 
> build error:
>
> Building targets 'images test-image' in configuration 'linux-x64-debug'
> lib/CompileJvm.gmk:207: *** missing separator.  Stop.
>
> Line 207 is:
>
> $(eval $(call SetupNativeCompilation, BUILD_LIBJVM, \
>
> so it can't in itself have a missing separator!
>
> I don't know how to try and debug this - any suggestions?
>
> Thanks,
> David



From david.holmes at oracle.com  Wed May 24 06:44:15 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 May 2017 16:44:15 +1000
Subject: Missing separator on macro call ?
In-Reply-To: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
References: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
Message-ID: <9f54a632-f996-02a7-2f8f-702e02676914@oracle.com>

It was suggested (thanks Gary A.) to check the debug, or trace logging. 
This revealed:

  [27] PRECOMPILED_HEADER := 
/scratch/dh/valhalla/jdk10/hotspot/src/share/vm/precompiled/precompiled.hpp 

  [28] PRECOMPILED_HEADER_EXCLUDE :=
lib/CompileJvm.gmk:207: Running shell command
+ /usr/bin/find <long list of directories> '(' -type f -o -type l ')'
make[3]: Leaving directory '/export/users/dh/valhalla/jdk10/hotspot/make'
lib/CompileJvm.gmk:207: *** missing separator.  Stop.

I can manually run that command without error, but I'm wondering if I am 
hitting some kind of length limit ??

Thanks,
David

On 24/05/2017 9:44 AM, David Holmes wrote:
> I just sync'd my local project with jdk10/hs and am getting a strange 
> build error:
> 
> Building targets 'images test-image' in configuration 'linux-x64-debug'
> lib/CompileJvm.gmk:207: *** missing separator.  Stop.
> 
> Line 207 is:
> 
> $(eval $(call SetupNativeCompilation, BUILD_LIBJVM, \
> 
> so it can't in itself have a missing separator!
> 
> I don't know how to try and debug this - any suggestions?
> 
> Thanks,
> David


From david.holmes at oracle.com  Wed May 24 06:49:36 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 May 2017 16:49:36 +1000
Subject: Missing separator on macro call ?
In-Reply-To: <64efe20b-fab6-f384-88a5-b5efc1f57bcc@oracle.com>
References: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
 <64efe20b-fab6-f384-88a5-b5efc1f57bcc@oracle.com>
Message-ID: <db93530d-6c9d-37db-a4e0-27983322af40@oracle.com>

On 24/05/2017 4:44 PM, Erik Joelsson wrote:
> Hello David,
> 
> That error means something goes wrong when evaluating the macro body. 
> Unfortunately make will not give you any better message than that. If 
> you didn't change anything in make/common/NativeCompilation.gmk, the 
> most likely cause is that you have changed a variable that is used in 
> there, or in one of the parameters in that call, and that variable now 
> has some character in it that gets misinterpreted, typically a comma or 
> dollar would be the culprits.

Or a # :(

Thanks Erik. Offlist Christine F. suggested I look for editor temp files 
but I didn't find any. But by using the trace output and running the 
find command - there it was: .#constantPool.cpp

Wow! What an insane waste of time. :(

David

> /Erik
> 
> 
> On 2017-05-24 01:44, David Holmes wrote:
>> I just sync'd my local project with jdk10/hs and am getting a strange 
>> build error:
>>
>> Building targets 'images test-image' in configuration 'linux-x64-debug'
>> lib/CompileJvm.gmk:207: *** missing separator.  Stop.
>>
>> Line 207 is:
>>
>> $(eval $(call SetupNativeCompilation, BUILD_LIBJVM, \
>>
>> so it can't in itself have a missing separator!
>>
>> I don't know how to try and debug this - any suggestions?
>>
>> Thanks,
>> David
> 


From daniel.daugherty at oracle.com  Thu May 25 16:48:54 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 25 May 2017 10:48:54 -0600
Subject: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and
 Parker code for POSIX systems
In-Reply-To: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
References: <3401d786-e657-35b4-cb0f-70848f5215b4@oracle.com>
Message-ID: <d944b05d-f44f-1520-a58e-37d64130bce5@oracle.com>

On 5/18/17 12:25 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
>
> webrevs:
>
> Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/

General comment(s):
   - Sometimes you've updated the copyright year for the file and
     sometimes you haven't. Please check before pushing.


common/autoconf/flags.m4
     No comments.

common/autoconf/generated-configure.sh
     No comments.


> hotspot: http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/

src/os/aix/vm/os_aix.cpp
     No comments; did not try to compare deleted code with os_posix.cpp.

src/os/aix/vm/os_aix.hpp
     No comments; did not try to compare deleted code with os_posix.hpp.

src/os/bsd/vm/os_bsd.cpp
     No comments; compared deleted code with os_posix.cpp version; nothing
     jumped out as wrong.

src/os/bsd/vm/os_bsd.hpp
     No comments; compared deleted code with os_posix.hpp version; nothing
     jumped out as wrong.

src/os/linux/vm/os_linux.cpp
     No comments; compared deleted code with os_posix.cpp version; nothing
     jumped out as wrong.

src/os/linux/vm/os_linux.hpp
     No comments; compared deleted code with os_posix.hpp version; nothing
     jumped out as wrong.

src/os/posix/vm/os_posix.cpp
     L1401: // Not currently usable by Solaris
     L1408: // time-of-day clock
         nit - needs period at end of the sentence

     L1433: // build time support then there can not be
         typo - "can not" -> "cannot"

     L1435: // int or int64_t.
         typo - needs a ')' before the period.

     L1446: // determine what POSIX API's are present and do appropriate
     L1447: // configuration
         nits - 'determine' -> 'Determine'
              - needs period at end of the sentence

     L1455:   // 1. Check for CLOCK_MONOTONIC support
         nit - needs period at end of the sentence

     L1462:   // we do dlopen's in this particular order due to bug in linux
     L1463:   // dynamical loader (see 6348968) leading to crash on exit
         nits - 'we' -> 'We'
              - needs period at end of the sentence

         typo - 'dynamical' -> 'dynamic'

     L1481:     // we assume that if both clock_gettime and clock_getres 
support
     L1482:     // CLOCK_MONOTONIC then the OS provides true high-res 
monotonic clock
         nits - 'we' -> 'We'
              - needs period at end of the sentence

     L1486:         clock_gettime_func(CLOCK_MONOTONIC, &tp) == 0) {
         nit - extra space before '=='

     L1487:       // yes, monotonic clock is supported
         nits - 'yes' -> 'Yes'
              - needs period at end of the sentence

     L1491:       // close librt if there is no monotonic clock
         nits - 'close' -> 'Close'
              - needs period at end of the sentence

     L1499:   // 2. Check for pthread_condattr_setclock support
     L1503:   // libpthread is already loaded
     L1511:   // Now do general initialization
         nit - needs period at end of the sentence

     L1591:   if (timeout < 0)
     L1592:     timeout = 0;
         nit - missing braces

     L1609:       // More seconds than we can add, so pin to max_secs
     L1658:         // More seconds than we can add, so pin to max_secs
         nit - needs period at end of the sentence

     L1643:         // Absolue seconds exceeds allow max, so pin to max_secs
         typo - 'Absolue' -> 'Absolute'
         nit - needs period at end of the sentence

src/os/posix/vm/os_posix.hpp
     L149:   ~PlatformEvent() { guarantee(0, "invariant"); }
     L185:   ~PlatformParker() { guarantee(0, "invariant"); }
         nit - '0' should be 'false' or just call fatal()

src/os/solaris/vm/os_solaris.cpp
     No comments.

src/os/solaris/vm/os_solaris.hpp
     No comments.


As Robbin said, this is very hard to review and be sure that everything
is relocated correctly. I tried to look at this code a couple of different
ways and nothing jumped out at me as wrong.

I did my usual crawl style review through posix.cpp and posix.hpp. I only
found nits and typos that you can chose to ignore since you're on a time
crunch here.

Thumbs up!

Dan



>
> First a big thank you to Thomas Stuefe for testing various versions of 
> this on AIX.
>
> This is primarily a refactoring and cleanup exercise (ie lots of 
> deleted duplicated code!).
>
> I have taken the PlatformEvent, PlatformParker and Parker::* code, out 
> of os_linux and moved it into os_posix for use by Linux, OSX, BSD, AIX 
> and perhaps one day Solaris (more on that later).
>
> The Linux code was the most functionally complete, dealing with 
> correct use of CLOCK_MONOTONIC for relative timed waits, and the 
> default wall-clock for absolute timed waits. That functionality is 
> not, unfortunately, supported by all our POSIX platforms so there are 
> some configure time build checks to set some #defines, and then some 
> dynamic lookup at runtime**. We allow for the runtime environment to 
> be less capable than the build environment, but not the other way 
> around (without build time support we don't know the runtime types 
> needed to make library calls).
>
> ** There is some duplication of dynamic lookup code on Linux but this 
> can be cleaned up in future work if we refactor the time/clock code 
> into os_posix as well.
>
> The cleanup covers a number of things:
> - removal of linux anachronisms that got "ported" into the other 
> platforms
>   - eg EINTR can not be returned from the wait methods
> - removal of solaris anachronisms that got ported into the linux code 
> and then on to other platforms
>   - eg ETIMEDOUT is what we expect never ETIME
> - removal of the ancient/obsolete os::*::allowdebug_blocked_signals() 
> from the Parker methods
> - consolidation of unpackTime and compute_abstime into one utility 
> function
> - use statics for things completely private to the implementation 
> rather than making them part of the os* API (eg access to condAttr 
> objects)
> - cleanup up commentary and style within methods of the same class
> - clean up coding style in places eg not using Names that start with 
> capitals.
>
> I have not tried to cleanup every single oddity, nor tried to 
> reconcile differences between the very similar in places PlatformEvent 
> and Park methods. For example PlatformEvent still examines the 
> FilterSpuriousWakeups** flag, and Parker still ignores it.
>
> ** Perhaps a candidate for deprecation and future removal.
>
> There is one mini "enhancement" slipped in this. I now explicitly 
> initialize mutexes with a mutexAttr object with its type set to 
> PTHREAD_MUTEX_NORMAL, instead of relying on the definition of 
> PTHREAD_MUTEX_DEFAULT. On FreesBSD the default is not "normal" but 
> "error checking" and so is slow. On all other current platforms there 
> is no effective change.
>
> Finally, Solaris is excluded from all this (other than the debug 
> signal blocking cleanup) because it potentially supports three 
> different low-level sync subsystems: UI thr*, Pthread, and direct LWP 
> sync. Solaris cleanup would be a separate RFE.
>
> No doubt I've overlooked mentioning something that someone will spot. :)
>
> Thanks,
> David
>



From glaubitz at physik.fu-berlin.de  Sat May 27 12:28:04 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sat, 27 May 2017 14:28:04 +0200
Subject: [PATCH]: linux-sparc build fixes
Message-ID: <d6671b9e-0dbf-f7da-c73c-2e58497bbc7c@physik.fu-berlin.de>

Hello!

openjdk-9 currently fails to build from source on Debian/sparc64 [1].

One of the reasons it fails is because of a misnamed header filename:

In file included from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/memory/allocation.inline.hpp:28:0,
                 from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/utilities/array.hpp:29,
                 from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/memory/universe.hpp:29,
                 from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/code/oopRecorder.hpp:28,
                 from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/asm/codeBuffer.hpp:28,
                 from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/asm/assembler.hpp:28,
                 from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/asm/macroAssembler.hpp:28,
                 from /<<PKGBUILDDIR>>/src/hotspot/src/cpu/sparc/vm/nativeInst_sparc.hpp:28,
                 from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/code/nativeInst.hpp:30,
                 from ad_sparc.hpp:32,
                 from ad_sparc_misc.cpp:28:
/<<PKGBUILDDIR>>/src/hotspot/src/share/vm/runtime/atomic.hpp:126:31: fatal error: atomic_linux_sparc.hpp: No such file or directory
 #include OS_CPU_HEADER(atomic)

While fixing this, I also discovered some other problems with the build on Debian/sparc64.

I'm attaching a set of three patches which address all the issues I have discovered with
openjdk-9 on Debian/sparc64 so far. They should apply to all builds on 64-bit Linux SPARC.

Please note, this is my first attempt ever trying to get patches into OpenJDK, so I will
definitely need a little guidance. I have already asked in the #openjdk channel and after
signing the OCA and sending it in, I was told to post my patches here. So here they are :).

Let's hope I can get them into the proper shape for getting them merged.

All patches are:

Signed-off by: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>

Thanks,
Adrian

> [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=sparc64&ver=9%7Eb170-2&stamp=1495173966&raw=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-missing-thread-parameter.patch
Type: text/x-patch
Size: 1133 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20170527/4832b843/0001-Add-missing-thread-parameter.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-missing-logging-log-hpp-include.patch
Type: text/x-patch
Size: 701 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20170527/4832b843/0002-Add-missing-logging-log-hpp-include.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Rename-atomic-linux-sparc-inline-hpp.patch
Type: text/x-patch
Size: 16071 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20170527/4832b843/0003-Rename-atomic-linux-sparc-inline-hpp.patch>

From sadhak001 at gmail.com  Sun May 28 23:15:37 2017
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Sun, 28 May 2017 23:15:37 +0000
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
Message-ID: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>

Hi,

While building OpenJDK8 on SmartOS (a fork of Sun Solaris), we came across
a number of anomalies and would like your help and support.

Here is the info from configure so you know a little bit more about the
platform we are talking about:

Running ./configure with  --with-boot-jdk=/opt/local/java/openjdk7
--enable-ccache --with-jvm-variants=server
--with-cacerts-file=/home/jenkins/workspace/openjdk_build_x86-64_smartOS/cacerts_area/security/cacerts
--with-alsa=/home/jenkins/workspace/openjdk_build_x86-64_smartOS/alsa-lib-1.0.27.2
--with-freetype=/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/installedfreetype
--with-x=/usr/include/X11 --with-debug-level=release
--x-includes=/opt/local/include --x-libraries=/opt/local/lib
--with-cups=/opt/local/ --with-cups-include=/opt/local/include
Running generated-configure.sh
configure: Configuration created at Sat May 27 23:30:44 UTC 2017.
configure: configure script generated at timestamp 1468207795.
checking for basename... /opt/local/bin//basename
checking for bash... /usr/bin/bash
checking for cat... /opt/local/bin//cat
checking for chmod... /opt/local/bin//chmod
checking for cmp... /opt/local/bin//cmp
checking for comm... /opt/local/bin//comm
checking for cp... /opt/local/bin//cp
checking for cpio... /usr/bin/cpio
checking for cut... /opt/local/bin//cut
checking for date... /opt/local/bin//date
checking for gdiff... /opt/local/bin//gdiff
checking for dirname... /opt/local/bin//dirname
checking for echo... /opt/local/bin//echo
checking for expr... /opt/local/bin//expr
checking for file... /usr/bin/file
checking for find... /opt/local/bin//find
checking for head... /opt/local/bin//head
checking for ln... /opt/local/bin//ln
checking for ls... /opt/local/bin//ls
checking for mkdir... /opt/local/bin//mkdir
checking for mktemp... /opt/local/bin//mktemp
checking for mv... /opt/local/bin//mv
checking for printf... /opt/local/bin//printf
checking for rm... /opt/local/bin//rm
checking for sh... /usr/bin/sh
checking for sort... /opt/local/bin//sort
checking for tail... /opt/local/bin//tail
checking for tar... /opt/local/bin//tar
checking for tee... /opt/local/bin//tee
checking for touch... /opt/local/bin//touch
checking for tr... /opt/local/bin//tr
checking for uname... /opt/local/bin//uname
checking for uniq... /opt/local/bin//uniq
checking for wc... /opt/local/bin//wc
checking for which... /usr/bin/which
checking for xargs... /opt/local/bin//xargs
checking for gawk... gawk
checking for grep that handles long lines and -e... /opt/local/bin//grep
checking for egrep... /opt/local/bin//grep -E
checking for fgrep... /opt/local/bin//grep -F
checking for a sed that does not truncate output... /opt/local/bin//sed
checking for nawk... /opt/local/bin//nawk
checking for cygpath... no
checking for readlink... /opt/local/bin//readlink
checking for df... /opt/local/bin//df
checking for SetFile... no
checking build system type... x86_64-pc-solaris2.11
checking host system type... x86_64-pc-solaris2.11
checking target system type... x86_64-pc-solaris2.11
checking openjdk-build os-cpu... solaris-x86_64
checking openjdk-target os-cpu... solaris-x86_64
checking compilation type... native
checking for presence of closed sources... no
checking if closed source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which interpreter of the JVM to build... template
checking which variants of the JVM to build... server
checking which debug level to use... release
checking what configuration name to use... solaris-x86_64-normal-server-release
checking for apt-get... no
checking for yum... no
checking for port... no
checking for pkgutil... no
checking for pkgadd... no
checking for gmake... /opt/local/bin//gmake
configure: Testing potential make at /opt/local/bin//gmake, found
using gmake in PATH
configure: Resolving FOUND_MAKE (as /opt/local/bin//gmake) failed,
using /opt/local/bin//gmake directly.
configure: Using GNU make 3.81 (or later) at /opt/local/bin//gmake
(version: GNU Make 4.1)
checking if find supports -delete... yes
checking for unzip... /opt/local/bin//unzip
checking for zip... /opt/local/bin//zip
checking for ldd... /usr/bin/ldd
checking for readelf... /opt/local/bin//readelf
checking for hg... /opt/local/bin//hg
checking for stat... /opt/local/bin//stat
checking for time... /usr/bin/time
checking for pkg-config... /opt/local/bin//pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for 7z... no
checking for unzip... unzip
checking for wget... wget
checking headful support... include support for both headful and headless
configure: Found potential Boot JDK using configure arguments
checking for Boot JDK... /opt/local/java/openjdk7
checking Boot JDK version... openjdk version "1.7.0-internal" OpenJDK
Runtime Environment (build 1.7.0-internal-pkgsrc_2015_02_22_06_07-b00)
OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
checking for java in Boot JDK... ok
checking for javac in Boot JDK... ok
checking for javah in Boot JDK... ok
checking for javap in Boot JDK... ok
checking for jar in Boot JDK... ok
checking for rmic in Boot JDK... ok
checking for native2ascii in Boot JDK... ok
checking if Boot JDK is 32 or 64 bits... 64
checking flags for boot jdk java command ...
checking flags for boot jdk java command for big workloads...  -Xms64M
-Xmx1600M -XX:ThreadStackSize=1536 -XX:PermSize=32m
-XX:MaxPermSize=160m
checking flags for boot jdk java command for small workloads...
-XX:+UseSerialGC -Xms32M -Xmx512M
checking for jtreg... no
checking for cc...
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/bin/cc
configure: Resolving CC (as
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/bin/cc)
failed, using /root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/bin/cc
directly.
checking resolved symbolic links for CC...
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc
checking if CC is disguised ccache... no, keeping CC
configure: Using Sun Studio C compiler version 5.12 (located at
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc)
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc
accepts -g... yes
checking for /root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc
option to accept ISO C89... none needed
checking for CC...
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/bin/CC
configure: Resolving CXX (as
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/bin/CC)
failed, using /root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/bin/CC
directly.
checking resolved symbolic links for CXX...
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/CC
checking if CXX is disguised ccache... no, keeping CXX
configure: Using Sun Studio C++ compiler version 5.12 (located at
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/CC)
checking whether we are using the GNU C++ compiler... no
checking whether
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/CC
accepts -g... yes
checking for ar... ar
configure: Rewriting AR to "/opt/local/bin//ar"
checking how to run the C preprocessor...
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc
-E
configure: Resolving CPP (as
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc)
failed, using /root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc
directly.
checking how to run the C++ preprocessor...
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/CC
-E
configure: Resolving CXXCPP (as
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/CC)
failed, using /root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/CC
directly.
checking for as... /opt/local/bin//as
configure: Resolving AS (as /opt/local/bin//as) failed, using
/opt/local/bin//as directly.
checking for nm... /opt/local/bin//nm
configure: Resolving NM (as /opt/local/bin//nm) failed, using
/opt/local/bin//nm directly.
checking for gnm... /opt/local/bin//gnm
configure: Resolving GNM (as /opt/local/bin//gnm) failed, using
/opt/local/bin//gnm directly.
checking for strip... /opt/local/bin//strip
configure: Resolving STRIP (as /opt/local/bin//strip) failed, using
/opt/local/bin//strip directly.
checking for mcs... /usr/bin/mcs
configure: Resolving MCS (as /usr/bin/mcs) failed, using /usr/bin/mcs directly.
checking for gobjcopy... gobjcopy
configure: Rewriting OBJCOPY to "/opt/local/bin//gobjcopy"
checking for gobjdump... gobjdump
configure: Rewriting OBJDUMP to "/opt/local/bin//gobjdump"
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking size of int *... 8
checking for target address size... 64 bits
checking whether byte ordering is bigendian... no
checking if the C compiler supports "-m64"... yes
checking if the C++ compiler supports "-m64"... yes
checking if both compilers support "-m64"... yes
checking if the C compiler supports "-m64"... yes
checking if the C++ compiler supports "-m64"... yes
checking if both compilers support "-m64"... yes
checking if we should generate debug symbols... true
checking if we should zip debug-info files... yes
checking what is not needed on Solaris?... alsa pulse
checking for X... libraries /opt/local/lib, headers /opt/local/include
checking whether -R must be followed by a space... no
checking for gethostbyname... no
checking for gethostbyname in -lnsl... yes
checking for connect... no
checking for connect in -lsocket... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for X11/extensions/shape.h... yes
checking for X11/extensions/Xrender.h... yes
checking for X11/extensions/XTest.h... yes
checking for X11/Intrinsic.h... yes
configure: Found freetype include files at
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/installedfreetype/include
using --with-freetype
checking for freetype includes...
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/installedfreetype/include
checking for freetype libraries...
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/installedfreetype/lib
checking if we can compile and link with freetype... yes
checking if we should bundle freetype... yes
configure: WARNING: alsa not used, so --with-alsa is ignored
checking for main in -ljpeg... no
configure: Will use jpeg decoder bundled with the OpenJDK source
checking for which giflib to use... bundled
checking for compress in -lz... no
checking for which zlib to use... bundled
checking for cos in -lm... yes
checking for dlopen in -ldl... yes
checking if elliptic curve crypto implementation is present... yes
checking for number of cores... 32
checking for memory size... prtconf: devinfo facility not available
8192 MB
checking for appropriate number of jobs to run in parallel... 7
checking whether to use sjavac... no
checking for ccache... no
checking if build directory is on local disk... yes
configure: creating
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/config.status
config.status: creating
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/spec.gmk
config.status: creating
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/hotspot-spec.gmk
config.status: creating
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/bootcycle-spec.gmk
config.status: creating
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/compare.sh
config.status: creating
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/spec.sh
config.status: creating
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/Makefile
config.status: creating
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/config.h

====================================================
A new configuration has been successfully created in
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release
using configure arguments '--with-boot-jdk=/opt/local/java/openjdk7
--enable-ccache --with-jvm-variants=server
--with-cacerts-file=/home/jenkins/workspace/openjdk_build_x86-64_smartOS/cacerts_area/security/cacerts
--with-alsa=/home/jenkins/workspace/openjdk_build_x86-64_smartOS/alsa-lib-1.0.27.2
--with-freetype=/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/installedfreetype
--with-x=/usr/include/X11 --with-debug-level=release
--x-includes=/opt/local/include --x-libraries=/opt/local/lib
--with-cups=/opt/local/ --with-cups-include=/opt/local/include'.

Configuration summary:
* Debug level:    release
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:       openjdk version "1.7.0-internal" OpenJDK Runtime
Environment (build 1.7.0-internal-pkgsrc_2015_02_22_06_07-b00) OpenJDK
64-Bit Server VM (build 24.71-b01, mixed mode)  (at
/opt/local/java/openjdk7)
* C Compiler:     Sun Studio version 5.12 (at
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc)
* C++ Compiler:   Sun Studio version 5.12 (at
/root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/CC)

Build performance summary:
* Cores to use:   7
* Memory limit:   8192 MB
* ccache status:  not available for your system


Firstly we had to apply the below patch in order to overcome couple of
initial issues:

--- a/hotspot/make/solaris/makefiles/build_vm_def.sh
+++ b/hotspot/make/solaris/makefiles/build_vm_def.sh
@@ -1,6 +1,6 @@
 #!/bin/sh

-/usr/ccs/bin/nm -p $* \
+/opt/local/bin/nm -p $* \
     | awk '{
           if ($2 == "U") next
           if ($3 ~ /^__1c.*__vtbl_$/ || $3 ~ /^gHotSpotVM/) print "\t" $3 ";"
diff --git a/hotspot/make/solaris/makefiles/sparcWorks.make
b/hotspot/make/solaris/makefiles/sparcWorks.make
index cff57a2..a58428b 100644
--- a/hotspot/make/solaris/makefiles/sparcWorks.make
+++ b/hotspot/make/solaris/makefiles/sparcWorks.make
@@ -112,7 +112,7 @@ ARCHFLAG_OLD/sparcv9 = -xarch=v9
 ARCHFLAG_NEW/sparcv9 = -m64 -xarch=sparc
 ARCHFLAG_OLD/i486    =
 ARCHFLAG_NEW/i486    = -m32
-ARCHFLAG_OLD/amd64   = -xarch=amd64
+ARCHFLAG_OLD/amd64   = -march=amdfam10
 ARCHFLAG_NEW/amd64   = -m64

 # Select the ARCHFLAGs and other SS12 (5.9) options


We think that these values are hard-coded and there is no way (or at least
we couldn't find one) to pass the custom values via a configure
command-line option or environment variable.

And then finally after patching it manually, we landed with this issue:

Compiling /home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/hotspot/src/share/vm/runtime/vm_version.cpp
Linking vm...
ld: warning: symbol '__JvmOffsets' has differing types:
        (file JvmOffsets.o type=OBJT; file dtrace.o type=FUNC);
ld: warning: symbol 'CodeCache::_heap' has differing types:
        (file codeCache.o type=OBJT; file dtrace.o type=FUNC);
ld: warning: symbol 'BufferBlob::__vtbl' has differing types:
        (file codeBlob.o type=OBJT; file dtrace.o type=FUNC);
ld: warning: symbol 'Method::__vtbl' has differing types:
        (file dtrace.o type=FUNC; file method.o type=OBJT);
ld: warning: symbol 'nmethod::__vtbl' has differing types:
        (file dtrace.o type=FUNC; file nmethod.o type=OBJT);
ld: warning: symbol 'Universe::_collectedHeap' has differing types:
        (file dtrace.o type=FUNC; file universe.o type=OBJT);
BFD: libjvm.debuginfo: Not enough room for program headers, try linking with -N
/opt/local/bin//gobjcopy:libjvm.debuginfo[.note]: Bad value
BFD: libjvm.debuginfo: Not enough room for program headers, try linking with -N
/opt/local/bin//gobjcopy:libjvm.debuginfo: Bad value
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/hotspot/make/solaris/makefiles/vm.make:296:
recipe for target 'libjvm.so' failed
gmake[6]: *** [libjvm.so] Error 1
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/hotspot/make/solaris/makefiles/top.make:112:
recipe for target 'the_vm' failed
gmake[5]: *** [the_vm] Error 2
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/hotspot/make/solaris/Makefile:226:
recipe for target 'product' failed
gmake[4]: *** [product] Error 2
Makefile:230: recipe for target 'generic_build2' failed
gmake[3]: *** [generic_build2] Error 2
Makefile:177: recipe for target 'product' failed
gmake[2]: *** [product] Error 2
HotspotWrapper.gmk:44: recipe for target
'/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
failed
gmake[1]: *** [/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
Error 2
/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk//make/Main.gmk:108:
recipe for target 'hotspot-only' failed
make: *** [hotspot-only] Error 2


I see this has already been reported and resolved via
https://bugs.openjdk.java.net/browse/JDK-8033602, so how come we still get
this issue.

Any ideas or thoughts about the above?

Thanks.

Cheers,
Mani
-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com/>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2017:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*


From david.holmes at oracle.com  Mon May 29 02:40:42 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 May 2017 12:40:42 +1000
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
Message-ID: <e882e63e-5272-497f-047d-54fd1c6d6b61@oracle.com>

Hi Mani,

I've dropped build-infra-dev as it is no longer actively used (it was 
for the new build system a couple of years ago).

Not sure about relevance to adoption-discuss ??

On 29/05/2017 9:15 AM, Mani Sarkar wrote:
> Hi,
> 
> While building OpenJDK8 on SmartOS (a fork of Sun Solaris), we came across
> a number of anomalies and would like your help and support.

Happy to help, not sure what "support" entails? ;-)

> Here is the info from configure so you know a little bit more about the
> platform we are talking about:
<snip>
> * C Compiler:     Sun Studio version 5.12 (at
> /root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/cc)
> * C++ Compiler:   Sun Studio version 5.12 (at
> /root/SolarisStudio12.3-solaris-x86-bin/solarisstudio12.3/prod/bin/CC)

The official toolset for 8u is SS12u1, so using 12u3 may encounter 
problems ...

> Firstly we had to apply the below patch in order to overcome couple of
> initial issues:
> 
> --- a/hotspot/make/solaris/makefiles/build_vm_def.sh
> +++ b/hotspot/make/solaris/makefiles/build_vm_def.sh
> @@ -1,6 +1,6 @@
>   #!/bin/sh
> 
> -/usr/ccs/bin/nm -p $* \
> +/opt/local/bin/nm -p $* \

The use of nm should really be via a NM variable set by configure, but 
the hotspot build isn't fully integrated with configure in 8u.

> --- a/hotspot/make/solaris/makefiles/sparcWorks.make
> +++ b/hotspot/make/solaris/makefiles/sparcWorks.make
> @@ -112,7 +112,7 @@ ARCHFLAG_OLD/sparcv9 = -xarch=v9
>   ARCHFLAG_NEW/sparcv9 = -m64 -xarch=sparc
>   ARCHFLAG_OLD/i486    =
>   ARCHFLAG_NEW/i486    = -m32
> -ARCHFLAG_OLD/amd64   = -xarch=amd64
> +ARCHFLAG_OLD/amd64   = -march=amdfam10

... this is the kind of problem you may get with a too recent toolset.

> We think that these values are hard-coded and there is no way (or at least
> we couldn't find one) to pass the custom values via a configure
> command-line option or environment variable.

May be possible to do this via EXTRA_CFLAGS variable ...

> And then finally after patching it manually, we landed with this issue:
> 
> Compiling /home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/hotspot/src/share/vm/runtime/vm_version.cpp
> Linking vm...
> ld: warning: symbol '__JvmOffsets' has differing types:
>          (file JvmOffsets.o type=OBJT; file dtrace.o type=FUNC);
> ld: warning: symbol 'CodeCache::_heap' has differing types:
>          (file codeCache.o type=OBJT; file dtrace.o type=FUNC);
> ld: warning: symbol 'BufferBlob::__vtbl' has differing types:
>          (file codeBlob.o type=OBJT; file dtrace.o type=FUNC);
> ld: warning: symbol 'Method::__vtbl' has differing types:
>          (file dtrace.o type=FUNC; file method.o type=OBJT);
> ld: warning: symbol 'nmethod::__vtbl' has differing types:
>          (file dtrace.o type=FUNC; file nmethod.o type=OBJT);
> ld: warning: symbol 'Universe::_collectedHeap' has differing types:
>          (file dtrace.o type=FUNC; file universe.o type=OBJT);

These warnings are well known and seemingly harmless.

> BFD: libjvm.debuginfo: Not enough room for program headers, try linking with -N
> /opt/local/bin//gobjcopy:libjvm.debuginfo[.note]: Bad value
> BFD: libjvm.debuginfo: Not enough room for program headers, try linking with -N
> /opt/local/bin//gobjcopy:libjvm.debuginfo: Bad value
> /home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/hotspot/make/solaris/makefiles/vm.make:296:
> recipe for target 'libjvm.so' failed
> gmake[6]: *** [libjvm.so] Error 1
> /home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/hotspot/make/solaris/makefiles/top.make:112:
> recipe for target 'the_vm' failed
> gmake[5]: *** [the_vm] Error 2
> /home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/hotspot/make/solaris/Makefile:226:
> recipe for target 'product' failed
> gmake[4]: *** [product] Error 2
> Makefile:230: recipe for target 'generic_build2' failed
> gmake[3]: *** [generic_build2] Error 2
> Makefile:177: recipe for target 'product' failed
> gmake[2]: *** [product] Error 2
> HotspotWrapper.gmk:44: recipe for target
> '/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
> failed
> gmake[1]: *** [/home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk/build/solaris-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
> Error 2
> /home/jenkins/workspace/openjdk_build_x86-64_smartOS/openjdk//make/Main.gmk:108:
> recipe for target 'hotspot-only' failed
> make: *** [hotspot-only] Error 2
> 
> 
> I see this has already been reported and resolved via
> https://bugs.openjdk.java.net/browse/JDK-8033602, so how come we still get
> this issue.

This was re-raised recently as well. See:

http://mail.openjdk.java.net/pipermail/build-dev/2017-May/019081.html

but again it relates to toolkits.

Cheers,
David
-----

> Any ideas or thoughts about the above?
> 
> Thanks.
> 
> Cheers,
> Mani
> 


From magnus.ihse.bursie at oracle.com  Mon May 29 07:25:10 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 29 May 2017 09:25:10 +0200
Subject: Missing separator on macro call ?
In-Reply-To: <db93530d-6c9d-37db-a4e0-27983322af40@oracle.com>
References: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
 <64efe20b-fab6-f384-88a5-b5efc1f57bcc@oracle.com>
 <db93530d-6c9d-37db-a4e0-27983322af40@oracle.com>
Message-ID: <b4d2d405-7e6e-e423-1d89-46fae3bb7612@oracle.com>

Maybe we should have a way to scan the source tree for files with 
problematic names, like *#* or *,*...? Or CachedFind should be written 
to handle *#* files properly?

/Magnus

On 2017-05-24 08:49, David Holmes wrote:
> On 24/05/2017 4:44 PM, Erik Joelsson wrote:
>> Hello David,
>>
>> That error means something goes wrong when evaluating the macro body. 
>> Unfortunately make will not give you any better message than that. If 
>> you didn't change anything in make/common/NativeCompilation.gmk, the 
>> most likely cause is that you have changed a variable that is used in 
>> there, or in one of the parameters in that call, and that variable 
>> now has some character in it that gets misinterpreted, typically a 
>> comma or dollar would be the culprits.
>
> Or a # :(
>
> Thanks Erik. Offlist Christine F. suggested I look for editor temp 
> files but I didn't find any. But by using the trace output and running 
> the find command - there it was: .#constantPool.cpp
>
> Wow! What an insane waste of time. :(
>
> David
>
>> /Erik
>>
>>
>> On 2017-05-24 01:44, David Holmes wrote:
>>> I just sync'd my local project with jdk10/hs and am getting a 
>>> strange build error:
>>>
>>> Building targets 'images test-image' in configuration 'linux-x64-debug'
>>> lib/CompileJvm.gmk:207: *** missing separator.  Stop.
>>>
>>> Line 207 is:
>>>
>>> $(eval $(call SetupNativeCompilation, BUILD_LIBJVM, \
>>>
>>> so it can't in itself have a missing separator!
>>>
>>> I don't know how to try and debug this - any suggestions?
>>>
>>> Thanks,
>>> David
>>



From david.holmes at oracle.com  Mon May 29 07:52:49 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 May 2017 17:52:49 +1000
Subject: Missing separator on macro call ?
In-Reply-To: <b4d2d405-7e6e-e423-1d89-46fae3bb7612@oracle.com>
References: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
 <64efe20b-fab6-f384-88a5-b5efc1f57bcc@oracle.com>
 <db93530d-6c9d-37db-a4e0-27983322af40@oracle.com>
 <b4d2d405-7e6e-e423-1d89-46fae3bb7612@oracle.com>
Message-ID: <a2883c0e-407b-073f-1ced-cb4f54cbd5ac@oracle.com>

On 29/05/2017 5:25 PM, Magnus Ihse Bursie wrote:
> Maybe we should have a way to scan the source tree for files with 
> problematic names, like *#* or *,*...? Or CachedFind should be written 
> to handle *#* files properly?

I have a recollection that these temp files used to cause a different 
kind of error that was much more obvious. I remember commenting that it 
was good that the build failed because you wouldn't be building waht you 
expected. But this "missing separator" error is just ridiculously 
obscure. :( Though something you should only get bitten by once.

Cheers,
David

> /Magnus
> 
> On 2017-05-24 08:49, David Holmes wrote:
>> On 24/05/2017 4:44 PM, Erik Joelsson wrote:
>>> Hello David,
>>>
>>> That error means something goes wrong when evaluating the macro body. 
>>> Unfortunately make will not give you any better message than that. If 
>>> you didn't change anything in make/common/NativeCompilation.gmk, the 
>>> most likely cause is that you have changed a variable that is used in 
>>> there, or in one of the parameters in that call, and that variable 
>>> now has some character in it that gets misinterpreted, typically a 
>>> comma or dollar would be the culprits.
>>
>> Or a # :(
>>
>> Thanks Erik. Offlist Christine F. suggested I look for editor temp 
>> files but I didn't find any. But by using the trace output and running 
>> the find command - there it was: .#constantPool.cpp
>>
>> Wow! What an insane waste of time. :(
>>
>> David
>>
>>> /Erik
>>>
>>>
>>> On 2017-05-24 01:44, David Holmes wrote:
>>>> I just sync'd my local project with jdk10/hs and am getting a 
>>>> strange build error:
>>>>
>>>> Building targets 'images test-image' in configuration 'linux-x64-debug'
>>>> lib/CompileJvm.gmk:207: *** missing separator.  Stop.
>>>>
>>>> Line 207 is:
>>>>
>>>> $(eval $(call SetupNativeCompilation, BUILD_LIBJVM, \
>>>>
>>>> so it can't in itself have a missing separator!
>>>>
>>>> I don't know how to try and debug this - any suggestions?
>>>>
>>>> Thanks,
>>>> David
>>>
> 


From kim.barrett at oracle.com  Mon May 29 10:25:45 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 29 May 2017 06:25:45 -0400
Subject: Missing separator on macro call ?
In-Reply-To: <a2883c0e-407b-073f-1ced-cb4f54cbd5ac@oracle.com>
References: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
 <64efe20b-fab6-f384-88a5-b5efc1f57bcc@oracle.com>
 <db93530d-6c9d-37db-a4e0-27983322af40@oracle.com>
 <b4d2d405-7e6e-e423-1d89-46fae3bb7612@oracle.com>
 <a2883c0e-407b-073f-1ced-cb4f54cbd5ac@oracle.com>
Message-ID: <724C34B1-F43F-4284-A6E1-EE5F7BEDBAF4@oracle.com>

> On May 29, 2017, at 3:52 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 29/05/2017 5:25 PM, Magnus Ihse Bursie wrote:
>> Maybe we should have a way to scan the source tree for files with problematic names, like *#* or *,*...? Or CachedFind should be written to handle *#* files properly?
> 
> I have a recollection that these temp files used to cause a different kind of error that was much more obvious.

I have the same recollection.

> I remember commenting that it was good that the build failed because you wouldn't be building waht you expected. But this "missing separator" error is just ridiculously obscure. :( Though something you should only get bitten by once.

I ran into it just recently.  Thankfully, I remembered this thread...



From magnus.ihse.bursie at oracle.com  Mon May 29 13:27:07 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 29 May 2017 15:27:07 +0200
Subject: Missing separator on macro call ?
In-Reply-To: <724C34B1-F43F-4284-A6E1-EE5F7BEDBAF4@oracle.com>
References: <ebf973f2-11b5-9e11-0140-a88753296fa7@oracle.com>
 <64efe20b-fab6-f384-88a5-b5efc1f57bcc@oracle.com>
 <db93530d-6c9d-37db-a4e0-27983322af40@oracle.com>
 <b4d2d405-7e6e-e423-1d89-46fae3bb7612@oracle.com>
 <a2883c0e-407b-073f-1ced-cb4f54cbd5ac@oracle.com>
 <724C34B1-F43F-4284-A6E1-EE5F7BEDBAF4@oracle.com>
Message-ID: <3f19efeb-2c2c-5c82-e7d1-485c1342dcec@oracle.com>


On 2017-05-29 12:25, Kim Barrett wrote:
>> On May 29, 2017, at 3:52 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 29/05/2017 5:25 PM, Magnus Ihse Bursie wrote:
>>> Maybe we should have a way to scan the source tree for files with problematic names, like *#* or *,*...? Or CachedFind should be written to handle *#* files properly?
>> I have a recollection that these temp files used to cause a different kind of error that was much more obvious.
> I have the same recollection.

I think I remember now. The failure discussed then was for a file in the 
hotspot directory. When we wrapped the old hotspot build, we first 
scanned the entire hotspot folder to see if anything had changed, since 
the "nop" build was so slow with the old hotspot build. This failed, but 
with a more obvious error result.

This scanning is no longer present. Also, depending on where in the 
source tree a spurious file may appear, different pieces of make logic 
might run into it first, so it's impossible to say how things will break.

/Magnus

>
>> I remember commenting that it was good that the build failed because you wouldn't be building waht you expected. But this "missing separator" error is just ridiculously obscure. :( Though something you should only get bitten by once.
> I ran into it just recently.  Thankfully, I remembered this thread...
>



From david.holmes at oracle.com  Mon May 29 02:17:13 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 May 2017 12:17:13 +1000
Subject: [PATCH]: linux-sparc build fixes
In-Reply-To: <d6671b9e-0dbf-f7da-c73c-2e58497bbc7c@physik.fu-berlin.de>
References: <d6671b9e-0dbf-f7da-c73c-2e58497bbc7c@physik.fu-berlin.de>
Message-ID: <4121e72b-25cb-a18f-dace-a44528cb622d@oracle.com>

Hi Adrian,

cc'ing hotspot-dev and bcc'ing build-dev as these are not issues with 
the build files, but hotspot sources.

First, than you for taking the time and effort to contribute to OpenJDK. 
However ...

The status of linux-sparc as a port in OpenJDK 9 (or 8u) is unclear. As 
you have found those bits have bit-rotted as it is not a supported 
Oracle JDK platform, and no-one else seems to have cared until now. Your 
patches may be acceptable, but we have no way to validate them. And the 
very next push may break things again. Or indeed once the hotspot issues 
are resolved you may find issues on the JDK library side. The process to 
get them into JDK 9 now is somewhat more difficult given where we are in 
the JDK 9 release. But without a commitment from some part of the 
community to maintain this port it may be better as something that is 
maintained downstream.

It would be interesting to hear from the Hotspot group leads on this.

Thanks,
David

On 27/05/2017 10:28 PM, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> openjdk-9 currently fails to build from source on Debian/sparc64 [1].
> 
> One of the reasons it fails is because of a misnamed header filename:
> 
> In file included from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/memory/allocation.inline.hpp:28:0,
>                   from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/utilities/array.hpp:29,
>                   from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/memory/universe.hpp:29,
>                   from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/code/oopRecorder.hpp:28,
>                   from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/asm/codeBuffer.hpp:28,
>                   from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/asm/assembler.hpp:28,
>                   from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/asm/macroAssembler.hpp:28,
>                   from /<<PKGBUILDDIR>>/src/hotspot/src/cpu/sparc/vm/nativeInst_sparc.hpp:28,
>                   from /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/code/nativeInst.hpp:30,
>                   from ad_sparc.hpp:32,
>                   from ad_sparc_misc.cpp:28:
> /<<PKGBUILDDIR>>/src/hotspot/src/share/vm/runtime/atomic.hpp:126:31: fatal error: atomic_linux_sparc.hpp: No such file or directory
>   #include OS_CPU_HEADER(atomic)
> 
> While fixing this, I also discovered some other problems with the build on Debian/sparc64.
> 
> I'm attaching a set of three patches which address all the issues I have discovered with
> openjdk-9 on Debian/sparc64 so far. They should apply to all builds on 64-bit Linux SPARC.
> 
> Please note, this is my first attempt ever trying to get patches into OpenJDK, so I will
> definitely need a little guidance. I have already asked in the #openjdk channel and after
> signing the OCA and sending it in, I was told to post my patches here. So here they are :).
> 
> Let's hope I can get them into the proper shape for getting them merged.
> 
> All patches are:
> 
> Signed-off by: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
> 
> Thanks,
> Adrian
> 
>> [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=sparc64&ver=9%7Eb170-2&stamp=1495173966&raw=0
> 


From dalibor.topic at oracle.com  Wed May 31 09:46:45 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 May 2017 11:46:45 +0200
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
Message-ID: <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>



On 29.05.2017 01:15, Mani Sarkar wrote:
> * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64

Subject says sparc, though. Are you cross-compiling in some way?

> Any ideas or thoughts about the above?

If you are running your own OpenJDK builds on a platform not listed on 
https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms 
such as SmartOS you may need to apply additional patches outside of 
OpenJDK to fix whatever platform-specific idiosyncrasies need fixing.

Whether such patches exist, and if there are such issues is something 
you'd need to discuss with that platform's provider through whatever 
channels they have for such support.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From glaubitz at physik.fu-berlin.de  Wed May 31 09:52:00 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 31 May 2017 11:52:00 +0200
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
Message-ID: <20170531095200.GA14877@physik.fu-berlin.de>

On Wed, May 31, 2017 at 11:46:45AM +0200, dalibor topic wrote:
> If you are running your own OpenJDK builds on a platform not listed on
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms such
> as SmartOS you may need to apply additional patches outside of OpenJDK to
> fix whatever platform-specific idiosyncrasies need fixing.

Why is so complicated to get patches merged to support additional
platforms? OpenJDK seems to be very unique in this regard.

Adrian

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


From dalibor.topic at oracle.com  Wed May 31 10:00:59 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 May 2017 12:00:59 +0200
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <20170531095200.GA14877@physik.fu-berlin.de>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
 <20170531095200.GA14877@physik.fu-berlin.de>
Message-ID: <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>



On 31.05.2017 11:52, John Paul Adrian Glaubitz wrote:
> On Wed, May 31, 2017 at 11:46:45AM +0200, dalibor topic wrote:
>> If you are running your own OpenJDK builds on a platform not listed on
>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms such
>> as SmartOS you may need to apply additional patches outside of OpenJDK to
>> fix whatever platform-specific idiosyncrasies need fixing.
>
> Why is so complicated to get patches merged to support additional
> platforms? OpenJDK seems to be very unique in this regard.

It's not very complicated. Please see 
http://openjdk.java.net/contribute/ for general details.

When it comes to ports to new platforms, the necessary changes may be (a 
lot) more invasive than a simple bugfix or two, though, so they should 
go through their own Projects.

That approach allows a port's developers to focus on making their port 
work well first without having to also deal with the regular influx of 
other, potentially breaking changes on the JDK mainline (and vice 
versa), and the specific review/integration rules in effect on the JDK 
mainline.

Once a port is getting ready to be merged into the JDK mainline, it can 
use the JEP process to get on the roadmap to arrive there.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From glaubitz at physik.fu-berlin.de  Wed May 31 10:44:00 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 31 May 2017 12:44:00 +0200
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
 <20170531095200.GA14877@physik.fu-berlin.de>
 <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>
Message-ID: <20170531104400.GB14877@physik.fu-berlin.de>

On Wed, May 31, 2017 at 12:00:59PM +0200, dalibor topic wrote:
> It's not very complicated. Please see http://openjdk.java.net/contribute/
> for general details.
> 
> When it comes to ports to new platforms, the necessary changes may be (a
> lot) more invasive than a simple bugfix or two, though, so they should go
> through their own Projects.

Ok, so I signed the OCA and sent in three patches to address build
issues on Linux/sparcv9. Those patches were rejected with the argument
that no one can test the code, even though Oracle themselves
officially support Oracle Linux on SPARC [1].

So, how can I get those fixes in?

Thanks,
Adrian

> [1] http://www.oracle.com/technetwork/server-storage/linux/downloads/oracle-linux-sparc-3665558.html

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


From neugens.limasoftware at gmail.com  Wed May 31 11:33:13 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 31 May 2017 13:33:13 +0200
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <20170531104400.GB14877@physik.fu-berlin.de>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
 <20170531095200.GA14877@physik.fu-berlin.de>
 <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>
 <20170531104400.GB14877@physik.fu-berlin.de>
Message-ID: <CAGUMyaTNUcrVMgY8+MfkwY=fD22B24Y0bitHgOm5MNGEJ-=hjw@mail.gmail.com>

2017-05-31 12:44 GMT+02:00 John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de>:
> On Wed, May 31, 2017 at 12:00:59PM +0200, dalibor topic wrote:
>> It's not very complicated. Please see http://openjdk.java.net/contribute/
>> for general details.
>>
>> When it comes to ports to new platforms, the necessary changes may be (a
>> lot) more invasive than a simple bugfix or two, though, so they should go
>> through their own Projects.
>
> Ok, so I signed the OCA and sent in three patches to address build
> issues on Linux/sparcv9. Those patches were rejected with the argument
> that no one can test the code, even though Oracle themselves
> officially support Oracle Linux on SPARC [1].

Do you have a link to this discussion?

> So, how can I get those fixes in?

As Dalibor said, this kind of patches tend to be very invasive, and as
a first contribution especially the entry barrier is quite high. You
may have better luck in trying to merge them into a separate Project
repository or start with a smaller set of changes.

In the meantime perhaps I would suggest to get in touch with the
distro-pkg-dev people since they may help you, even if this is not
Linux specific.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From glaubitz at physik.fu-berlin.de  Wed May 31 11:50:36 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 31 May 2017 13:50:36 +0200
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <CAGUMyaTNUcrVMgY8+MfkwY=fD22B24Y0bitHgOm5MNGEJ-=hjw@mail.gmail.com>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
 <20170531095200.GA14877@physik.fu-berlin.de>
 <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>
 <20170531104400.GB14877@physik.fu-berlin.de>
 <CAGUMyaTNUcrVMgY8+MfkwY=fD22B24Y0bitHgOm5MNGEJ-=hjw@mail.gmail.com>
Message-ID: <20170531115036.GE14877@physik.fu-berlin.de>

On Wed, May 31, 2017 at 01:33:13PM +0200, Mario Torre wrote:
> > Ok, so I signed the OCA and sent in three patches to address build
> > issues on Linux/sparcv9. Those patches were rejected with the argument
> > that no one can test the code, even though Oracle themselves
> > officially support Oracle Linux on SPARC [1].
> 
> Do you have a link to this discussion?

> http://mail.openjdk.java.net/pipermail/build-dev/2017-May/019301.html
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026984.html

> > So, how can I get those fixes in?
> 
> As Dalibor said, this kind of patches tend to be very invasive, and as
> a first contribution especially the entry barrier is quite high. You
> may have better luck in trying to merge them into a separate Project
> repository or start with a smaller set of changes.

Those patches aren't invasive. One fixes a filename, one adds a
missing #include and the third one adds a missing variable. All within
the linux_sparc folder.

> In the meantime perhaps I would suggest to get in touch with the
> distro-pkg-dev people since they may help you, even if this is not
> Linux specific.

I am one of the maintainers of the Debian/sparc64 port and we have the
possibility to add distro-specific patches. However, I don't want to
carry these patches around forever but rather get them merged upstream
and make them available to all downstreams, not just Debian.

Adrian

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


From neugens.limasoftware at gmail.com  Wed May 31 12:12:16 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 31 May 2017 14:12:16 +0200
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <20170531115036.GE14877@physik.fu-berlin.de>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
 <20170531095200.GA14877@physik.fu-berlin.de>
 <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>
 <20170531104400.GB14877@physik.fu-berlin.de>
 <CAGUMyaTNUcrVMgY8+MfkwY=fD22B24Y0bitHgOm5MNGEJ-=hjw@mail.gmail.com>
 <20170531115036.GE14877@physik.fu-berlin.de>
Message-ID: <CAGUMyaQcqMfYC7kFQnW0Pee79o=6aaLPk-O+xYZW+iXXwArJPA@mail.gmail.com>

2017-05-31 13:50 GMT+02:00 John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de>:
> On Wed, May 31, 2017 at 01:33:13PM +0200, Mario Torre wrote:
>> > Ok, so I signed the OCA and sent in three patches to address build
>> > issues on Linux/sparcv9. Those patches were rejected with the argument
>> > that no one can test the code, even though Oracle themselves
>> > officially support Oracle Linux on SPARC [1].
>>
>> Do you have a link to this discussion?
>
>> http://mail.openjdk.java.net/pipermail/build-dev/2017-May/019301.html
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026984.html
>
>> > So, how can I get those fixes in?
>>
>> As Dalibor said, this kind of patches tend to be very invasive, and as
>> a first contribution especially the entry barrier is quite high. You
>> may have better luck in trying to merge them into a separate Project
>> repository or start with a smaller set of changes.
>
> Those patches aren't invasive. One fixes a filename, one adds a
> missing #include and the third one adds a missing variable. All within
> the linux_sparc folder.

I can't check the patches in detail now, but I see that the discussion
on those threads doesn't go much on the technical side but rather
focus on whether Oracle should support or not their own products :)

I think David's reply was highlighting the actual points instead:

* The status of linux-sparc as a port in OpenJDK 9 (or 8u) is unclear
* There is no way you will get them JDK 9 at this stage, this work
needs to be done on 10
* Hotspot group leads should have a say on this

I think it makes sense to seek the hotspot leads approval for that
work before anything else.

>> In the meantime perhaps I would suggest to get in touch with the
>> distro-pkg-dev people since they may help you, even if this is not
>> Linux specific.
>
> I am one of the maintainers of the Debian/sparc64 port and we have the
> possibility to add distro-specific patches. However, I don't want to
> carry these patches around forever but rather get them merged upstream
> and make them available to all downstreams, not just Debian.
>

The way we have done that in the past is exactly this, slowly merge
upstream all the downstream specific changes, it's a process that
takes a lot of time, especially at the beginning when you need to
build trust and experience with the upstream developers.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From glaubitz at physik.fu-berlin.de  Wed May 31 12:26:16 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 31 May 2017 14:26:16 +0200
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <CAGUMyaQcqMfYC7kFQnW0Pee79o=6aaLPk-O+xYZW+iXXwArJPA@mail.gmail.com>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
 <20170531095200.GA14877@physik.fu-berlin.de>
 <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>
 <20170531104400.GB14877@physik.fu-berlin.de>
 <CAGUMyaTNUcrVMgY8+MfkwY=fD22B24Y0bitHgOm5MNGEJ-=hjw@mail.gmail.com>
 <20170531115036.GE14877@physik.fu-berlin.de>
 <CAGUMyaQcqMfYC7kFQnW0Pee79o=6aaLPk-O+xYZW+iXXwArJPA@mail.gmail.com>
Message-ID: <20170531122616.GF14877@physik.fu-berlin.de>

On Wed, May 31, 2017 at 02:12:16PM +0200, Mario Torre wrote:
> I can't check the patches in detail now, but I see that the discussion
> on those threads doesn't go much on the technical side but rather
> focus on whether Oracle should support or not their own products :)

Well, I wish we could focus on the technical side.

> I think David's reply was highlighting the actual points instead:
> 
> * The status of linux-sparc as a port in OpenJDK 9 (or 8u) is unclear
> * There is no way you will get them JDK 9 at this stage, this work
> needs to be done on 10

I just want the changes to get merged into what would be HEAD in git
terms, just to get them off my plate.

> * Hotspot group leads should have a say on this
> 
> I think it makes sense to seek the hotspot leads approval for that
> work before anything else.

For one-liner patches?

> >> In the meantime perhaps I would suggest to get in touch with the
> >> distro-pkg-dev people since they may help you, even if this is not
> >> Linux specific.
> >
> > I am one of the maintainers of the Debian/sparc64 port and we have the
> > possibility to add distro-specific patches. However, I don't want to
> > carry these patches around forever but rather get them merged upstream
> > and make them available to all downstreams, not just Debian.
> >
> 
> The way we have done that in the past is exactly this, slowly merge
> upstream all the downstream specific changes, it's a process that
> takes a lot of time, especially at the beginning when you need to
> build trust and experience with the upstream developers.

That's sound very slow and painful. I don't think this way you will be
able to attract contributors in the future. If such minor changes
already involve so much discussion, most contributors will refrain
from sending in patches which is sad because it means lots of good
patches and ideas will never get merged.

Adrian

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


From erik.osterlund at oracle.com  Wed May 31 13:45:26 2017
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 31 May 2017 15:45:26 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
Message-ID: <592EC8F6.5080605@oracle.com>

Hi,

It would be desirable to be able to use harmless C++ standard library 
headers like <limits> in the code as long as it does not add any 
link-time dependencies to the standard library.
This is possible on all supported platforms except the ones using the 
solaris studio compiler where we enforce -library=%none in both CFLAGS 
and LDFLAGS.
I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.

I have consulted with the studio folks, and they think this is 
absolutely fine and thought that the choice of -library=stlport4 should 
be fine for our CFLAGS and is indeed what is already used in the gtest 
launcher.

Webrev for jdk10-hs top level repository:
http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/

Webrev for jdk10-hs hotspot repository:
http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/

Testing: JPRT.

Will need a sponsor.

Thanks,
/Erik


From erik.joelsson at oracle.com  Wed May 31 13:57:14 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 31 May 2017 15:57:14 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <592EC8F6.5080605@oracle.com>
References: <592EC8F6.5080605@oracle.com>
Message-ID: <5edf009a-9055-a2a8-b546-d73094e05360@oracle.com>

(adding hotspot-dev)

Looks good from a build perspective.

/Erik


On 2017-05-31 15:45, Erik ?sterlund wrote:
> Hi,
>
> It would be desirable to be able to use harmless C++ standard library 
> headers like <limits> in the code as long as it does not add any 
> link-time dependencies to the standard library.
> This is possible on all supported platforms except the ones using the 
> solaris studio compiler where we enforce -library=%none in both CFLAGS 
> and LDFLAGS.
> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>
> I have consulted with the studio folks, and they think this is 
> absolutely fine and thought that the choice of -library=stlport4 
> should be fine for our CFLAGS and is indeed what is already used in 
> the gtest launcher.
>
> Webrev for jdk10-hs top level repository:
> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>
> Webrev for jdk10-hs hotspot repository:
> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>
> Testing: JPRT.
>
> Will need a sponsor.
>
> Thanks,
> /Erik



From Roger.Riggs at Oracle.com  Wed May 31 14:34:46 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 31 May 2017 10:34:46 -0400
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
Message-ID: <e8e26648-4c90-cfe0-5c04-f2db6c842105@Oracle.com>

Please review javadoc markup change to update to html5 acceptable to 
doclint.
The table formatting is updated to html5 markup.

The Docs build is updated to require doclint html5.

Webrev:
   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/
   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/

Issue:
https://bugs.openjdk.java.net/browse/JDK-8181156 html5 doclint issues in 
java.base javadoc

Thanks, Roger


From Alan.Bateman at oracle.com  Wed May 31 14:43:20 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 15:43:20 +0100
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: <e8e26648-4c90-cfe0-5c04-f2db6c842105@Oracle.com>
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
 <e8e26648-4c90-cfe0-5c04-f2db6c842105@Oracle.com>
Message-ID: <00be0bd8-baed-2859-a32a-fd6376f8db62@oracle.com>

On 31/05/2017 15:34, Roger Riggs wrote:

> Please review javadoc markup change to update to html5 acceptable to 
> doclint.
> The table formatting is updated to html5 markup.
>
> The Docs build is updated to require doclint html5.
>
> Webrev:
>   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/
>   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/
Some of the lines are way too long now and will means lots of horizontal 
scrolling when looking at diffs in the future. Can these be cleaned up 
before these changes are pushed?

-Alan


From sriramnrn at gmail.com  Wed May 31 23:37:21 2017
From: sriramnrn at gmail.com (Sriram Narayanan)
Date: Thu, 1 Jun 2017 07:37:21 +0800
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <20170531122616.GF14877@physik.fu-berlin.de>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
 <20170531095200.GA14877@physik.fu-berlin.de>
 <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>
 <20170531104400.GB14877@physik.fu-berlin.de>
 <CAGUMyaTNUcrVMgY8+MfkwY=fD22B24Y0bitHgOm5MNGEJ-=hjw@mail.gmail.com>
 <20170531115036.GE14877@physik.fu-berlin.de>
 <CAGUMyaQcqMfYC7kFQnW0Pee79o=6aaLPk-O+xYZW+iXXwArJPA@mail.gmail.com>
 <20170531122616.GF14877@physik.fu-berlin.de>
Message-ID: <CANiY96arqXzc16prFZg0hZG8e0zFrF5JvYeYQBULtsnhp3qG9Q@mail.gmail.com>

On Wed, May 31, 2017 at 8:26 PM, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:

> On Wed, May 31, 2017 at 02:12:16PM +0200, Mario Torre wrote:
> > I can't check the patches in detail now, but I see that the discussion
> > on those threads doesn't go much on the technical side but rather
> > focus on whether Oracle should support or not their own products :)
>
> Well, I wish we could focus on the technical side.
>
> > I think David's reply was highlighting the actual points instead:
> >
> > * The status of linux-sparc as a port in OpenJDK 9 (or 8u) is unclear
> > * There is no way you will get them JDK 9 at this stage, this work
> > needs to be done on 10
>
> I just want the changes to get merged into what would be HEAD in git
> terms, just to get them off my plate.
>
> > * Hotspot group leads should have a say on this
> >
> > I think it makes sense to seek the hotspot leads approval for that
> > work before anything else.
>
> For one-liner patches?
>
> > >> In the meantime perhaps I would suggest to get in touch with the
> > >> distro-pkg-dev people since they may help you, even if this is not
> > >> Linux specific.
> > >
> > > I am one of the maintainers of the Debian/sparc64 port and we have the
> > > possibility to add distro-specific patches. However, I don't want to
> > > carry these patches around forever but rather get them merged upstream
> > > and make them available to all downstreams, not just Debian.
> > >
> >
> > The way we have done that in the past is exactly this, slowly merge
> > upstream all the downstream specific changes, it's a process that
> > takes a lot of time, especially at the beginning when you need to
> > build trust and experience with the upstream developers.
>
> That's sound very slow and painful. I don't think this way you will be
> able to attract contributors in the future. If such minor changes
> already involve so much discussion, most contributors will refrain
> from sending in patches which is sad because it means lots of good
> patches and ideas will never get merged.
>

I agree.

I think such deliberation is the right thing to do for design changes and
alterations or additions to fundamentals.

For smaller changes,

I would urge the devs to consider "it depends" when deciding just how much
debate and deliberation is needed for a contribution.


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