Re: enhanced for loop with multiple iteration variables

[Alan Snyder]

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
> 
> - 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 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 maps (keys and values) and lists (indexes and values).
>>> 
>>> I have in mind keeping the syntactic sugar approach by using one or more
>>> extensions of the Iterator/Iterable interfaces, such as, for example:
>>> 
>>> interface Iterator2 extends Iterator {
>>>   E2 get2();
>>> }
>>> 
>>> with the extra methods providing the values for the extra variables 
>>> (associated
>>> with the previous call to next).
>>> 
>>> Extending interfaces is not required, but it makes the trailing variables
>>> optional, which might be useful. For example, the same iterator could 
>>> provide
>>> values or values and keys.
>>> 
>>> The fact that this approach only works for a fixed set of numbers of 
>>> variables
>>> does not bother me unduly.
>>> 
>>>   Alan
> 

Re: enhanced for loop with multiple iteration variables

[Alan Snyder]

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()) { ... }
> 
> 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 maps (keys and values) and lists (indexes and values).
>> 
>> I have in mind keeping the syntactic sugar approach by using one or more 
>> extensions of the Iterator/Iterable interfaces, such as, for example:
>> 
>> interface Iterator2 extends Iterator {
>>   E2 get2();
>> }
>> 
>> with the extra methods providing the values for the extra variables 
>> (associated with the previous call to next).
>> 
>> Extending interfaces is not required, but it makes the trailing variables 
>> optional, which might be useful. For example, the same iterator could 
>> provide values or values and keys.
>> 
>> The fact that this approach only works for a fixed set of numbers of 
>> variables does not bother me unduly.
>> 
>>   Alan
>> 
> 

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

[Brian Burkhalter]

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

[Remi Forax]

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 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 maps (keys and values) and lists (indexes and values).
>>
>> I have in mind keeping the syntactic sugar approach by using one or more
>> extensions of the Iterator/Iterable interfaces, such as, for example:
>>
>> interface Iterator2 extends Iterator {
>>E2 get2();
>> }
>>
>> with the extra methods providing the values for the extra variables 
>> (associated
>> with the previous call to next).
>>
>> Extending interfaces is not required, but it makes the trailing variables
>> optional, which might be useful. For example, the same iterator could provide
>> values or values and keys.
>>
>> The fact that this approach only works for a fixed set of numbers of 
>> variables
>> does not bother me unduly.
>>
>>Alan

Re: enhanced for loop with multiple iteration variables

[Brian Goetz]

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 maps (keys and values) and lists (indexes and values).

I have in mind keeping the syntactic sugar approach by using one or more 
extensions of the Iterator/Iterable interfaces, such as, for example:

interface Iterator2 extends Iterator {
   E2 get2();
}

with the extra methods providing the values for the extra variables (associated 
with the previous call to next).

Extending interfaces is not required, but it makes the trailing variables 
optional, which might be useful. For example, the same iterator could provide 
values or values and keys.

The fact that this approach only works for a fixed set of numbers of variables 
does not bother me unduly.

   Alan

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

[Stephen Colebourne]

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.
>
> Cheers,
>
> — Jim
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8215489 
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html
>

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

[Lance Andersen]

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.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 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 Buchholz wrote:
 On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen >>> >
 wrote:
 
> 
> 
> Is there a reason you did not use
> 
> @Test(expectedExceptions = IOException.class)
> 
> It just seems to make the test a bit more readable
> 
> That construct has lost popularity over the past decade, sort of like
 inheritance is no longer considered a silver bullet.
>>> <8066619.patch>
>>  
>>   
>> 
>>  Lance Andersen| 
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> lance.ander...@oracle.com 
>> 
>> 
>> 
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

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

[Roger Riggs]

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 78  79 7a    
|qrstuvwxyz|


I'm not sure the reference to hexdump(1) is useful, it could be removed
without loss of precision or usefulness.

Thanks, Roger


On 12/12/2018 01:21 PM, Vincent Ryan wrote:

