[9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently

2015-09-18 Thread Brian Burkhalter
Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-5100935 Patch: http://cr.openjdk.java.net/~bpb/5100935/webrev.00/ Summary: Add multiplyFull() and multiplyHigh() methods to java.lang.Math. This change addresses the Java specification and implementation only.

Re: RFR: 8136656: Check in blessed-modifier-order.sh

2015-09-18 Thread Magnus Ihse Bursie
On 2015-09-17 18:09, Chris Hegarty wrote: On 17 Sep 2015, at 17:08, Martin Buchholz wrote: Done! The updated webrev ( in-place ) looks good to me Martin. Agree. /Magnus -Chris. On Thu, Sep 17, 2015 at 1:14 AM, Chris Hegarty wrote: On 16

Re: Running blessed-modifier-order on the rest of the JDK

2015-09-18 Thread Martin Buchholz
(I'm on both sides of the upstream/downstream divide) It's a good idea to have a per-directory-tree metadata file that can provide information about the tree where it is found, like TEST.ROOT but more general and extensible. Here at Google we actually have files named METADATA - this makes it

Re: RFR(m) 2: 8072722: add stream support to Scanner

2015-09-18 Thread Stuart Marks
On 9/17/15 12:11 AM, Peter Levart wrote: As an alternative to additional boolean field, you could use one bit of expectedCount/modCount int field(s): - let initial value of expectedCount be 1 (odd value) - instead of (expectedCount >= 0) ==> (expectedCount != 1) - let initial value of

Re: Running blessed-modifier-order on the rest of the JDK

2015-09-18 Thread Magnus Ihse Bursie
On 2015-09-17 18:24, Martin Buchholz wrote: flush with success, I ran blessed-modifier-order on the entire JDK forest, and it seems to work fine. But we want to leave out code maintained elsewhere. How to identify that? As far as I know, the only way to figure out if code is maintained

Re: [verona.stage] RFR 8087203: Adapt Version.java.template to the JEP-223 new version string format

2015-09-18 Thread Alejandro E Murillo
Thanks Iris Alejandro On 9/17/2015 4:17 PM, Iris Clark wrote: Hi, Alejandro. This cleanup looks good to me. Thanks, iris (not a JDK 9 Reviewer) -Original Message- From: Alejandro E Murillo Sent: Wednesday, September 16, 2015 11:04 AM To: core-libs-dev@openjdk.java.net Cc:

Re: JEP 264: Platform Logging API and Service

2015-09-18 Thread David M. Lloyd
On 09/18/2015 11:17 AM, mark.reinh...@oracle.com wrote: New JEP Candidate: http://openjdk.java.net/jeps/264 +1 good idea! -- - DML

Review: Indify String Concat JEP

2015-09-18 Thread Aleksey Shipilev
Hi, I recently sent the review request to compiler-dev@ [1], but got no response. Resending at corelibs-dev@ to gain more exposure. Please review the submitted "Indify String Concat" JEP. It seems complete to me: with working implementation, testing, and general understanding of an issue. Start

Re: RFR (xs) : 8077874 : [TESTBUG] The test com/sun/corba/cachedSocket/7056731.sh should not be run on JRE

2015-09-18 Thread Chris Hegarty
Looks fine to me Sean. -Chris. On 17 Sep 2015, at 14:50, Seán Coffey wrote: > Test bug correction to allow the jdb command to be launched via compilejdk > parameter where necessary. I've checked for similar usage across other corba > tests and this one seems to be the

Re: RFR: 8136570: Avoid setting environment variables related to /usr/dt

2015-09-18 Thread Martin Buchholz
On Thu, Sep 17, 2015 at 11:00 AM, Stuart Marks wrote: > Doctor Deprecator approves. > > Not only is this a win because it's a pure-deletion change, it's a double > win because it removes a side effect from a function that's supposed to > "get" and initialize Java