Re: JDK 9 RFR(m): 8150488: Scanner.findAll() can return infinite stream if regex matches zero chars

+1 On 4/27/17, 3:34 PM, Stuart Marks wrote: Hi all, Please review this fix [1] for JDK-8150488 [2] to prevent Scanner.findAll() from returning an infinite stream of zero-length matches in certain cases. This was previously an issue that simply documented this limitation. In the review for

Re: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module

+1 Mandy > On Apr 27, 2017, at 5:25 PM, Jonathan Gibbons > wrote: > > Please review a handful of small changes that were not caught be the earlier > bulk updates. Unlike those earlier updates, these few were determined > manually. > > After these minor changes,

Re: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module

On 04/27/2017 05:53 PM, Martin Buchholz wrote: Thanks. On Thu, Apr 27, 2017 at 5:25 PM, Jonathan Gibbons > After these minor changes, all remaining issues in java.base are related to the use and appearance of tables.

Re: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module

Thanks. On Thu, Apr 27, 2017 at 5:25 PM, Jonathan Gibbons < jonathan.gibb...@oracle.com> > > After these minor changes, all remaining issues in java.base are related > to the use and appearance of tables. > Aside: most tables can probably be modified to do simply even if their appearance then

Re: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module

Looks fine; thanks, -Joe On 4/27/2017 5:34 PM, Lance Andersen wrote: +1 On Apr 27, 2017, at 8:25 PM, Jonathan Gibbons wrote: Please review a handful of small changes that were not caught be the earlier bulk updates. Unlike those earlier updates, these few were

Re: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module

+1 > On Apr 27, 2017, at 8:25 PM, Jonathan Gibbons > wrote: > > Please review a handful of small changes that were not caught be the earlier > bulk updates. Unlike those earlier updates, these few were determined > manually. > > After these minor changes, all

RFR: 8179413: Fix remaining minor HTML5 issues in java.base module

Please review a handful of small changes that were not caught be the earlier bulk updates. Unlike those earlier updates, these few were determined manually. After these minor changes, all remaining issues in java.base are related to the use and appearance of tables. JBS:

JDK 9 RFR(m): 8150488: Scanner.findAll() can return infinite stream if regex matches zero chars

Hi all, Please review this fix [1] for JDK-8150488 [2] to prevent Scanner.findAll() from returning an infinite stream of zero-length matches in certain cases. This was previously an issue that simply documented this limitation. In the review for that issue [3], Timo K convinced me that this

Re: [JDK9] RFR 8167229: Improve VarHandle documentation

> On 27 Apr 2017, at 11:32, Martin Buchholz wrote: > > Looks good! > Thanks, i made the changes you propose in the previous emails. > --- > > Consider changing parameter name of findVarHandle name to make it clearer > it's a field name > name => fieldName >

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

I understand the interest in having test pass reliably, but I don't think giving the test very large timeouts is the preferred way of accomplishing that. For all configurations, the test can now run for up to 20 minutes, up from 4 minutes. We want to run the entire test suite, thousands of

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

+1 Joe On 4/27/2017 12:08 PM, Brent Christian wrote: Hi, This test times out under our automated testing configurations that include -Xcomp. Please review my change to increase the timeout for this test. It is sufficient for the test configurations in question to pass on two different

Re: [JDK9] RFR 8167229: Improve VarHandle documentation

Looks good! --- Consider changing parameter name of findVarHandle name to make it clearer it's a field name name => fieldName findVarHandle(Class recv, String name, Class type) I might have named these methods instanceFieldVarHandle and staticFieldVarHandle to make it clearer there are many

Re: RFR: 8179370: Replace use of , and tags in java.base

Only comment is updating the copyright dates to 2017. Brad On 4/26/2017 6:23 PM, Mandy Chung wrote: Looks okay. Mandy On Apr 26, 2017, at 5:50 PM, Jonathan Gibbons wrote: Please review these mostly simple changes to replace HTML tags which are not valid in

Re: [JDK9] RFR 8167229: Improve VarHandle documentation

Add missing period. 1787 * Returns the {@code VarHandle} signature-polymorphic method name 1788 * associated with this {@code AccessMode} value 1789 *

Re: [JDK9] RFR 8167229: Improve VarHandle documentation

Oh wait, there's a distinction between "access mode" and "access mode method", because of VarHandle.AccessMode. Is it true that each access mode is associated with exactly one access mode method ? Seems to be yes, because of

Re: [JDK9] RFR 8167229: Improve VarHandle documentation

Each access mode is associated with an access mode method Tautological. Did you mean to say "Each VarHandle method" or "Each access" ? > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229- > varhandle-docs/webrev/index.html >

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

Hi folks, I'd like to revisit this for JDK10 as it was judged to be a bit late in the game for 9. I've published a new webrev at: http://cr.openjdk.java.net/~robm/8160768/webrev.05/ which incorporates very helpful feedback from Michael Osipov. Notes: - The 9 request rejection noted that there

Re: RFR: 8179370: Replace use of , and tags in java.base

> On Apr 26, 2017, at 6:49 PM, Jonathan Gibbons > wrote: > > Updated webrev to address Joe's suggestion to try harder to use {@code} as a > substitute for . > > http://cr.openjdk.java.net/~jjg/8179370/webrev.01 Looks good. Mandy

Re: RFR: 8179370: Replace use of , and tags in java.base

On 27/04/2017 02:49, Jonathan Gibbons wrote: Updated webrev to address Joe's suggestion to try harder to use {@code} as a substitute for . http://cr.openjdk.java.net/~jjg/8179370/webrev.01 The updated version using {@code ... } looks better and also keeps the lines from growing too long.

Re: RFR: 8178298 (LdapLoginModule)Migrate the JNDI properties technote to javadoc doc-files

On Tuesday 25 April 2017 08:41 PM, Chris Hegarty wrote: Vyom, On 24 Apr 2017, at 10:15, Vyom Tewari wrote: Hi All, Please review the simple doc fix. Webrev : http://cr.openjdk.java.net/~vtewari/8178298/webrev0.0/index.html Bugid :