FYI I’ve updated the webrev/javadoc with latest edits including the 2 new 
ByteBuffer methods:

http://cr.openjdk.java.net/~vinnie/8170769/webrev.09/ 

http://cr.openjdk.java.net/~vinnie/8170769/javadoc.09/api/java.base/java/util/HexFormat.html
 

(NOTE: internal link to HexFormat.Formatter class is currently broken)


If that is an acceptable compromise then I believe all outstanding issues have 
now been addressed.
Thanks to all those who provided review comments.



On 12 Dec 2018, at 12:32, Vincent Ryan  wrote:

Thanks for your proposal.
Comments below.


On 12 Dec 2018, at 02:35, Stuart Marks  wrote:



On 12/11/18 1:21 PM, Vincent Ryan wrote:

My preference is for PrintStream rather than Writer, for the same reason as 
Roger: it’s more convenient
for handling System.out. Does that address your concern?

PrintStream is fine with me.


I cannot simply cast 8859-1 characters into UTF-8 because UTF-8 is multi-byte 
charset so some 0x8X characters
Will trigger the multi-byte sequence and will end up being misinterpreted. 
Hence my rather awkward conversion to a String.
Is there a better way?

In toPrintableString(),

259 StringBuilder printable = new StringBuilder(toIndex - fromIndex);
260 for (int i = fromIndex; i < toIndex; i++) {
261 if (bytes[i] > 0x1F && bytes[i] < 0x7F) {
262 printable.append((char) bytes[i]);
263 } else if (bytes[i] > (byte)0x9F && bytes[i] <= (byte)0xFF) {
264 printable.append(new String(new byte[]{bytes[i]}, 
ISO_8859_1));
265
266 } else {
267 printable.append('.');
268 }
269 }

It works to cast ASCII bytes char, because the 7-bit ASCII range overlaps the 
low 7 bits of the UTF-16 char range. The bytes values of ISO 8859-1 overlap the 
low 8 bits of UTF-16, so casts work for them too.

For any other charset, you'd need to do codeset conversion. But you're cleverly 
supporting only ISO 8859-1, so you don't have to do any conversion. :-)


I’m not sure I’ve addressed your concern regarding IOExceptions - can you 
elaborate?

Taking out the OutputStream overloads addressed my concerns. In at least one 
case the code would wrap the OutputStream into a PrintStream, print stuff to 
it, and then throw away the PrintStream. If an output error occurred, any error 
state in the PrintStream would also be thrown away. The creation of the 
PrintStream wrapper would also use the system's default charset instead of 
letting the caller control it.

The dump() overloads now all take PrintStream, so it's the caller's 
responsibility to ensure that the PrintStream is using the right charset and to 
check for errors after. So this is all OK now.

Note that the internal getPrintStream(), to wrap an OutputStream in a 
PrintStream, is now obsolete and can be removed.

(Oh, I see Roger has said much the same things. Oh well, the peril of parallel 
reviews.)

**


BTW updated webrev/javadoc available:
http://cr.openjdk.java.net/~vinnie/8170769/webrev.08/
http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html

Now we have a somewhat unsatisfying asymmetry in the APIs.

There are four kinds of inputs:

1. byte[]
2. byte[] subrange
3. InputStream
4. ByteBuffer

and two kinds of outputs:

1. PrintStream
2. Stream

and two variations of formatters:

1. default formatter
2. custom formatter + chunk size

This is a total of 16 combinations. But there are only eight methods: three 
PrintStream methods with choice of input, two stream-output methods using the 
default formatter, and three stream-output methods using custom chunk+formatter.

You don't have to provide ALL combinations, but what's here is an odd subset 
with some apparently arbitrary choices. For example, if I have a ByteBuffer and 
I want to dump it to System.out using default formatting, I have to go the 
Stream.forEachOrdered route AND provide the default chunk size and formatter.

   HexFormat.dumpAsStream(buf, DEFAULT_CHUNK_SIZE, HEXDUMP_FORMATTER)
.forEachOrdered(System.out::println);

