RFR: 8167002: JAXP schema validator: Use HashSet instead of ArrayList for tracking XML IDs

https://bugs.openjdk.java.net/browse/JDK-8167002 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/xml-id-validation-by-hash/

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

On 9/28/16 4:48 AM, Claes Redestad wrote: as discussed recently on hotspot-compiler-dev[1], having a private class with no default constructor can lead to C2 failing to inline, due to the synthetic bridge constructor using a dummy argument of an uninitialized class. This is really a problem in

Re: Collection Design FAQ

On 9/22/16 11:13 PM, Kasper Nielsen wrote: I accidently bumped into an old friend today https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html There are couple of questions that might need an update after Java 8. Such as Why don't you provide an "apply" method in

Re: ParallelStream Vs Stream Digest, Vol 113, Issue 94

On 9/30/16 12:41 PM, John Rose wrote: On Sep 29, 2016, at 11:39 PM, Louis Wasserman wrote: You should absolutely not assume parallel streams are faster than sequential streams. http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html

RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

Hi, I have a fix for a 10 year old bug (JDK-6378384 ). It was marked as a duplicate of a 19 year old bug (JDK-4032740 ) which is marked as a duplicate of a 17 year old bug (JDK-4283544

Re: ParallelStream Vs Stream Digest, Vol 113, Issue 94

On Sep 29, 2016, at 11:39 PM, Louis Wasserman wrote: > > You should absolutely not assume parallel streams are faster than > sequential streams. > http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html >

RFR 9: 8155760 Implement Serialization Filtering - revised for extensibility

Converging on a final version. The ObjectInputFilter.FilterInfo.getClazz method was renamed to serialClass to improve readability and reduce ambiguity with getClass. A few other editorial improvements have been made in the docs of the FilterInfo interface for arrays, depth(), references(), and

RE: Proposal for adding O_DIRECT support into JDK 9

Hi All, Please find the most recent version of the patch available at http://cr.openjdk.java.net/~igraves/8164900-2/ In this version, we have following two changes: 1. Move O_DIRECT flag from StandardOpenOption to ExtendedOpenOption 2. Move the checks of O_DIRECT from native code to Java code.

Re: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK

Hi Sergey, I'm not a reviewer, but after reading the deprecation messages in Event.java * @deprecated It is recommended that {@code AWTEvent} class and its > subclasses > * be used instead. I get the impression they would read better without the redundant "class" in the middle,

Re: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK

The jconsole change looks fine. I’m including serviceability-dev and bcc core-libs-dev as serviceability-dev is the right mailing list for jconsole change. Mandy > On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov > wrote: > > Hello. > > Please review the fix for

[9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK

Hello. Please review the fix for jdk9. This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug

Re: RFR: 8166842: String.hashCode() has a non-benign data race

Hi, Thank you all for reviews and comments, especially instructive was Hans Boehm's explanation about why JMM must allow reordering of plain reads from the same location. The fix is now pushed. Regards, Peter

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 30/09/16 14:55, Rafael Winterhalter wrote: > That does not work in the general case but only if the initiating class > is also on the class path. A class can only be identified uniquely as a > pair of name and class loader. > > I experimented with this and ended up iterating over >

Re: RFR: 8166842: String.hashCode() has a non-benign data race

Dear Peter, On Thu, Sep 29, 2016 at 5:31 AM, Peter Levart wrote: > I think Carsten has a point. > I think that this is enough to apply the fix, thanks. > You are welcome. I added my thoughts to the jira ticket. Carsten

Re: RFR: 8166842: String.hashCode() has a non-benign data race

On Thu, Sep 29, 2016 at 2:31 AM, Peter Levart wrote: > > I think that this is enough to apply the fix, thanks. > I think general concurent software hygiene considerations are enough to commit this fix. Don't re-read fields, especially ones that are involved in a race!

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Stuart, Thanks for doing such a thorough review of the parts you've managed to look at so far. I see you had a number of questions in your numbered bullet points, so I'll do my best to answer them below. 1) It actually didn't occur to me that there was a potential TOCTOU problem in

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

That does not work in the general case but only if the initiating class is also on the class path. A class can only be identified uniquely as a pair of name and class loader. I experimented with this and ended up iterating over Instrumentation.getAllLoadedClasses which resulted in rather poor

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 30/09/16 14:27, Rafael Winterhalter wrote: > A Java agent ends up on the class path. The Byte Buddy agent (or any > similar library) basically adds a single class: > > package net.bytebuddy.agent; > public class Installer { > public static volatile Instrumentation instrumentation; > public

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

A Java agent ends up on the class path. The Byte Buddy agent (or any similar library) basically adds a single class: package net.bytebuddy.agent; public class Installer { public static volatile Instrumentation instrumentation; public static void agentMain(String argument, Instrumentation

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 30/09/16 13:15, Rafael Winterhalter wrote: > Such a library exists already: > http://mvnrepository.com/search?q=byte-buddy-agent Ok, so problem solved :-) > I do however not share your point of view on this: if there is a valid > use case for self-attachment - Aleksey, you and I already named

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

Such a library exists already: http://mvnrepository.com/search?q=byte-buddy-agent I do however not share your point of view on this: if there is a valid use case for self-attachment - Aleksey, you and I already named several such use cases - why not add convenience, security and performance to

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 30/09/16 10:37, Alan Bateman wrote: > On 30/09/2016 09:39, Rafael Winterhalter wrote: > >> I agree that this should be considered carefully. >> >> However, without a security manager, it is already possible to get >> such an instance for most environments. And starting with Java 9, this >>

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 30/09/2016 09:39, Rafael Winterhalter wrote: I agree that this should be considered carefully. However, without a security manager, it is already possible to get such an instance for most environments. And starting with Java 9, this will extend to non JDK-VMs as the former tools.jar is

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

I agree that this should be considered carefully. However, without a security manager, it is already possible to get such an instance for most environments. And starting with Java 9, this will extend to non JDK-VMs as the former tools.jar is now a module. I think by adding such a method, security

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 29/09/2016 20:37, Rafael Winterhalter wrote: It would be perfectly fine, in my opinion, to throw an unsupported operation exception, if the feature was unsupported. The method would primarily be used by testing code and tools. Right, but it essentially means that anything that use

Re: ParallelStream Vs Stream Digest, Vol 113, Issue 94

You should absolutely not assume parallel streams are faster than sequential streams. http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html is pretty much the iconic document on that subject, and explains circumstances under which parallelism is good, and when it is likely to be harmful.