RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

e current proposal, mainly the removal of the static factory methods from the concrete classes. JEP: http://openjdk.java.net/jeps/269 API spec (basically List, Map, and Set): http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151123/ Specdiff: http://cr.openjdk.j

Re: RFR: jsr166 jdk9 integration wave 2

On Mon, Nov 23, 2015 at 8:04 PM, joe darcy wrote: > Hello, > > There is a high barrier to consistent use of new jtreg keywords. FWIW, I > would prefer expanding the scope of @key randomness to defining a new @key > nondeterminstic. > It should come as no surprise to anyone that jtreg tests in j.

Re: RFR: 8140344: add support for 3 digit update release numbers

On 24/11/2015 12:24 AM, Rob McKenna wrote: Thanks David, I'll mark this 9-na. (bcc'ing verona-dev) Something similar was fixed in 7 (https://bugs.openjdk.java.net/browse/JDK-8009634) - that may be what you're thinking of. 6 hit this with 6u101 first, so presumably it was addressed there (and

Re: RFR: jsr166 jdk9 integration wave 2

Hello, There is a high barrier to consistent use of new jtreg keywords. FWIW, I would prefer expanding the scope of @key randomness to defining a new @key nondeterminstic. Thanks, -Joe On 11/18/2015 12:41 AM, Paul Sandoz wrote: On 18 Nov 2015, at 03:46, Martin Buchholz

Re: RFR: 8085984 Add JDBC Sharding API

Hi Joe, Thank you and Ulf for catching the error message typo as we changed the name of the method. I will fix that before I push Best Lance On Nov 23, 2015, at 7:09 PM, huizhe wang wrote: > Hi Lance, > > Looks good, except as Ulf pointed out already, in both in Connection.java and > XACon

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On Nov 23, 2015, at 1:42 PM, Aleksey Shipilev wrote: > > Okay, here it is (only tests changed): > http://cr.openjdk.java.net/~shade/8136500/webrev.06/ > Thanks; that's a solid test. Cleanups are good too. You can count me as a reviewer.

Re: RFR: 8085984 Add JDBC Sharding API

Hi Lance, Looks good, except as Ulf pointed out already, in both in Connection.java and XAConnection.java, SQLFeatureNotSupportedException should have been thrown with a message "setShardingKeyIfValid not implemented" rather than "isValid not implemented" (4 occurrences in total). Best, Joe

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Ah, the good 'ole switch statement earning more optimization jiras :). sent from my phone On Nov 23, 2015 7:36 PM, "John Rose" wrote: > On Nov 23, 2015, at 1:42 PM, Aleksey Shipilev > wrote: > > > > Okay, here it is (only tests changed): > > http://cr.openjdk.java.net/~shade/8136500/webrev.06/

Re: Reference.reachabilityFence

2015/11/23 8:38 -0800, paul.san...@oracle.com: > Please review the addition of Reference.reachabilityFence contributed > by Aleksey, Doug and myself: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-813

Re: Reference.reachabilityFence

Hi Peter, Reachability is not a side effect the compiler should preserve. In other words, if a method has no other side effects and is eliminated, I'd expect this to shorten the live range of any of its, say, arguments assuming no further use of them. If that doesn't happen, I'd consider that a

Re: RFR: 8085984 Add JDBC Sharding API

Hi, Isn't it "i_f_Valid not implemented" instead "i_s_Valid not implemented" or eventually "setShardingKeyIfValid not implemented"? -Ulf Am 24.11.2015 um 00:01 schrieb Lance Andersen: Hi all, Need a reviewer for 8085984, which adds support for Sharding. The CCC has been approved. The w

Re: Reference.reachabilityFence

Hi, On 11/23/2015 05:50 PM, Vitaly Davidovich wrote: Hi Paul, Glad you guys are addressing this. It looks like C1 and C2 will actually call this method. Is the longer term plan to teach the compilers that this method does not need to be called but rather expand the live range of the reference

RFR: 8085984 Add JDBC Sharding API

Hi all, Need a reviewer for 8085984, which adds support for Sharding. The CCC has been approved. The webrev can be found at http://cr.openjdk.java.net/~lancea/8085984/webrev.00/ Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Netw

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Frederic, Looks good. Many thanks. Karen > On Nov 23, 2015, at 12:44 PM, Frederic Parain > wrote: > > Karen, > > Thank you for your review, my answers are in-lined below. > > New Webrevs (including some fixes suggested by Paul Sandoz): > > http://cr.openjdk.java.net/~fparain/8046936/webrev

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

( Finally getting back to this, after too many weeks of travel ... ) 2015/10/20 11:28 -0700, roger.ri...@oracle.com: > Sorry for the silence, JavaOne preparations and the availability of > folks who wanted to review have stretched things out. > > The Cleaner API was very simple and saw feature cr

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 08:58 PM, John Rose wrote: > On Nov 23, 2015, at 8:23 AM, Ivan Gerasimov > wrote: >> >> Though, it may be better to get yet another pair of eyes. >> >> One minor nit: In the tests, in the summary, it is written, "Test >> Integer.toString method*s*",

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

> On 23 Nov 2015, at 16:08, Aleksey Shipilev > wrote: > > On 11/23/2015 04:34 PM, Ivan Gerasimov wrote: >> With this fixed patch: >> http://cr.openjdk.java.net/~igerasim/8136500/8136500-addition-1.patch >> all tests from test/lang pass. >> >> Would you give it another chance? > > Okay, but th

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Karen, Thank you for your review, my answers are in-lined below. New Webrevs (including some fixes suggested by Paul Sandoz): http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ On 20/11/2015 19:44, Karen Kinnear wrote: Fre

Re: Reference.reachabilityFence

On 11/23/2015 06:33 PM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/misc/ReachabilityFence/ReachabilityFence.java This works reliably on Linux and only takes not much more than 200ms per test. I wanted to say, not more than 100ms per negative test. How to choose the POSITIVE_T

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

> On Nov 23, 2015, at 8:42 AM, Alan Bateman wrote: > > We need to do a bit of clean-up in Images.gmk to make things clearer as this > MAIN vs. PROVIDER topic has caused confusion on a few cases. If we can keep > the lists separate to the list of modules for the compact profile builds then > t

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 07:08 AM, Aleksey Shipilev wrote: On 11/23/2015 04:34 PM, Ivan Gerasimov wrote: With this fixed patch: http://cr.openjdk.java.net/~igerasim/8136500/8136500-addition-1.patch all tests from test/lang pass. Would you give it another chance? Okay, but this is better be the last non-c

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 16:07, Attila Szegedi wrote: : Whichever is the stronger criteria for deciding whether to place it in MAIN or PROVIDER is fine with me. Intuitively “provider” seems like a weaker category (exposes a service provider but doesn’t have its own API), so (without knowing the particul

(De-)serialization, quo vadis

Hi, I'm not absolutely sure this is the best place to have this discussion (pointers welcome), but it's the most appropriate I figured out so far. In the light of the most recent code execution vulnerabilities through arbitrary object deserialization - and the follow-ups that I can guarantee you

Reference.reachabilityFence

Hi, Please review the addition of Reference.reachabilityFence contributed by Aleksey, Doug and myself: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ http://cr.openj

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

> On Nov 23, 2015, at 7:40 AM, Alan Bateman wrote: > > > > On 23/11/2015 15:27, Attila Szegedi wrote: >> Folks, >> >> I integrated the changes Mandy suggested; please review these (build >> related) changes: >> jdk9 top level: >>

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 15:43, Sundararajan Athijegannathan wrote: But, in addition to providing service, jdk.scripting.nashorn module also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. Sure, it could go in either but we mostly treat it as a service provider. -Alan.

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

> On Nov 23, 2015, at 4:40 PM, Alan Bateman wrote: > > > > On 23/11/2015 15:27, Attila Szegedi wrote: >> Folks, >> >> I integrated the changes Mandy suggested; please review these (build >> related) changes: >> jdk9 top level: >>

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

But, in addition to providing service, jdk.scripting.nashorn module also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. -Sundar On 11/23/2015 9:10 PM, Alan Bateman wrote: On 23/11/2015 15:27, Attila Szegedi wrote: Folks, I integrated the changes Mandy suggested; please revi

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 09:05 PM, Aleksey Shipilev wrote: > On 11/23/2015 08:58 PM, John Rose wrote: >> On Nov 23, 2015, at 8:23 AM, Ivan Gerasimov > > wrote: >>> >>> Though, it may be better to get yet another pair of eyes. >>> >>> One minor nit: In the tests, in the summar

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 08:58 PM, John Rose wrote: > On Nov 23, 2015, at 8:23 AM, Ivan Gerasimov > wrote: >> >> Though, it may be better to get yet another pair of eyes. >> >> One minor nit: In the tests, in the summary, it is written, "Test >> Integer.toString method*s*",

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On Nov 23, 2015, at 8:23 AM, Ivan Gerasimov wrote: > > Though, it may be better to get yet another pair of eyes. > > One minor nit: In the tests, in the summary, it is written, "Test > Integer.toString method*s*", but only one of the overloads is tested. Here's another nit in the tests. This i

Re: Reference.reachabilityFence

Hi Paul, Good to see this getting in. Cleaner API depends on it ;-) On 11/23/2015 05:38 PM, Paul Sandoz wrote: Hi, Please review the addition of Reference.reachabilityFence contributed by Aleksey, Doug and myself: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jd

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 04:34 PM, Ivan Gerasimov wrote: > With this fixed patch: > http://cr.openjdk.java.net/~igerasim/8136500/8136500-addition-1.patch > all tests from test/lang pass. > > Would you give it another chance? Okay, but this is better be the last non-cosmetic change to board this departing tr

Re: Reference.reachabilityFence

Hi Paul, Glad you guys are addressing this. It looks like C1 and C2 will actually call this method. Is the longer term plan to teach the compilers that this method does not need to be called but rather expand the live range of the reference? Thanks On Mon, Nov 23, 2015 at 11:38 AM, Paul Sandoz

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 15:27, Attila Szegedi wrote: Folks, I integrated the changes Mandy suggested; please review these (build related) changes: jdk9 top level: jdk9/jdk:

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

Hi Jason On 20.11.2015 22:15, Jason Mehrens wrote: Alexander, I see your point. It is also out of spec for Handler.setFormatter to actually call Formatter.setErrorManager. What if there are subclasses of formatter that exist today with a setErrorManager method? Also not all handlers have o

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

Alexander, Given those constraints, what about simply modify the output string? As in: = . } catch (Exception ex) { // Formatting failed: use localized format string. return format + " " + toString(record, ex); } private String toString(LogRecord record, Exception

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Great! Now I like it the best. Though, it may be better to get yet another pair of eyes. One minor nit: In the tests, in the summary, it is written, "Test Integer.toString method*s*", but only one of the overloads is tested. Sincerely yours, Ivan On 23.11.2015 18:08, Aleksey Shipilev wrote:

Re: RFR: jsr166 jdk9 integration wave 2

On 11/23/2015 10:27 AM, Peter Levart wrote: Sorry for confusion. I now noticed that Throwable.addSuppressed() and getSuppressed() methods are actually synchronized! I don't know how I missed that... And I don't know how you led me to forget that :-) So above patch is not needed. Even print

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