These aren't huge deals, but they're easily stumbled over.

One approach to organizing this is to have a HexFormat instance that contains 
the setup information and then to have instance methods that either update the 
setup or perform 

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

[Douglas Surber]

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 Throwable {
SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
final int nBits = 4096;
final int nBuckets = 128;
final int count = 10;
Pair[] buckets = new Pair[nBuckets];
BigInteger max = BigInteger.TWO.pow(nBits);
BigInteger limit = max;
BigInteger step = limit.divide(BigInteger.valueOf(buckets.length));
for (int i = 0; i < buckets.length; i++) buckets[i] = new Pair(limit = 
limit.subtract(step));
for (int i = 0; i < count; ++i) {
  // biased towards high numbers. never chooses below a high limit 
  BigInteger number = new BigInteger(nBits, sr);
  int j;
  for (j = 0; buckets[j].limit.compareTo(number) > 0; j++) {}
  buckets[j].count++;
}
for (int i = buckets.length; i > 0; i--) 
System.out.print(buckets[i-1].count + (i%8==0 ? "\n" : "\t"));
System.out.println();
  }


Douglas

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

[Brian Burkhalter]

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)

[Brian Burkhalter]

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 0110 0101 0100
0011 0010
0001


Half of the values have bit length 4, 25% have bit length 2, etc. Re-running my 
test code shows pretty much this sort of distribution of the bit lengths. It 
looks like the likelihood of bit lengths from the largest length downward is a 
geometric sequence with initial value 0.5 for the largest bit length and common 
ratio 0.5. So I concur with Adam that the current implementation looks correct. 
Therefore I think that [1] should be withdrawn and [2] closed as not an issue.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8215441
[2] https://bugs.openjdk.java.net/browse/JDK-8146153

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

[Roger Riggs]

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, 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 


There is inconsistency with regards to blank lines and indentation. Adding indent space 
ignores blank lines, where subtraction indentation white space does not ignore blank 
lines. The solution is to remove the condition "Blank lines are unaffected" 
from the specification with appropriate changes to the implementation.

Thank you.

Cheers,

— Jim

CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 

JBS: https://bugs.openjdk.java.net/browse/JDK-8215493 

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

[Joe Darcy]

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 in JISAutodetect charset detected by 
FindDecoderBugs test


The bad values which trigger the bug might only a very small subset of 
the full space. For the latter bug which was tracked down once the seed 
made the situation reproducible, see this comment from Martin in 2015 :-)


Sherman: Thanks for fixing this.  I've observed this in the wild a 
couple of times myself.


(Although flaky tests are annoying, finding actual bugs makes it so 
worth it!)


http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034836.html

Please using the testing randomness library and the randomness jtreg 
keyword. The keyword helps guide failure analysis.


Thanks,

-Joe


On 12/19/2018 7:15 AM, Martin Buchholz wrote:

On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs  wrote:


Hi Martin,

It is also useful and conventional to print the seed of the random
so that if necessary it can be reproduced.


For many years, we've been using ThreadLocalRandom for testing, and that
does not allow setting a seed.

I remain unconvinced that saving a seed has value in the real world.  When
a randomized test fails, running it with sufficient iterations has always
worked for me.

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

[James Laskey]

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:
>> Please review these changes for jdk 12.
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8215493/webrev/index.html 
>> 
>> 
>> There is inconsistency with regards to blank lines and indentation. Adding 
>> indent space ignores blank lines, where subtraction indentation white space 
>> does not ignore blank lines. The solution is to remove the condition "Blank 
>> lines are unaffected" from the specification with appropriate changes to the 
>> implementation.
>> 
>> Thank you.
>> 
>> Cheers,
>> 
>> — Jim
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215493 
>> 
>> 
>> 
> 

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

[Roger Riggs]

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 


There is inconsistency with regards to blank lines and indentation. Adding indent space 
ignores blank lines, where subtraction indentation white space does not ignore blank 
lines. The solution is to remove the condition "Blank lines are unaffected" 
from the specification with appropriate changes to the implementation.

