Deprecate all java.util.concurrent.*FieldUpdater

Given that Java 9 introduces a faster way to emit things like compareAndSet by using the VarHandke API and that AtomiReference (and likes) are now rewritten to use VarHandles directly, i think it's time to deprecate all *FieldUpdater with something saying that they have been superseded by the

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

On 10/4/16 3:55 AM, Claes Redestad wrote: On 2016-10-04 12:52, Aleksey Shipilev wrote: On 10/04/2016 12:50 PM, Claes Redestad wrote: Webrev: http://cr.openjdk.java.net/~redestad/8167005/webrev.01/ OK. Thanks for the speedy review! :-) Thanks for looking at this. The shorter text in

RE: RFR(M): 8166560: [s390] Basic enablement of s390 port.

Hi David, I fixed the change accordingly: http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr03/ But do you really want me to incorporate a bugfix for ARM in the port? Best regards, Goetz. > -Original Message- > From: David Holmes [mailto:david.hol...@oracle.com] >

RE: Proposal for adding O_DIRECT support into JDK 9

Hi Christoph, Thank you very much for trying our patch. We are still seeking the feedback from the community. When we get closer to the final version of the patch, we will modify the copyright years. Thank you for reminding us! Anyone else has any feedback/comments? Thanks, Lucy

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

The explanation which Stuart gives for this change in https://bugs.openjdk.java.net/browse/JDK-8167005 seems to describe why this constructor is needed much better than the comment itself does. So I wonder if it's worth adding the link to the bug report in the comment. E.g. // prevent generation

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

On 9/30/16 6:57 AM, Jonathan Bluett-Duncan wrote: 1) It actually didn't occur to me that there was a potential TOCTOU problem in ModuleFinder.compose, despite the fact that I found a potential problem in FileTreeIterator - it completely missed me, so thank you for finding it! I'll see if I can

Re: Deprecate all java.util.concurrent.*FieldUpdater

VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet complete (where is accumulateAndGet?), and when do you deprecate something when the replacement won't be ubiquitous for 10 years? On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax wrote: > Given that Java 9

Re: RFR: 8166875: (tz) Support tzdata2016g

Looks good to me! On Tue, Oct 4, 2016 at 3:22 AM, Ramanand Patil wrote: > Hi Martin, > Thank you for your review and explanation of "Yangon". I liked the > translation "End of Strife". > > Looking at the description of the ZoneNames.java: > * The zid<->metazone

Re: RFR(M): 8166560: [s390] Basic enablement of s390 port.

Hi Goetz, On 28/09/2016 8:26 PM, Lindenmaier, Goetz wrote: Hi, here a new webrev for this change: http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr02/ I reverted the major reorderings in macros.hpp and os_linux.cpp. David asked me to do so, and I guess it makes reviewing

RE: Proposal for adding O_DIRECT support into JDK 9

Hi Lucy, FWIW: I ran a build on AIX and this looks ok. I also assume in your final version you'll update all copyright years where it's not 2016 yet? Other than that the changes look ok to me - but I'm neither a reviewer nor a deep expert in the area of your changes. Best regards Christoph >

Re: [9] RFR: 8166645: Include locales plugin throws InternalError with "*" specified.

Thanks, Mandy. I updated it as you suggested. http://cr.openjdk.java.net/~naoto/8166645/webrev.02/ Naoto On 10/3/16 7:53 PM, Mandy Chung wrote: On Oct 3, 2016, at 3:17 PM, Naoto Sato wrote: According to an internal review, I added some explanation to the

RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

Hi, I have a fix for conformance (P2) bug (8062389 ) that also fixes a conformance (P3) bug (8029459 ) and a performance issue (8061950 ):

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

On 2016-10-04 12:52, Aleksey Shipilev wrote: On 10/04/2016 12:50 PM, Claes Redestad wrote: Webrev: http://cr.openjdk.java.net/~redestad/8167005/webrev.01/ OK. Thanks for the speedy review! :-) /Claes

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

On 10/04/2016 12:50 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8167005/webrev.01/ OK. -Aleksey

RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

Hi, as suggested by Stuart Marks in the review thread for JDK-8166840, we should add a comment as to why an empty constructor is important in the private inner Itr class, to avoid it being accidentally "cleaned up". Webrev: http://cr.openjdk.java.net/~redestad/8167005/webrev.01/ Bug:

RE: RFR: 8166875: (tz) Support tzdata2016g

Hi Martin, Thank you for your review and explanation of "Yangon". I liked the translation "End of Strife". Looking at the description of the ZoneNames.java: * The zid<->metazone mappings are based on CLDR metaZones.xml. * The alias mappings are based on Link entries in tzdb data files. I had

Re: [9] RFR: 8166645: Include locales plugin throws InternalError with "*" specified.

> On Oct 4, 2016, at 5:42 AM, Naoto Sato wrote: > > Thanks, Mandy. I updated it as you suggested. > > http://cr.openjdk.java.net/~naoto/8166645/webrev.02/ +1 Mandy

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