Folks, I integrated the changes Mandy suggested; please review these (build related) changes: jdk9 top level: jdk9/jdk: For the sake of complete

Re: RFR: jsr166 jdk9 integration wave 2

Hi, On 11/23/2015 03:12 PM, Doug Lea wrote: On 11/23/2015 04:54 AM, Peter Levart wrote: In CompletableFuture.uniWhenComplete method, the possible exception thrown from BiConsumer action is added as suppressed exception to the exception of the previous stage. This updated exception is then

Re: RFR: jsr166 jdk9 integration wave 2

On 11/23/2015 04:54 AM, Peter Levart wrote: In CompletableFuture.uniWhenComplete method, the possible exception thrown from BiConsumer action is added as suppressed exception to the exception of the previous stage. This updated exception is then passed as completion result to next stage. When p

Re: RFR: 8140344: add support for 3 digit update release numbers

Thanks David, I'll mark this 9-na. (bcc'ing verona-dev) Something similar was fixed in 7 (https://bugs.openjdk.java.net/browse/JDK-8009634) - that may be what you're thinking of. Aside from that are you ok with the changes? -Rob On 18/11/15 09:00, David Holmes wrote: On 18/11/2015

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

What sanity checks you had in mind? Because java/lang/Integer/IntegerDecode.java fails, and it fails *in compiler*. Oh, how embarrassing! Overlooked a sign :( I had tested it only with new lang/Integer/ToString.java, in a hope it gives enough coverage for sanity, but I was wrong. I tried to

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 12:36 PM, Ivan Gerasimov wrote: > A couple of concerns, though: > 1) > Wouldn't it be clearer to have "(byte)('0' + q);" instead of "(byte)(48 > + q); // 48 is ASCII '0'"? > I see that '0' constant is used in arithmetic in some other places. Yes, okay: http://cr.openjdk.java.net/~s

Re: Throwable support for cloning: was Re: RFR: jsr166 jdk9 integration wave 2

Even more backwards-compatible. It keeps current behavior for Throwable.clone() method if subclasses use it. Just one static method and implemented interface need to be added: public class Throwable implements Serializable, Cloneable { /** * Clones given {@code exception} and returns

Throwable support for cloning: was Re: RFR: jsr166 jdk9 integration wave 2

Hi, Until Throwable.addSuppressed() was added in JDK7 to support try-with-resources statement, Throwable has been a more-or-less immutable from the outside (except for initCause which is a one-of method meant to be called right after construction and before throwing and can't be called multip

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

Given John's comments, and the limitation of -XX:-RestrictContended, adding an additional command line flag, -XaddExports, in 9 to access @CS seems reasonable. I will proceed with this change as is. http://cr.openjdk.java.net/~chegar/8140687/00/ -Chris. On 13/11/15 00:08, John Rose wrote: O

Re: RFR: jsr166 jdk9 integration wave 2

On 11/16/2015 10:39 PM, Martin Buchholz wrote: Smaller than wave 1, but still large. Nothing like a looming deadline to spur work ... Oracle folks will need to help with API review. https://bugs.openjdk.java.net/issues/?jql=(subcomponent%20%3D%20java.util.concurrent)%20AND%20status%20%3D%20%2

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Hi Aleksey! I think the code looks much better now! A couple of concerns, though: 1) Wouldn't it be clearer to have "(byte)('0' + q);" instead of "(byte)(48 + q); // 48 is ASCII '0'"? I see that '0' constant is used in arithmetic in some other places. 2) What still annoys me is the necessity

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

+1 for the Nashorn/Dynalink changes. The top level changes look good to me but I'd prefer to leave reviews to those who are more familiar with the build/modules infrastructure. Hannes Am 2015-11-20 um 00:15 schrieb Attila Szegedi: Please review JDK-8141338 "Move jdk.internal.dynalink package

Re: RFR JDK-8143330: No appropriate CCC request for two new protected methods added in JDK9b93 by JDK-8141132

Hi, looks good to me. Best, Tobias On 20.11.2015 19:41, Xueming Shen wrote: > > I missed the override version in StringBuffer.java, thanks > Tobias for catching it. > > http://cr.openjdk.java.net/~sherman/8143553 > https://bugs.openjdk.java.net/browse/JDK-8143553 > > I did re-generate the api

Re: JDK 9 RFR of JDK-8143583: Several tests don't work with latest jtreg due to non-existing files in @build

On 23/11/2015 07:10, Amy Lu wrote: Below tests failed with latest nightly jtreg due to non-existing files in @build com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java sun/tools/jmap/BasicJMapTest.java com/sun/jdi/DoubleAgentTest.java com/sun/jdi/SuspendNoFlagTest.java Please review this