Thank you.

Cheers,

— Jim

CSR: https://bugs.openjdk.java.net/browse/JDK-8215499 

JBS: https://bugs.openjdk.java.net/browse/JDK-8215493 

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

[Roger Riggs]

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 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 Buchholz wrote:

On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen mailto:lance.ander...@oracle.com>>
wrote:




Is there a reason you did not use

@Test(expectedExceptions = IOException.class)

It just seems to make the test a bit more readable

That construct has lost popularity over the past decade, sort of like

inheritance is no longer considered a silver bullet.

<8066619.patch>

  
   

  Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

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

[Peter Levart]

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 generated BigInteger, uniformly 
distributed over

 * the range 0 to (2{@code numBits} - 1), inclusive.
 * The uniformity of the distribution assumes that a fair source of 
random

 * bits is provided in {@code rnd}.  Note that this constructor always
 * constructs a non-negative BigInteger.

I think that the javadoc meant to say that the *values* of the 
BigIntegers constructed are uniformly distributed...


On 12/20/18 5:01 AM, Brian Burkhalter wrote:

https://bugs.openjdk.java.net/browse/JDK-8215441

This issue was filed to cover improving the uniformity of randomly generated 
BigIntegers. It is not intended to resolve [1] which is deliberately left open. 
The proposed patch implements a modified version of the “workaround” suggested 
in [1].

The problem is that the magnitude of the random BigInteger is created from a 
sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any 
of these bytes is zero is small


It should be 1/256 right? If the bytes returned by Random.nextBytes() 
are good random bytes, they are independent and their distribution is 
uniform. So the likelihood of an individual byte being 0 is 
approximately the same as the likelihood of it being any particular 
other byte value. As there are 256 different values a byte can have, 
this amounts to 1/256...



  so the distribution of the resulting random BigIntegers is skewed towards 
values close to the maximum bit size “numBits” specified to the constructor.


I think that's a normal consequence of uniform distribution of values. 
The "bit length" of a BigInteger value is the index of its highest 1 bit 
(+1 counted from lowest bit0). Say you produce a uniformly distributed 
random BigInteger in range 0 ... 2^8 - 1 (the bitLength constructor 
parameter being 8 in this case)


The probability that you get an integer with "bit length" of 8 is 1/2 
(that's the probability of a uniformly distributed 8 bit integer having 
the highest bit 1)... 1XXX
The probability that you get an integer with "bit lenght" of 7 is 1/4 
(that's the probability of a uniformly distributed 8 bit integer having 
the highest bit 0 and the next to highest bit 1)... 01XX

Probability you get bit length 6 is 1/8 ... 001X
Probability you get bit length 5 is 1/16 ... 0001
Probability you get bit length 4 is 1/32 ... 1XXX
Probability you get bit length 3 is 1/64 ... 01XX
Probability you get bit length 2 is 1/128 ... 001X
Probability you get bit length 1 is 1/256 ... (the probability of 
getting value 1) ... 0001
Probability you get bit length 0 is 1/256 ... (the probability of 
getting value 0) ... 


In general, the probability that you get an integer with bit length N is 
equal to the probability that you get an integer with bit length < N.


The probability that you get 0 from BigInteger random constructor when 
you pass to it numBits is 1/(2^numBits). When you choose 256 for 
numBits, that's a very slim probability. Practically zero. Let alone 
when you choose 4096.




The workaround suggested in [1] is to randomly change numBits to the value 
numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround 
is nextInt(numBits) which is incorrect as the parameter is an exclusive upper 
bound.) This greatly improves the uniformity of the distribution. A remaining 
problem however is that now the very largest numbers in the interval 
[0,2^numBits) are underrepresented. A modification of this approach is to 
increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 
[4]. This was empirically observed to improve the underrepresentation of the 
largest values.

The distribution of the random BigIntegers was estimated using [5]. For a given 
maximum bit length, bin size, and number of random values to generate, this 
creates a histogram and calculates the coefficient of variation of the numbers 
generated. The histogram bin at index zero represents the largest valued bin in 
the result. The count in a given histogram bin is the number of values for 
which that bin is the leftmost (largest valued) with at least one non-zero bit. 
The bin of maximum index represents zero.