> On 4 Oct 2016, at 11:55, Claes Redestad wrote: > > > On 2016-10-04 12:52, Aleksey Shipilev wrote: >> On 10/04/2016 12:50 PM, Claes Redestad wrote: >>> Webrev: http://cr.openjdk.java.net/~redestad/8167005/webrev.01/ +1 -Chris.

RFR: 8159855

Core-libs folk, Please review the following change to add a new service provider class java.util.spi.ToolProvider which can be used provide simple "command-line" access to select JDK tools, without starting a new JVM. The following tools are updated to provide access through the new SPI:

RE: Proposal for adding O_DIRECT support into JDK 9

Hi Brain, Thank you very much for reviewing the patch and providing the detailed error/warning messages. They are very helpful! We will look into the issues and solve them in the next version of the patch. Test cases for O_DIRECT and modified copyright year will be added in next version too.

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

On 4 October 2016 at 23:27, Stuart Marks wrote: > 4) The 'resolverFields' problem/comment was regarding DateTimeFormatter (see > this part of latest webrev), where I realised I couldn't use Set.of instead > of Collections.unmodifiableSet(new HashSet<>(Arrays.asList(*))),

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

Hi Jonathan, the aim isn't to add an in-depth explanation to the code about exactly the circumstance that led to this constructor and comment being added, but to put a clear message that it was simply, in fact, deliberate, so even the proposed comment might be going further than strictly

Re: RFR: 8159855: Create an SPI for tools

Resend with non-mostly-empty subject line! -- Jon On 10/04/2016 04:39 PM, Jonathan Gibbons wrote: Core-libs folk, Please review the following change to add a new service provider class java.util.spi.ToolProvider which can be used provide simple "command-line" access to select JDK tools,

Re: Proposal for adding O_DIRECT support into JDK 9

Hi Lucy, On Oct 4, 2016, at 10:24 AM, Lu, Yingqi wrote: > Anyone else has any feedback/comments? I looked over the 8164900-2 patch and did not see any conceptual problems per se. I did not however scrutinize all the detailed changes, especially the more extensive ones

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

Right, the main point of the comment is to tell the reader the constructor isn't superfluous, to prevent it from being cleaned up and accidentally causing a regression. Full history can reside in the commit comment, the bug database, and in these email logs. I'd put in a link to a bug only

Re: RFR: 8166875: (tz) Support tzdata2016g

Hi Ramanand, I don't think it's appropriate to add the bug ID to test/sun/util/resources/cldr/Bug8134384.java. This test doesn't verify the TimeZoneNames*.java changes of this fix. Otherwise, the change looks OK to me. Thanks, Masayoshi On 10/4/2016 7:22 PM, Ramanand Patil wrote: Hi

Re: RFR: 8159855: Create an SPI for tools

This SPI is useful and provides as a replacement to existing use of internal APIs to launch some of our tools. We will get jar, jmod, jlink and possibly other tools to convert to this SPI. ToolProvider::findFirst(String name) can find tool providers on classpath. I think it needs to wrap the

Re: RFR: 8159855: Create an SPI for tools

This SPI is useful and provides as a replacement to existing use of internal APIs to launch some of our tools. We will get jar, jmod, jlink and possibly other tools to convert to this SPI. ToolProvider::findFirst(String name) can find tool providers on classpath. I think it needs to wrap the

Re: RFR(M): 8166560: [s390] Basic enablement of s390 port.

On 5/10/2016 2:52 AM, Lindenmaier, Goetz wrote: Hi David, I fixed the change accordingly: http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr03/ But do you really want me to incorporate a bugfix for ARM in the port? Sure - it is only an error message and we've probably never

Review Request JDK-8167014: jdeps: Missing message: warn.skipped.entry

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8167014/webrev.00/index.html This fixes the missing key in the resource bundle and also include the exception message of the invalid entry. I verified with a JAR file with bad entries. Mandy

Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

Hi Peter, Without making any comment on what you have actually done, does this account for private interface methods correctly? Thanks, David On 4/10/2016 11:40 PM, Peter Levart wrote: Hi, I have a fix for conformance (P2) bug (8062389 )

Review Request JDK-8166846: jdeps fails to generate module info if there is any class in unnamed package

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166846/webrev.00/ This improves jdeps error message to indicate that a JAR file containing unnamed package is not valid to generate module-info.java. Mandy

RE: RFR: JEP draft for Linux/s3990x port

Hi Vladimir, This webrev contains all the changes to hotspot needed for the port: http://cr.openjdk.java.net/~goetz/wr16/8166730-linuxs390-all/hotspot.wr01/ It includes http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr03/

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

To a potential reviewer... The change might look scary at first as it touches reflective access controls and by that, security of the platform, but: - it is just (32 ins; 56 del; 62 mod) lines. The rest is a new jtreg test which is beneficial by itself as such test did not exist until now. -