Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Claes, > http://cr.openjdk.java.net/~redestad/8193128/open.02/ I think you should provide specialised implementations of the #indexOf() and #lastIndexOf() methods in the classes List12 and ListN. Using an iterator in List12 is an overkill. But even in ListN using a simple for loop would be

Possible bug in StackFrameInfo#getByteCodeIndex?

I was doing some research related to AccessController, and I noted this code [1] in StackFrameInfo#getByteCodeIndex(): @Override public int getByteCodeIndex() { // bci not available for native methods if (isNativeMethod()) return -1; return bci; } Now bci is of type short,

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On Thu, Dec 7, 2017 at 4:47 PM, Stuart Marks wrote: > > > On 12/7/17 3:50 PM, Jonathan Bluett-Duncan wrote: > > Looking over http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/ >> src/java.base/share/classes/java/util/ArrayList.java.cdiff.html, I'm >> wondering

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

Yes! It would be even better for the "toArray(Class)" case if Class had a "getArrayClass()" method which returned the Class, which would allow: return (T[]) Arrays.copyOf(elementData, size, componentType.getArrayClass()); and similar for other array-backed collections. I never

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

On Dec 7, 2017, at 4:33 PM, Stuart Marks wrote: > Please review this changeset that introduces a new no-arg method > orElseThrow() to Optional, as a preferred alternative to the get() method. Looks OK to me. > Corresponding methods are also added to OptionalDouble,

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

