Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

On 17/12/2014 10:06 AM, Martin Buchholz wrote: On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley wrote: On 11/12/14 00:53, David Holmes wrote: There are many good uses of storestore in the various lock-free algorithms inside hotspot. There may be many uses, but I am extremely suspicious of how g

Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

Various comments for this thread from June/July/November/December. Some of the comments I'm responding to may already be better understood than when they were originally written. Peter wrote in response to a suggestion to use /dev/random: Although the approach would cause some more classes t

RFR: JDK-8067151 - [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh

Hi please oblige and review the follow changes http://cr.openjdk.java.net/~msheppar/8067151/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8067151 which sees a test failure for JRE only in an embedded environment. the test scripts now use the env variable COMPILEJAVA r

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley wrote: > On 11/12/14 00:53, David Holmes wrote: >> There are many good uses of storestore in the various lock-free >> algorithms inside hotspot. > > There may be many uses, but I am extremely suspicious of how good > they are. I wonder if we went thro

Re: Documentation of methods in java.lang.Number

Andreas, Doesn’t the class documentation of Number [1] provide sufficient clarity, to wit: " The specific semantics of the conversion from the numeric value of a particular Number implementation to a given primitive type is defined by the Number implementation in question.” and “[…] conversi

Re: JDK-8067661: transferTo proposal for Appendable

Hi Patrick, nice to hear from you again! I agree we should consider adding this method. Unfortunately, from the spec point of view I suppose this one will require a lot more chewing. For instance there's nothing that can be closed either in Readable or Appendable (in general case), since neither of

JDK-8067661: transferTo proposal for Appendable

Hi Chris & Pavel, Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer.

Re: RFR(s): 8035117: TEST_BUG: java/rmi/server/RemoteObject/notExtending/NotExtending.java can fail with timeout

Thanks Lance, I appreciate it. That's what I get for posting a code review on a Friday afternoon during the holiday season. :-) s'marks On 12/16/14 9:42 AM, Lance Andersen wrote: Looks OK stuart. Another test I looked at last week but forgot to reply On Dec 16, 2014, at 12:40 PM, Stuart Mark

Re: Java implementation of Alpha-numeric comparator

Maybe it can be considered as a special "tailoring" of UCA. It's "alphabetic" + "numeric", the "alphabetic" part got to be "locale sensitive". The "non-locale-sensitive-alphabetic-order" is a special case of locale sensitive sorting. It might be true most people don't care about it here, but so

Re: Java implementation of Alpha-numeric comparator

j.t.Collator is basically for locale sensitive sorting, and I think this use case is locale independent. Aside from how significant to have it in the library, I am not sure j.t.Collator is the right place. Naoto On 12/16/14 11:04 AM, Xueming Shen wrote: On 12/16/2014 06:58 AM, roger riggs wro

Re: Java implementation of Alpha-numeric comparator

On 12/16/2014 10:44 AM, Ivan Gerasimov wrote: On 16.12.2014 17:58, roger riggs wrote: Hi Ivan, In which package/class do you propose to add the API to get the comparator? I was thinking of java.text package, though I don't see a specific class in which the static method could be naturally i

Re: Java implementation of Alpha-numeric comparator

On 12/16/2014 06:58 AM, roger riggs wrote: Hi Ivan, In which package/class do you propose to add the API to get the comparator? In java.time, comparators are returned from static methods in an interface. This allows lambda to be used for the implementation. For example, ChronoZonedDateTime.time

Re: Java implementation of Alpha-numeric comparator

On 16.12.2014 17:58, roger riggs wrote: Hi Ivan, In which package/class do you propose to add the API to get the comparator? I was thinking of java.text package, though I don't see a specific class in which the static method could be naturally included. This kind of Comparator doesn't seem

Re: RFR(s): 8035117: TEST_BUG: java/rmi/server/RemoteObject/notExtending/NotExtending.java can fail with timeout

Looks OK stuart. Another test I looked at last week but forgot to reply On Dec 16, 2014, at 12:40 PM, Stuart Marks wrote: > Hi, any reviewers for this changeset? > > Thanks, > > s'marks > > On 12/12/14 12:05 PM, Stuart Marks wrote: >> Hi all, >> >> Please review this small fix and cleanup t

Re: RFR(s): 8035117: TEST_BUG: java/rmi/server/RemoteObject/notExtending/NotExtending.java can fail with timeout

Hi, any reviewers for this changeset? Thanks, s'marks On 12/12/14 12:05 PM, Stuart Marks wrote: Hi all, Please review this small fix and cleanup to this test. The old version would force garbage collection of an unreferenced RMI object by allocating lots and lots of memory until OOME is recei

Re: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid

Hi Katja, This request should probably go to core-libs as well. Other than that I have just a few nits: test/java/util/logging/TestLoggerWeakRefLeak.java L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? L127: // in LogManager.loggers that *arebeing* properly managed -> *are

Re: Java implementation of Alpha-numeric comparator

Corrected the internal string example below to reflect the case intended. On 12/16/2014 9:58 AM, roger riggs wrote: Hi Ivan, In which package/class do you propose to add the API to get the comparator? In java.time, comparators are returned from static methods in an interface. This allows l

Re: Java implementation of Alpha-numeric comparator

Hi Ivan, In which package/class do you propose to add the API to get the comparator? In java.time, comparators are returned from static methods in an interface. This allows lambda to be used for the implementation. For example, ChronoZonedDateTime.timeLineOrder

Re: Documentation of methods in java.lang.Number

Andreas, this didn't get attention in the past. You can now find your report at https://bugs.openjdk.java.net/browse/JDK-8067669 I'll leave it up to maths engineers to determine if the Number API needs improving. regards, Sean. On 16/12/2014 12:55, Andreas Lundblad wrote: I've noticed that

Documentation of methods in java.lang.Number

I've noticed that the documentation of Number.longValue says: > Returns the value of the specified number as a long, which may involve > rounding or truncation. BigInteger and BigDecimal does not seem to honor this contract since they implement this method by masking out the lower bits of the n

Re: RFR JDK-8066867: Add InputStream transferTo to transfer content to an OutputStream

On 16 Dec 2014, at 11:35, Pavel Rappo wrote: > The latest webrev summing up all what we've talked so far: > > http://cr.openjdk.java.net/~prappo/8066867/webrev.02/ This looks good to me. Reviewed. Just a note on the attribution. I think it should include at least the following: Cont

Re: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible.

Hi Daniel, Thumbs up from me! Thanks, David On 16/12/2014 8:36 PM, Daniel Fuchs wrote: On 16/12/14 11:34, Daniel Fuchs wrote: Here is a new version where I have removed all the 'ClassLoaders' stuff. After all it was not instrumental to the test. Is that good to go? Forgot the link: http://

Re: RFR JDK-8066867: Add InputStream transferTo to transfer content to an OutputStream

The latest webrev summing up all what we've talked so far: http://cr.openjdk.java.net/~prappo/8066867/webrev.02/ -Pavel > On 15 Dec 2014, at 21:39, Patrick Reinhart wrote: > > > Have there been any further review being done jet? > >> Good catch, guys! >> >>> ...the method names are

Re: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible.

On 16/12/14 11:34, Daniel Fuchs wrote: Here is a new version where I have removed all the 'ClassLoaders' stuff. After all it was not instrumental to the test. Is that good to go? Forgot the link: http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.03/ sorry for the noise. -- daniel

Re: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible.

Hi David, On 12/16/14 6:20 AM, David Holmes wrote: On 16/12/2014 3:48 AM, Daniel Fuchs wrote: Hi guys, Do I have approval to push the latest version of the test for JDK 9: http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ or are there still some objections? My objections stan

Re: Java implementation of Alpha-numeric comparator

Got it, thanks! Please find the updated webrev at the same location: http://cr.openjdk.java.net/~igerasim/XXX-AlphaNumeric/1/webrev/ Sincerely yours, Ivan On 16.12.2014 11:23, Remi Forax wrote: On 12/16/2014 09:13 AM, Ivan Gerasimov wrote: Thanks Remi for the comments! As you and Roger

Re: Java implementation of Alpha-numeric comparator

On 12/16/2014 09:13 AM, Ivan Gerasimov wrote: Thanks Remi for the comments! As you and Roger suggested I only left a CharSequence variant of the comparator. I also removed the custom Comparator altogether for now, for the sake of simplicity. I guess for the purpose of a sample Character.com

Re: Java implementation of Alpha-numeric comparator

Thanks Remi for the comments! As you and Roger suggested I only left a CharSequence variant of the comparator. I also removed the custom Comparator altogether for now, for the sake of simplicity. I guess for the purpose of a sample Character.compare(ch1, ch2) should be good enough. Here's

Re: Java implementation of Alpha-numeric comparator

Thanks Naoto, good point! Since Character.isDigit is used to determine the numeric part of a string, the full width digits are already taken into account. I only had to modify handling of leading zeros: instead of comparing the character with '0', it's now checking if Character.digit(ch, 10) eq