Re: enhanced for loop with multiple iteration variables

Lambdas are clean, but limited in current Java compared to nested blocks. Are full featured lambdas on the horizon? If not, then we still need loops and iterators. Alan > On Dec 20, 2018, at 3:00 PM, Remi Forax wrote: > > or > map.forEach((key, value) -> { >... > }); > > Rémi > >

Re: enhanced for loop with multiple iteration variables

RIght, but I don’t see that as a general solution. Its also a bit kludgy, like saying that methods need only one parameter because you can always pass a data object. > On Dec 20, 2018, at 2:50 PM, Brian Goetz wrote: > > For Map, you can do: > > for (Map.Entry e : map.entrySet()) { ... } >

8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException

https://bugs.openjdk.java.net/browse/JDK-8215759 http://cr.openjdk.java.net/~bpb/8215759/webrev.00/ Although highly unlikely, the modulus parameter of modPow() can be zero which would provoke an ArithmeticException. Unsure whether I need this bug ID in the @bug list. Thanks, Brian

Re: enhanced for loop with multiple iteration variables

or map.forEach((key, value) -> { ... }); Rémi - Mail original - > De: "Brian Goetz" > À: "Alan Snyder" , "core-libs-dev" > > Envoyé: Jeudi 20 Décembre 2018 23:50:15 > Objet: Re: enhanced for loop with multiple iteration variables > For Map, you can do: > >     for (Map.Entry

Re: enhanced for loop with multiple iteration variables

For Map, you can do:     for (Map.Entry e : map.entrySet()) { ... } and you're already there. On 12/19/2018 9:54 AM, Alan Snyder wrote: Has any consideration been given to supporting iterators that provide more than one iteration variable in the enhanced for loop? Obvious uses would be map

Re: RFR - CSR JDK-8215490 Remove String::align

Is String::transform going to be removed as well given the removal of raw strings and its controversial nature? Stephen On Wed, 19 Dec 2018 at 19:50, Jim Laskey wrote: > > CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 > > > Thank you. >

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

Hi Roger, Thank you. I am OK with the current version of the patch. Happy Holidays! Best Lance > On Dec 20, 2018, at 10:50 AM, Roger Riggs wrote: > > Hi Lance, > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-8066619-5.patch/ > > Phillip does not yet have access to cr.openjdk.java.

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Hi Vincent, This looks good. The doc for HEXDUMP_FORMATTER should include an example of the formatting. Its easier to see it than to reconstruct it from the example code. like:       61 62 63 64 65 66 67 68  69 6a 6b 6c 6d 6e 6f 70 |abcdefghijklmnop|     0010  71 72 73 74 75 76 77 7

Re: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)

I wrote the following simple test case to look at the uniformity of the distribution. I don't see any problem running it up to 4096 buckets. Admittedly I did not do any statistical tests on the buckets but by eye they look uniformly distributed. public static void main(String[] args) throws

Re: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)

Correction: Half have bit length 4, 25% 3, ... > On Dec 20, 2018, at 9:08 AM, Brian Burkhalter > wrote: > > Half of the values have bit length 4, 25% have bit length 2, etc.

Re: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)

Thanks for the comments. It looks like I got this completely wrong. For some reason I was thinking that the distribution of bit lengths should be uniform which is patently incorrect. Consider the example of a four bit integer. The possible values are 1110 1101 1100 1011 1010 1001 1000 0111

Re: RFR - JDK-8215493 String::indent inconsistency with blank lines

Thanks, looks fine.  Roger On 12/20/2018 11:46 AM, James Laskey wrote: It’s there. AlignIndent.java. Sent from my iPhone On Dec 20, 2018, at 12:10 PM, Roger Riggs wrote: Hi Jim, Is there a missing test? I'd expect to see a corresponding test change also. otherwise, looks fine. Regards,

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Hello, For some other libs test using randomness, we've been able to track down and fix bugs only after a seed value was printed and usable for reproducing the problem, see the history of: * JDK-6854417: "testbug: java/util/regex/RegExTest.java fails intermittently." * JDK-804: Rare bug

Re: RFR - JDK-8215493 String::indent inconsistency with blank lines

It’s there. AlignIndent.java. Sent from my iPhone > On Dec 20, 2018, at 12:10 PM, Roger Riggs wrote: > > Hi Jim, > > Is there a missing test? I'd expect to see a corresponding test change also. > > otherwise, looks fine. > > Regards, Roger > > >> On 12/19/2018 03:13 PM, Jim Laskey wrote

Re: RFR - JDK-8215493 String::indent inconsistency with blank lines

Hi Jim, Is there a missing test?  I'd expect to see a corresponding test change also. otherwise, looks fine. Regards, Roger On 12/19/2018 03:13 PM, Jim Laskey wrote: Please review these changes for jdk 12. webrev: http://cr.openjdk.java.net/~jlaskey/8215493/webrev/index.html

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

Hi Lance, Webrev:   http://cr.openjdk.java.net/~rriggs/webrev-8066619-5.patch/ Phillip does not yet have access to cr.openjdk.java.net. $.02, Roger On 12/20/2018 09:17 AM, Lance Andersen wrote: Hi Philipp, The tests look better. Any chance you can post the webrev in the future vs the patch

Re: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)

Hi Brian, I don't quite understand this reasoning. I need some explanation... You are talking about the distribution of BigInteger values (not the bit lengths of the values), obtained with constructor BigInteger(int, java.util.Random) for which the javadoc says: * Constructs a randomly

Re: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)

I'm not sure what the problem is. If X is uniform, then "the number of leading zero bits" of X is exponential. The probability of getting a "small" number, in which the first (say) 32 bits are 0 is 2^-32. If this is what is measured by the histrogram[5], then the current implementation looks co

Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

Hi Philipp, The tests look better. Any chance you can post the webrev in the future vs the patch as it makes it easer to review. Best Lance > On Dec 19, 2018, at 1:24 AM, Philipp Kunz wrote: > > now with assertThrows. Find a new patch attached. > > On Tue, 2018-12-18 at 13:38 -0800, Martin B

Re: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)

Hm strange, never saw it this way. Would other types have the same problem (should be visible in your histogram for long as well, right?) Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Brian Burkhalter Gesendet: Donnerstag, Dezembe

Re: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly

Hi Liam, I read the spec bugs, we had a similar discussion a few years ago about the scoping. Given how all implementations of javac have behaved for the last 4 years or so, I agree this is the right fix. Thanks for the extra test. Ship it! cheers /Joel On Wed, Dec 19, 2018 at 8:19 PM Liam Mill