Re: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base

Thanks as usual for the modern html lessons. Looks good. Things I wonder about: - I expected to find scope= attributes in BlockingDeque.java tables. TIL about colgroup and rowgroup. (or does headers=... make that redundant?) - I see "font-style: italic" but that seems rather low-level and I

Re: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base

Hi Naoto, Thanks for checking out the changes. On 08/18/2017 05:19 PM, Naoto Sato wrote: Hi Jon, Thank you for the cleanup! I looked at j.l.String, j.t.DateTimeFormatter, and j.u.ResourceBundle and all look good. BTW, I just noticed that in ResourceBundle, line 1330 and so on, there is a

Re: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base

Hi Jon, Thank you for the cleanup! I looked at j.l.String, j.t.DateTimeFormatter, and j.u.ResourceBundle and all look good. BTW, I just noticed that in ResourceBundle, line 1330 and so on, there is a new column "Index" introduced. Is this intentional? Naoto On 8/18/17 5:03 PM, Jonathan

RFR: JDK-8186466: Fix accessibility and other minor issues in java.base

Please review these fixes for various minor documentation issues in the java.base module. The changes are mostly in java.util and its subpackages, but there is some minor cleanup in previously updated packages as well. The primary focus is on addressing accessibility issues. In addition, some

[10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

Hi, Please review this API enhancement for MethodHandle.invokeWithArguments to support jumbo-arity and for BSM invocation to be specified in terms of MethodHandle.invokeWithArguments: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8185992-invoke-with-arguments-jumbo/webrev/ This patch is

Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

looks good. It's better than the previous wording. cheers, Rémi - Mail original - > De: "Stuart Marks" > À: "core-libs-dev" > Envoyé: Vendredi 18 Août 2017 21:59:25 > Objet: RFR(s) #2: 6344935: (spec) clarify specifications for

RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

Hi all, Well nothing is ever simple, is it? Prompted by David Holmes' comments, I looked at the other overloads of wait(), and I agree that they're in need of cleanup. I decided to put the most complete version of the specification into the wait(timeout, nanos) overload, and then I simply

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

Hi Jaroslav, In general, thanks for pushing through with this change. I don't think JVMCIMXBeans should be in the hotspot-agnostic jdk.vm.ci.services.internal package since it has a direct reference to HotSpotJVMCIRuntime. I would suggest moving it to jdk.vm.ci.hotspot. In

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

Updated changes in all repos: http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ On 8/18/17 7:12 AM, Jaroslav Tulach wrote: Thanks for pushing me forward, Vladimir. Yes, the changes are still needed if we want the Graal compiler to expose its MBean in a lazy way. I am offering new webrev for

RFR 8173817: StackOverflowError in "process reaper" thread

Please review a change to the process reaper completion handler's choice of an anonymous inner class for more consistent stack usage.  Additional background and discussion in the issue 8173817 [1]. Webrev:    http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8173817/ Issue: [1]  

Re: RFR: JDK8U Backport of 8185346: Relax RMI Registry Serial Filter to allow arrays of any type

Looks good. Regards, Sean. On 17/08/17 20:06, Ramanand Patil wrote: Hi All, Please review this webrev for jdk8u backport. Webrev: http://cr.openjdk.java.net/~rpatil/8185346/jdk8u-dev/webrev.00/ Main Bug: https://bugs.openjdk.java.net/browse/JDK-8185346 JDK10 review thread:

Re: java.util.stream 'map' method, proposal of method name change

On 16/08/17 13:26, Remi Forax wrote: > the name comes from Lisp > https://en.m.wikipedia.org/wiki/Map_(higher-order_function) Actually, the Lisp usage comes from mathematics: https://en.wikipedia.org/wiki/Map_(mathematics) Since the original conception of Lisp was lambda calculus realised as a