What exactly are you trying to show with this code? I'm strugling to 
understand it...


If you wanted to show the distribution of BigInteger values into equally 
sized bins by the value (each bin representing the sub-interval in the 
interval 0 ... 2^numBits -1) then the code would be much simpler. But 
you are trying to show something else... What is that?


Regards, Peter

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

[Adam Petcher]

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 correct to me.


On 12/19/2018 11:01 PM, Brian Burkhalter wrote:

https://bugs.openjdk.java.net/browse/JDK-8215441

This issue was filed to cover improving the uniformity of randomly generated 
BigIntegers. It is not intended to resolve [1] which is deliberately left open. 
The proposed patch implements a modified version of the “workaround” suggested 
in [1].

The problem is that the magnitude of the random BigInteger is created from a 
sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any 
of these bytes is zero is small so the distribution of the resulting random 
BigIntegers is skewed towards values close to the maximum bit size “numBits” 
specified to the constructor.

The workaround suggested in [1] is to randomly change numBits to the value 
numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround 
is nextInt(numBits) which is incorrect as the parameter is an exclusive upper 
bound.) This greatly improves the uniformity of the distribution. A remaining 
problem however is that now the very largest numbers in the interval 
[0,2^numBits) are underrepresented. A modification of this approach is to 
increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 
[4]. This was empirically observed to improve the underrepresentation of the 
largest values.

The distribution of the random BigIntegers was estimated using [5]. For a given 
maximum bit length, bin size, and number of random values to generate, this 
creates a histogram and calculates the coefficient of variation of the numbers 
generated. The histogram bin at index zero represents the largest valued bin in 
the result. The count in a given histogram bin is the number of values for 
which that bin is the leftmost (largest valued) with at least one non-zero bit. 
The bin of maximum index represents zero.

Results for the current and two modified approaches for 256 bits with a 1-bit 
bin size and for 4096 bits with a 4-bit bin size are given at [6-11]. As may be 
observed, the original histogram is clustered towards the largest possible 
value 2^numBits - 1, and the coefficient of variation is small. The results for 
the two variants of the patch show a flattened distribution, i.e., more 
uniform, and a significantly larger coefficient of variation. The second 
approach shows better flattening of both ends of the histogram. These results 
are samples only but are exemplary of the results observed over numerous runs 
of this code.

The test ModPow is modified as the modPow() method throws an 
ArithmeticException for a zero modulus. The current algorithm never generates a 
random BigInteger equal to zero however so that exception never occurs. That is 
not the case for either modified version.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8146153
[2] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html#nextBytes(byte[])
[3] http://cr.openjdk.java.net/~bpb/8146153/webrev.00/
[4] http://cr.openjdk.java.net/~bpb/8146153/webrev.01/
[5] http://cr.openjdk.java.net/~bpb/8146153/StatsBigIntegerRandom.java
[6] http://cr.openjdk.java.net/~bpb/8146153/before-256-1.txt
[7] http://cr.openjdk.java.net/~bpb/8146153/after-256-1.txt
[8] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-256-1.txt
[9] http://cr.openjdk.java.net/~bpb/8146153/before-4096-4.txt
[10] http://cr.openjdk.java.net/~bpb/8146153/after-4096-4.txt
[11] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-4096-4.txt

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

[Lance Andersen]

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 Buchholz wrote:
>> On Tue, Dec 18, 2018 at 1:13 PM Lance Andersen > >
>> wrote:
>> 
>>> 
>>> 
>>> 
>>> Is there a reason you did not use
>>> 
>>> @Test(expectedExceptions = IOException.class)
>>> 
>>> It just seems to make the test a bit more readable
>>> 
>>> That construct has lost popularity over the past decade, sort of like
>> 
>> inheritance is no longer considered a silver bullet.
> <8066619.patch>

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

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

[Bernd Eckenfels]

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, Dezember 20, 2018 8:03 AM
An: core-libs-dev
Betreff: 8215441: Increase uniformity of the distribution of BigIntegers 
constructed by BigInteger(int, Random)

https://bugs.openjdk.java.net/browse/JDK-8215441

This issue was filed to cover improving the uniformity of randomly generated 
BigIntegers. It is not intended to resolve [1] which is deliberately left open. 
The proposed patch implements a modified version of the “workaround” suggested 
in [1].

The problem is that the magnitude of the random BigInteger is created from a 
sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any 
of these bytes is zero is small so the distribution of the resulting random 
BigIntegers is skewed towards values close to the maximum bit size “numBits” 
specified to the constructor.

The workaround suggested in [1] is to randomly change numBits to the value 
numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround 
is nextInt(numBits) which is incorrect as the parameter is an exclusive upper 
bound.) This greatly improves the uniformity of the distribution. A remaining 
problem however is that now the very largest numbers in the interval 
[0,2^numBits) are underrepresented. A modification of this approach is to 
increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 
[4]. This was empirically observed to improve the underrepresentation of the 
largest values.

The distribution of the random BigIntegers was estimated using [5]. For a given 
maximum bit length, bin size, and number of random values to generate, this 
creates a histogram and calculates the coefficient of variation of the numbers 
generated. The histogram bin at index zero represents the largest valued bin in 
the result. The count in a given histogram bin is the number of values for 
which that bin is the leftmost (largest valued) with at least one non-zero bit. 
The bin of maximum index represents zero.

Results for the current and two modified approaches for 256 bits with a 1-bit 
bin size and for 4096 bits with a 4-bit bin size are given at [6-11]. As may be 
observed, the original histogram is clustered towards the largest possible 
value 2^numBits - 1, and the coefficient of variation is small. The results for 
the two variants of the patch show a flattened distribution, i.e., more 
uniform, and a significantly larger coefficient of variation. The second 
approach shows better flattening of both ends of the histogram. These results 
are samples only but are exemplary of the results observed over numerous runs 
of this code.

The test ModPow is modified as the modPow() method throws an 
ArithmeticException for a zero modulus. The current algorithm never generates a 
random BigInteger equal to zero however so that exception never occurs. That is 
not the case for either modified version.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8146153
[2] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html#nextBytes(byte[])
[3] http://cr.openjdk.java.net/~bpb/8146153/webrev.00/
[4] http://cr.openjdk.java.net/~bpb/8146153/webrev.01/
[5] http://cr.openjdk.java.net/~bpb/8146153/StatsBigIntegerRandom.java
[6] http://cr.openjdk.java.net/~bpb/8146153/before-256-1.txt
[7] http://cr.openjdk.java.net/~bpb/8146153/after-256-1.txt
[8] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-256-1.txt
[9] http://cr.openjdk.java.net/~bpb/8146153/before-4096-4.txt
[10] http://cr.openjdk.java.net/~bpb/8146153/after-4096-4.txt
[11] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-4096-4.txt

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

[Joel Borggrén-Franck]

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 Miller-Cushon  wrote:
>
> Hi Joel,
>
> I think this fix is appropriate for the other uses of nestingForType.
>
> The underlying problem here is the treatment of nested types in general, 
> which directly affects getAnnotatedOwnerType, but also applies to the 
> examples in JDK-8066967.
>
> I added an additional test based on the one in JDK-8066967:
> http://cr.openjdk.java.net/~cushon/8198526/webrev.02/
>
> Re: JDK-8148504, javac consistently emits type_path_kind=1 entries for nested 
> types when there are multiple parts for which type annotations are 
> admissable. That wasn't consistent with JVMS 11, which expects 
> type_path_kind=1 entries for all nested types (regardless of whether the 
> enclosing type is admissable for annotations). The resolution was to update 
> the spec in JDK-8215035 and leave javac's behaviour unchanged, and this 
> change is updating reflection to be consistent with the updated spec and the 
> existing javac behaviour.