(I'm still trying to love this new API) The changes to the jsr166 tck are fine. I'm not convinced that the new implementation for ArrayList is progress. The current implementation of toArray(T[]) does // Make a new array of a's runtime type, but my contents: return (T[])

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/7/17 3:50 PM, Jonathan Bluett-Duncan wrote: Looking over http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/src/java.base/share/classes/java/util/ArrayList.java.cdiff.html, I'm wondering if the method `ArrayList.toArray(IntFunction)` should have an `@Override` to make it

RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

Hi all, Please review this changeset that introduces a new no-arg method orElseThrow() to Optional, as a preferred alternative to the get() method. Corresponding methods are also added to OptionalDouble, Int, and Long. The orElseThrow() method is functionally identical to get(). It has some

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

On 12/7/17 6:38 AM, Daniel Fuchs wrote: Hi, Please find below a patch for: 8191033 Regression in logging.properties: specifying .handlers= for     root logger (instead of handlers=) no longer works https://bugs.openjdk.java.net/browse/JDK-8191033 webrev:

Re: RFR: jsr166 jdk integration 2017-12-XX

++1 -Chris > On 7 Dec 2017, at 18:03, Paul Sandoz wrote: > > +1 > > Paul. > >> On 7 Dec 2017, at 09:14, Martin Buchholz wrote: >> >> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html >> >> With the change to the

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

Hi Stuart, Looking over http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/src/java.base/share/classes/java/util/ArrayList.java.cdiff.html, I'm wondering if the method `ArrayList.toArray(IntFunction)` should have an `@Override` to make it clear that it's overriding the default method in

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On 2017-12-07 01:12, Claes Redestad wrote: SubList is now final, inherits from AbstractImmutableList instead of AbstractList and reuses more of the shared code. I also moved 'implements Serializable' from AbstractImmutableList to List12 and ListN respectively to not change the behavior that

Re: RFR 4358774: Add null InputStream and OutputStream

Hi Sergey, On Dec 7, 2017, at 3:14 PM, Sergey Bylokhov wrote: >> http://cr.openjdk.java.net/~bpb/4358774/webrev.02/. > > Why the >Objects.requireNonNull(b); > should be called before >Objects.checkFromIndexSize(off, len, b.length); > since the second call

Re: RFR 4358774: Add null InputStream and OutputStream

On 07/12/2017 14:55, Brian Burkhalter wrote: Hi Roger, I agree. It does not seem that whatever performance improvement might accrue from not using the Objects methods is offset by the increased code readability in addition to mitigating the risks mentioned in [1]. I have reinstated this

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

[Martin: please review changes to the JSR 166 TCK.] Another updated webrev for this changeset: http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/ This includes an override of toArray(IntFunction) in the implementation of Arrays.asList(), as requested by Tagir Valeev. Overrides

Re: RFR 4358774: Add null InputStream and OutputStream

Hi Roger, I agree. It does not seem that whatever performance improvement might accrue from not using the Objects methods is offset by the increased code readability in addition to mitigating the risks mentioned in [1]. I have reinstated this approach in

Re: RFR 4358774: Add null InputStream and OutputStream

Hi Brian, For checking indices, I think you should leverage the work done for java.util.Objects.checkFromIndexSize(...) as optimized for this purpose in 8135248.  That was extensively designed and reviewed for optimal performance. Regards, Roger [1]

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 7, 2017, at 12:05 PM, Remi Forax wrote: > > have a bit saying if an object is fully initialized or not, this bit will be > true at the end of the constructor and can be set for the de-serialization too Yes, that's the hard part of fixing final. Sometimes we call this

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

You have also the problem of people doing a lot of things in the constructor, by example class Foo { @Stable final int x; Foo() { m(); x = 3; m(); } void m() { for(...) { // use x here } } } here, m() can be JITed with x equals to 0 as a constant and the

Draft JEP: Enhanced pseudo-random number generators

Please check out a new draft JEP https://bugs.openjdk.java.net/browse/JDK-8193209 that proposes new interface types and implementations for pseudo-random number generators. —Guy

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

> On Dec 6, 2017, at 5:16 PM, Paul Sandoz wrote: > > It can, since final fields are not treated as really final (unless in > java.lang.invoke package, where it’s as if all such fields are annotated with > @Stable). C2 will treat the field value a constant value if the

Re: RFR 4358774: Add null InputStream and OutputStream

Updated patch: http://cr.openjdk.java.net/~bpb/4358774/webrev.01/ On Dec 7, 2017, at 6:08 AM, Alan Bateman wrote: > If nothing else, a private ensureOpen method would make it easier to read so > that the "if (closed) throw ..." isn't needed in every method. Done. On

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

I'm not a logging expert, but this change Looks Good To Me. --- A bunch of "handler" should be changed to "handlers" +// Verify that exactly one of the two handler is a custom.Handler +// Verify that exactly one of the two handler is a custom.DotHandler +// Verify that

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

You went to the trouble of checking test.src. Shouldn't CONFIG_FILE be found relative to SRC_DIR? +public static final Path SRC_DIR = +Paths.get(System.getProperty("test.src", "src")); +public static final Path USER_DIR = +Paths.get(System.getProperty("user.dir",

Re: Finalization and dead references: another proposal

On 12/07/2017 07:22 PM, Peter Levart wrote: On 12/07/2017 06:46 PM, Vitaly Davidovich wrote: So no magic here. Just API. This is an API version of Hans’s #3 approach. As he said, there’s performance overhead and nothing guarantees that the referent is kept alive - that’s an

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

On Thu, Dec 7, 2017 at 11:00 AM, Martin Buchholz wrote: > You went to the trouble of checking test.src. Shouldn't CONFIG_FILE be > found relative to SRC_DIR? > > Oh never mind, I now see you did +Path initialProps = SRC_DIR.resolve(CONFIG_FILE); +Path

Re: Finalization and dead references: another proposal

Hi Remi, On 12/07/2017 07:12 PM, Remi Forax wrote: So no magic here. Just API. This is an API version of Hans’s #3 approach. As he said, there’s performance overhead and nothing guarantees that the referent is kept alive - that’s an implementation artifact. it's not even true, the

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

On 12/7/17 1:08 PM, serguei.spit...@oracle.com wrote: Hi Dan, The fix looks good to me. Nice, you have caught it. Thanks for the review! Do you want this fixed in 10 or 11? I thought that the jdk/hs is for 11 now. Is it correct? Please see Mark R's e-mail with the subject line of "JDK 10

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

On 12/7/17 10:08, serguei.spit...@oracle.com wrote: Hi Dan, The fix looks good to me. Nice, you have caught it. Do you want this fixed in 10 or 11? I thought that the jdk/hs is for 11 now. Is it correct? Never mind. I've just found a message from Jesper the jdk/hs is used for 10 pushes for

Re: Finalization and dead references: another proposal

On Thu, Dec 7, 2017 at 1:22 PM, Peter Levart wrote: > > > On 12/07/2017 06:46 PM, Vitaly Davidovich wrote: > > So no magic here. Just API. > > This is an API version of Hans’s #3 approach. As he said, there’s > performance overhead and nothing guarantees that the

Re: Finalization and dead references: another proposal

On 12/07/2017 06:46 PM, Vitaly Davidovich wrote: So no magic here. Just API. This is an API version of Hans’s #3 approach.  As he said, there’s performance overhead and nothing guarantees that the referent is kept alive - that’s an implementation artifact. I think without the VM

Re: Finalization and dead references: another proposal

On Thu, Dec 7, 2017 at 1:12 PM, Remi Forax wrote: > - Mail original - > > De: "Vitaly Davidovich" > > À: "Peter Levart" > > Cc: "core-libs-dev" > > Envoyé: Jeudi 7 Décembre 2017 18:46:41 > >

Re: Finalization and dead references: another proposal

- Mail original - > De: "Vitaly Davidovich" > À: "Peter Levart" > Cc: "core-libs-dev" > Envoyé: Jeudi 7 Décembre 2017 18:46:41 > Objet: Re: Finalization and dead references: another proposal > On Thu, Dec 7,

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

Hi Dan, The fix looks good to me. Nice, you have caught it. Do you want this fixed in 10 or 11? I thought that the jdk/hs is for 11 now. Is it correct? Thanks, Serguei On 12/7/17 09:09, Daniel D. Daugherty wrote: Roger, Thanks for the review! Dan P.S. I'm planning to push this fix to

Re: RFR: jsr166 jdk integration 2017-12-XX

+1 Paul. > On 7 Dec 2017, at 09:14, Martin Buchholz wrote: > > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > > > > With the change to the openjdk

Re: Finalization and dead references: another proposal

On Thu, Dec 7, 2017 at 12:28 PM Peter Levart wrote: > Hi, > > On 12/07/2017 03:27 AM, Vitaly Davidovich wrote: > > So kind of the opposite of WeakReference - a SuperStrongReference :). > > > > Kidding aside, it seems like the way you’d want to encapsulate this at > the >

Re: RFR 4358774: Add null InputStream and OutputStream

> On Dec 6, 2017, at 11:11 AM, Jonathan Gibbons > wrote: > >> "null" is a significant term in the Java ecosystem, and the relationship >> here, to /dev/null or NUL seems somewhat tenuous. >> >> Have any other names been considered? At least for the InputStream,

Re: Finalization and dead references: another proposal

Hi, On 12/07/2017 03:27 AM, Vitaly Davidovich wrote: So kind of the opposite of WeakReference - a SuperStrongReference :). Kidding aside, it seems like the way you’d want to encapsulate this at the language level is via a type that the JVM intrinsically knows about; in this way it’s similar to

Review Request: JDK-8193192: jdeps --generate-module-info does not look at module path

jdeps currently finds modules from the module path for analysis based on the value specified via --add-modules option.  When the input classes depend on a module on the given module path, it will report missing dependences until the module is specified in --add-modules option.  This fixes this

RFR: jsr166 jdk integration 2017-12-XX

http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html With the change to the openjdk release model, jsr166 integrations will simply be "jdk integrations" instead of e.g. "jdk10 integrations" from now on. (Nevertheless, we try to get in important bug fixes before jdk

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

Roger, Thanks for the review! Dan P.S. I'm planning to push this fix to jdk/hs since the only sightings have been in jdk/hs testing or in projects that are parented to jdk/hs repos... Hope that's okay... On 12/7/17 12:07 PM, Roger Riggs wrote: +1 On 12/7/2017 12:00 PM, Gerald Thornbrugh

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

+1 On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: Hi Dan, Your fix looks good. Jerry Adding core-libs-dev@... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This is one of the few times that

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

Jerry, Thanks for the review! Dan On 12/7/17 12:00 PM, Gerald Thornbrugh wrote: Hi Dan, Your fix looks good. Jerry Adding core-libs-dev@... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

Hi Dan, Your fix looks good. Jerry Adding core-libs-dev@... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This is one of the few times that reply-to-all is the right thing to do... Dan On

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

configure => configured +// For backward compatibility: add any handlers configure using

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

Adding core-libs-dev@... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This is one of the few times that reply-to-all is the right thing to do... Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote:

Re: RFR(XS) : 8181118 : update java/time tests to use RandomFactory from the top level testlibrary

Hi Igor, On 12/7/2017 11:18 AM, Igor Ignatyev wrote: Also, please break the line (w/ '\`) for exclusiveAccess so side-by-side diffs fit on the screen. it's not really related to this patch, so if you don't mind of course, I'd prefer to make that refactoring in a separate RFE. True, but it

Re: Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

+1

Re: RFR JDK-8187485: Update Zip implementation to use Cleaner, not finalizers

On 12/4/17 3:14 PM, Xueming Shen wrote: issue: https://bugs.openjdk.java.net/browse/JDK-8185582 webrev: http://cr.openjdk.java.net/~sherman/8185582/webrev ZStreamRef.java 79 static ZStreamRef get(Object owner, LongSupplier addr, LongConsumer end) { It may be better to have two factory

Re: RFR(XS) : 8181118 : update java/time tests to use RandomFactory from the top level testlibrary

Hi Roger, > On Dec 7, 2017, at 7:27 AM, Roger Riggs wrote: > > Hi Igor, > > Looks fine. > > Is the current jtreg b09? no, the latest the greatest jtreg is 4.2-b10. usually we specify the minimal required version in TEST.ROOT, not the latest available. > > Also,

Re: Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

On 12/7/17 5:39 AM, Alan Bateman wrote: On 07/12/2017 05:04, mandy chung wrote: On 12/6/17 6:08 PM, Martin Buchholz wrote: Google decided that LinkedList is almost never the best choice, so any use of LinkedList is discouraged. ArrayDeque's backing array never shrinks, so you might

Re: Finalization and dead references: another proposal

Hi, I'm trying to read the rules and imagine cases where they would not work... /A field declared to be reachability-sensitive is reachability-safe. An access a to a reachability-safe field of object p inside a (possibly static) method in p’s class, results in the introduction of

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

Hi Rob, Latest code looks good to me. minor bit. LdapDnsProviderService.java Line: 71 , while loop condition is bit complex, we can simplify it little bit as follows.This will make code more readable and easy to understand. while (iterator.hasNext())     {    

Re: RFR(XS) : 8181118 : update java/time tests to use RandomFactory from the top level testlibrary

Hi Igor, Looks fine. Is the current jtreg b09? Also, please break the line (w/ '\`) for exclusiveAccess so side-by-side diffs fit on the screen. Thanks, Roger On 12/6/2017 7:35 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev/8181118/webrev.00 115 lines changed: 0 ins; 108

Re: RFR 4358774: Add null InputStream and OutputStream

On Thu, Dec 7, 2017 at 9:40 AM Roger Riggs wrote: > Hmm... > > Seems like a lot of fine tuning for a function that has a low profile and > no > performance data... These are known issues in the current JIT optimizer. We all wish we didn’t have to do this stuff. If we

Re: Change in properties for logging: deliberate?

Hi Jeremy, I just proposed a patch on core-libs-dev. best regards, -- daniel On 06/12/2017 01:17, Jeremy Manson wrote: Hey folks, Any thoughts on a timeline for this? We're just having to decide what to do internally.  If a patch is likely to arrive in the next month or so, then we'll

Re: RFR 4358774: Add null InputStream and OutputStream

Hmm... Seems like a lot of fine tuning for a function that has a low profile and no performance data... $.02, Roger On 12/6/2017 10:03 PM, Vitaly Davidovich wrote: On Wed, Dec 6, 2017 at 4:01 PM, Jason Mehrens wrote: Brian, My understand is JDK-6533165 is moving

RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

Hi, Please find below a patch for: 8191033 Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works https://bugs.openjdk.java.net/browse/JDK-8191033 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8191033/webrev.00/ The patch

Re: RFR 4358774: Add null InputStream and OutputStream

On 06/12/2017 21:01, Jason Mehrens wrote: Brian, My understand is JDK-6533165 is moving the bytes that are rarely invoked to a cold method. Therefore: if (closed) { throw new IOException("Stream closed"); } ==becomes=== if (closed) { throw sc(); } private static IOException

Re: Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

On 2017-12-07 14:39, Alan Bateman wrote: On 07/12/2017 05:04, mandy chung wrote: On 12/6/17 6:08 PM, Martin Buchholz wrote: Google decided that LinkedList is almost never the best choice, so any use of LinkedList is discouraged. ArrayDeque's backing array never shrinks, so you might

Re: Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

On 07/12/2017 05:04, mandy chung wrote: On 12/6/17 6:08 PM, Martin Buchholz wrote: Google decided that LinkedList is almost never the best choice, so any use of LinkedList is discouraged. ArrayDeque's backing array never shrinks, so you might want to give it an explicit initial size.

Re: Add EnumMap.keyType() and EnumSet.elementType()

I'm surprised I've never run into this. This seems like a simple and useful change. Stephen On 7 December 2017 at 11:40, Andrej Golovnin wrote: > Hi all, > > it would be nice if we would have access to the class of the enum type > used to create an EnumMap or an

Add EnumMap.keyType() and EnumSet.elementType()

Hi all, it would be nice if we would have access to the class of the enum type used to create an EnumMap or an EnumSet. This is usefull when you write a custom serialization library and would like to serialize/deserialize an empty EnumMap or an empty EnumSet. For the empty EnumSet there is a

FW: RFR(M): 8189102: All tools should support -?, -h and --help

Hi, ... missed some lists in my first post ... I prepared a fifth webrev for this change. Please review. It incorporates the changes requested by the CSR reviewers (not to remove docuemtation of '-help' where is was documented before) and the changes proposed by Kumar: