Re: RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators

[Jiangli Zhou]

Hi Claes,

Moving the use of SALT to iterator creation is a great idea! You change looks 
really good.

Thanks for making the change!

Jiangli

> On Apr 18, 2018, at 8:20 AM, Claes Redestad  wrote:
> 
> Hi,
> 
> please review this change that moves the use of SALT to iterator creation, 
> which would allow for certain startup
> optimizations in the future.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201650
> Webrev: http://cr.openjdk.java.net/~redestad/8201650/open.00/
> 
> This does make the randomness of iteration order weaker as we're only 
> randomizing the starting point (varying with
> the size of the collection) and the iteration direction (run-to-run variant; 
> weaker than calculating per size, but
> allows this patch to be performance neutral).
> 
> Some Set/Map operations become very slightly faster with this patch, but 
> that's in the noise. Iterator operations
> remain largely performance neutral, sometimes even a bit faster.
> 
> Thanks!
> 
> /Claes
> 
> 
> 

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

[David Holmes]

Adding back hotspot-runtime-dev  - please reply-all

On 19/04/2018 1:26 AM, Roger Riggs wrote:

Hi,

Also, the new constructor should be public so it can be used in other 
places.


That takes this from being a simple change that adds more info to the 
exception message, to an API addition that requires a CSR etc. That 
changes the scope considerably.


I'm not 100% clear why we need to change the Java side of this when we 
can push a message with the desired info from the VM side?


David

It seems in some cases the error message is a literal in the VM code ( 
typeArrayKlass.cpp:149).

That would seem to be a duplication and not really a good idea.

Roger


On 4/18/18 10:30 AM, Roger Riggs wrote:

Hi,

The message can be simpler and more efficiently convey the information.
It should be more consistent with existing uses of 
ArrayIndexOutOfBoundsException as

throw by:  Objects.checkIndex(index, length).

Which roughly reads as:

   Index %d out-of-bounds for length %d

Regards, Roger

On 4/18/18 4:54 AM, David Holmes wrote:
Adding core-libs-dev as you're changing 
java.lang.ArrayIndexOutOfBoundsException.


I appreciate the intent here but I find the messages excessively 
verbose. The basic error is:


index N is outside range [0, length-1]

David

On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote:

Hi,

I would like to print a more verbose text on ArrayIndexOutOfBounds 
exception
that not only mentions the index, but also the length of the array 
accessed.

See the bug for documentation of the change of the message.
http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/

@aarch/arm people:
I edited the aarch/arm files. Could you please verify this is correct?
I can not build on these platforms.

The code on all the other platforms is tested with all the jtreg and 
jck tests etc.


Best regards,
   Goetz.

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

[David Lloyd]

+1 from me, thanks!

On Wed, Apr 18, 2018 at 3:09 PM, Xueming Shen  wrote:
> Alan, David,
>
> Any more update/comment/suggestion on this one? I have updated
> DeInflate.java with
> some new test cases to cover the newly added methods. Good to go?
>
> -Sherman
>
> On 04/10/2018 08:49 PM, Xueming Shen wrote:
>>
>>
>>
>> http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/
>>
>> Thanks,
>> Sherman
>>
>



-- 
- DML

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

[Xueming Shen]

Alan, David,

Any more update/comment/suggestion on this one? I have updated DeInflate.java 
with
some new test cases to cover the newly added methods. Good to go?

-Sherman

On 04/10/2018 08:49 PM, Xueming Shen wrote:



http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/

Thanks,
Sherman

Re: RFR: 8184693: (opt) add Optional.isEmpty

[Roger Riggs]

+1

There is one extra space in Optional.java: line 163:  "is__not".

Thanks, Roger


On 4/18/18 2:06 AM, Stuart Marks wrote:

OK, looks good! +1 from me.

s'marks

On 4/17/18 10:34 PM, Vivek Theeyarath wrote:

Hi Stuart,
Done with the changes 
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.05/ .

Regards
Vivek
-Original Message-
From: Stuart Marks
Sent: Wednesday, April 18, 2018 8:56 AM
To: Vivek Theeyarath 
Cc: core-libs-dev ; Paul Sandoz 


Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty

Hi Vivek,

Thanks for the update. In the test files, please remove the 
unnecessary imports of List and the various Predicate types. In most 
cases it's not a problem to have unnecessary imports. I happened to 
notice in this case that they're left over from the previous version 
of the webrev, and looking at the current webrev by itself, it's 
clear they're unnecessary.


Thanks,

s'marks

On 4/17/18 6:23 AM, Vivek Theeyarath wrote:

Hi All,
Please find the updated webrev
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.04
Regards
Vivek

-Original Message-
From: Stuart Marks
Sent: Tuesday, April 17, 2018 5:11 AM
To: Vivek Theeyarath 
Cc: core-libs-dev ; Paul Sandoz

Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty

Hi Vivek,

Please add "@since 11" tags to the doc comments of the four 
Optional*.isEmpty() methods.


Regarding the tests, I don't think the various newly added 
testIsEmpty() tests are useful. The setup in those test files 
already generates a fairly comprehensive set of Optional values from 
a variety of sources. All the assertion checking is performed in the 
checkEmpty() and checkPresent() methods.
It should be sufficient to add an assertTrue(isEmpty()) call to 
checkEmpty() -- as you've done -- and also to add an 
assertFalse(isEmpty()) call to checkPresent(). If these assertions 
are added, the additional testIsEmpty() test is unnecessary.


This applies to all four of the regression test files.

Thanks,

s'marks

On 4/16/18 11:08 AM, Vivek Theeyarath wrote:

Hi All,
Please find the updated webrev 
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ .

Here is the csr which I have raised for this change
https://bugs.openjdk.java.net/browse/JDK-8201606

Regards
Vivek
-Original Message-
From: Chris Hegarty
Sent: Sunday, April 15, 2018 6:48 PM
To: Vivek Theeyarath 
Cc: Remi Forax ; core-libs-dev

Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty



On 15 Apr 2018, at 11:25, Vivek Theeyarath 
 wrote:


Hi All,
  Please review
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/


This looks ok to me.

For consistency, can you please update the copyright header year 
range in OptionalInt.


-Chris.


Regards
Vivek
-Original Message-
From: Vivek Theeyarath
Sent: Saturday, April 14, 2018 6:24 PM
To: Remi Forax 
Cc: core-libs-dev 
Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty

I missed that Remi. Thanks for pointing it out. Will address those 
and get back.


Regards
Vivek
-Original Message-
From: Remi Forax [mailto:fo...@univ-mlv.fr]
Sent: Saturday, April 14, 2018 2:58 PM
To: Vivek Theeyarath 
Cc: core-libs-dev 
Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty

Hi Vivek,
OptionalInt, OptionalLong and OptionalDouble should be changed too.

Rémi

- Mail original -

De: "Vivek Theeyarath" 
À: "core-libs-dev" 
Envoyé: Samedi 14 Avril 2018 08:22:50
Objet: RFR: 8184693: (opt) add Optional.isEmpty



Hi All,

    Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8184693

Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/



The related jtreg test was run and the test passed .



Regards

Vivek

[PATCH] minor regex cleanup: use switch for enum

[Isaac Levy]

Hi,

Minor improvement in readability (and probably perf) for Pattern. Switch is
more consistent with the rest of the impl and the resulting tableswitch
avoids a comparison for possessives.

-Isaac

--- a/src/java.base/share/classes/java/util/regex/Pattern.java
+++ b/src/java.base/share/classes/java/util/regex/Pattern.java
@@ -4356,7 +4356,9 @@
-if (type == Qtype.GREEDY)
+switch (type) {
+case GREEDY:
 return match0(matcher, i, j, seq);
-else if (type == Qtype.LAZY)
+case LAZY:
 return match1(matcher, i, j, seq);
-else
+default:
 return match2(matcher, i, j, seq);
+}

@@ -4527,7 +4529,10 @@
-if (type == Qtype.GREEDY) {
+switch (type) {
+case GREEDY:
 ret = match0(matcher, i, cmin, seq);
+break;
-} else if (type == Qtype.LAZY) {
+case LAZY:
 ret = match1(matcher, i, cmin, seq);
+break;
-} else {
+default:
 ret = match2(matcher, i, cmin, seq);
 }

Re: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding

[Roger Riggs]

Hi Pallavi,

The fix here seems to make padding to a fixed width incompatible with 
adjacent value parsing.
That's not intuitive, since adjacent value parsing is intended to allow 
more flexible parsing
of a combination leading fixed-width fields and subsequent variable 
length fields.
The specification of the behavior of padding vs adjacent value parsing 
should be investigated

and clarified if necessary.

The implementation would be better expressed as checking whether the 
active PrinterParser
*is* a NumberPrinterParser as a precondition for entering the adjacent 
parsing mode block

(and the necessary cast).
And otherwise, fall into the existing code in which the new Parser 
becomes the new active parser.


The tests should be included in the existing test classes for padding, 
and be written using
the direct DateTimeFormatterBuilder methods (padNext(), instead of the 
patterns) since the patterns

are just a front end for the builder methods.
See test/java/time/format/TestPadPrinterDecorator.java

TestDateTimeFormatter.java:

line 96: please keep the static imports for testng together

Line 662: The odd formatting and incorrect indentation should no longer 
be a problem

because the indentation will not need to change.

Regards, Roger


On 4/18/18 8:41 AM, Pallavi Sonal wrote:

Hi,

Please review the changes to the following issue:

Bug :https://bugs.openjdk.java.net/browse/JDK-8193877  

  


The proposed fix is located at:

Webrev :http://cr.openjdk.java.net/~rpatil/8193877/webrev.00/

  


When padding is used in a pattern where there are unpadded values adjacent to padded ones 
(like "pdQ") , the previous PrinterParser (used for parsing 'd' in the example 
) is fetched to use its settings for parsing the next value('Q' in the example). But , in 
cases like this , it is a PadPrinterDecoratorParser instead of an assumed 
NumberPrinterParser and a ClassCastException is thrown.

The fix has been done to check such cases where the previous parserprinter is 
PadPrinterDecoratorParser and use the new NumberPrinterParser instead for 
parsing the next value.

  


All the tier1 and tier2 Mach 5 tests have passed.

  


Thanks,

Pallavi Sonal

  

Re: uploading of new code

[mark . reinhold]

2018/4/18 10:27:36 -0700, e...@zusammenkunft.net:
> Hello, I would put it on a standalone Git repo on one of the public
> hosting sites lile.Github, especially for a first discussion
> (especially good if added JMH comparisions). I would not expect a id
> quickly/easily and a in-tree webrev could be created by sponsor for
> final ok.

For IP clarity, no Oracle engineer will review code that is not posted,
in some form or another (e-mail, webrev, JIRA), directly to OpenJDK.

For an initial discussion a patch in e-mail is a fine way to start, even
for 3,000 lines of code.  Those who care can either read it directly or
else import it into a local repo for further evaluation.

- Mark

Re: uploading of new code

[Bernd Eckenfels]

Hello, I would put it on a standalone Git repo on one of the public hosting 
sites lile.Github, especially for a first discussion (especially good if added 
JMH comparisions). I would not expect a id quickly/easily and a in-tree webrev 
could be created by sponsor for final ok.

Bernd

Von: raffaello.giulie...@gmail.com
Gesendet: Mittwoch, 18. April 2018 19:20
An: Aleksey Shipilev; Andrew Haley; core-libs-dev
Betreff: Re: uploading of new code

On 2018-04-18 16:35, Aleksey Shipilev wrote:
> On 04/18/2018 03:58 PM, Andrew Haley wrote:
>> On 04/18/2018 02:55 PM, raffaello.giulie...@gmail.com wrote:
>>> So, how can I best proceed with this initial delivery?
>>
>> Once you have an OpenJDK id you can get an account on cr.openjdk.java.net.
>> That's where you should put your changes.
> 

@Andrew
I can't recall having got an OpenJDK id when I got my Oracle Contributor
Agreement confirmed. But I'll double check.



> ...and until that happens you can ask existing users to host the webrev for 
> you, probably your
> current sponsor. Brian Burkhalter seems to be your sponsor for this work?
> 

@Aleksey
Right, I suppose Brian is my sponsor.



Greetings
Raffaello

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

[Roger Riggs]

Hi,

Also, the new constructor should be public so it can be used in other 
places.


It seems in some cases the error message is a literal in the VM code ( 
typeArrayKlass.cpp:149).

That would seem to be a duplication and not really a good idea.

Roger


On 4/18/18 10:30 AM, Roger Riggs wrote:

Hi,

The message can be simpler and more efficiently convey the information.
It should be more consistent with existing uses of 
ArrayIndexOutOfBoundsException as

throw by:  Objects.checkIndex(index, length).

Which roughly reads as:

   Index %d out-of-bounds for length %d

Regards, Roger

On 4/18/18 4:54 AM, David Holmes wrote:
Adding core-libs-dev as you're changing 
java.lang.ArrayIndexOutOfBoundsException.


I appreciate the intent here but I find the messages excessively 
verbose. The basic error is:


index N is outside range [0, length-1]

David

On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote:

Hi,

I would like to print a more verbose text on ArrayIndexOutOfBounds 
exception
that not only mentions the index, but also the length of the array 
accessed.

See the bug for documentation of the change of the message.
http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/

@aarch/arm people:
I edited the aarch/arm files. Could you please verify this is correct?
I can not build on these platforms.

The code on all the other platforms is tested with all the jtreg and 
jck tests etc.


Best regards,
   Goetz.

RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators

[Claes Redestad]

Hi,

please review this change that moves the use of SALT to iterator 
creation, which would allow for certain startup

optimizations in the future.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201650
Webrev: http://cr.openjdk.java.net/~redestad/8201650/open.00/

This does make the randomness of iteration order weaker as we're only 
randomizing the starting point (varying with
the size of the collection) and the iteration direction (run-to-run 
variant; weaker than calculating per size, but

allows this patch to be performance neutral).

Some Set/Map operations become very slightly faster with this patch, but 
that's in the noise. Iterator operations

remain largely performance neutral, sometimes even a bit faster.

Thanks!

/Claes

Re: uploading of new code

[Roger Riggs]

Hi,

The requirements to become an OpenJDK Author[1] are fairly modest but follow
from a couple of sponsored contributions after which you can request to 
become

an author.

Regards, Roger

[1] http://openjdk.java.net/projects/#project-author

On 4/18/18 10:49 AM, raffaello.giulie...@gmail.com wrote:

On 2018-04-18 16:35, Aleksey Shipilev wrote:

On 04/18/2018 03:58 PM, Andrew Haley wrote:

On 04/18/2018 02:55 PM, raffaello.giulie...@gmail.com wrote:

So, how can I best proceed with this initial delivery?

Once you have an OpenJDK id you can get an account on cr.openjdk.java.net.
That's where you should put your changes.

@Andrew
I can't recall having got an OpenJDK id when I got my Oracle Contributor
Agreement confirmed. But I'll double check.




...and until that happens you can ask existing users to host the webrev for 
you, probably your
current sponsor. Brian Burkhalter seems to be your sponsor for this work?


@Aleksey
Right, I suppose Brian is my sponsor.



Greetings
Raffaello

Re: uploading of new code

[raffaello . giulietti]

On 2018-04-18 16:35, Aleksey Shipilev wrote:
> On 04/18/2018 03:58 PM, Andrew Haley wrote:
>> On 04/18/2018 02:55 PM, raffaello.giulie...@gmail.com wrote:
>>> So, how can I best proceed with this initial delivery?
>>
>> Once you have an OpenJDK id you can get an account on cr.openjdk.java.net.
>> That's where you should put your changes.
> 

@Andrew
I can't recall having got an OpenJDK id when I got my Oracle Contributor
Agreement confirmed. But I'll double check.



> ...and until that happens you can ask existing users to host the webrev for 
> you, probably your
> current sponsor. Brian Burkhalter seems to be your sponsor for this work?
> 

@Aleksey
Right, I suppose Brian is my sponsor.



Greetings
Raffaello

Re: uploading of new code

[Aleksey Shipilev]

On 04/18/2018 03:58 PM, Andrew Haley wrote:
> On 04/18/2018 02:55 PM, raffaello.giulie...@gmail.com wrote:
>> So, how can I best proceed with this initial delivery?
> 
> Once you have an OpenJDK id you can get an account on cr.openjdk.java.net.
> That's where you should put your changes.

...and until that happens you can ask existing users to host the webrev for 
you, probably your
current sponsor. Brian Burkhalter seems to be your sponsor for this work?

-Aleksey

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

[Roger Riggs]

Hi,

The message can be simpler and more efficiently convey the information.
It should be more consistent with existing uses of 
ArrayIndexOutOfBoundsException as

throw by:  Objects.checkIndex(index, length).

Which roughly reads as:

   Index %d out-of-bounds for length %d

Regards, Roger

On 4/18/18 4:54 AM, David Holmes wrote:
Adding core-libs-dev as you're changing 
java.lang.ArrayIndexOutOfBoundsException.


I appreciate the intent here but I find the messages excessively 
verbose. The basic error is:


index N is outside range [0, length-1]

David

On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote:

Hi,

I would like to print a more verbose text on ArrayIndexOutOfBounds 
exception
that not only mentions the index, but also the length of the array 
accessed.

See the bug for documentation of the change of the message.
http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/

@aarch/arm people:
I edited the aarch/arm files. Could you please verify this is correct?
I can not build on these platforms.

The code on all the other platforms is tested with all the jtreg and 
jck tests etc.


Best regards,
   Goetz.

Re: uploading of new code

[Andrew Haley]

On 04/18/2018 02:55 PM, raffaello.giulie...@gmail.com wrote:
> So, how can I best proceed with this initial delivery?

Once you have an OpenJDK id you can get an account on cr.openjdk.java.net.
That's where you should put your changes.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

uploading of new code

[raffaello . giulietti]

Hi,

in thread [1] I mention a clean room implementation of
Double.toString(double) and my willingness to contribute it to the
OpenJDK project to fix [2].

As of today, my code resides in a module that exports a package simply
named "math". The reason I do not alter the original OpenJDK
implementation is that I need it *along* my code to be able to compare
results. I developed the code in total ignorance of the OpenJDK
implementation, so to speak. This is not the end goal, of course, but
the safest way to review/test it without potentially breaking existing code.

As a consequence, I wonder how to best deliver my contribution to the
OpenJDK project in this phase. As far as I understand, webrev [3] is
better suited for *changes* to existing code, not specifically for *new*
code.

I also understand that attachments are not recommended. On the other
hand, pasting some thousands of Java lines in a post on the mailing list
isn't practical either, I guess.

The code currently consists of about 8 files for a total of about 3000 +
600 lines for code + tests.

So, how can I best proceed with this initial delivery?



Greetings
Raffaello


[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
[2] https://bugs.openjdk.java.net/browse/JDK-4511638
[3] http://openjdk.java.net/guide/codeReview.html

RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding

[Pallavi Sonal]

Hi,

Please review the changes to the following issue:

Bug : https://bugs.openjdk.java.net/browse/JDK-8193877 

 

The proposed fix is located at:

Webrev : http://cr.openjdk.java.net/~rpatil/8193877/webrev.00/

 

When padding is used in a pattern where there are unpadded values adjacent to 
padded ones (like "pdQ") , the previous PrinterParser (used for parsing 'd' in 
the example ) is fetched to use its settings for parsing the next value('Q' in 
the example). But , in cases like this , it is a PadPrinterDecoratorParser 
instead of an assumed NumberPrinterParser and a ClassCastException is thrown.

The fix has been done to check such cases where the previous parserprinter is 
PadPrinterDecoratorParser and use the new NumberPrinterParser instead for 
parsing the next value.

 

All the tier1 and tier2 Mach 5 tests have passed.

 

Thanks,

Pallavi Sonal

 

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

[David Holmes]

Adding core-libs-dev as you're changing 
java.lang.ArrayIndexOutOfBoundsException.


I appreciate the intent here but I find the messages excessively 
verbose. The basic error is:


index N is outside range [0, length-1]

David

On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote:

Hi,

I would like to print a more verbose text on ArrayIndexOutOfBounds exception
that not only mentions the index, but also the length of the array accessed.
See the bug for documentation of the change of the message.
http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/

@aarch/arm people:
I edited the aarch/arm files. Could you please verify this is correct?
I can not build on these platforms.

The code on all the other platforms is tested with all the jtreg and jck tests 
etc.

Best regards,
   Goetz.

Re: RFR(S): 8201540: [AIX] Extend the set of supported charsets in java.base

[Ichiroh Takiguchi]

Hello Volker.
(I'm sorry for duplicate posting, I did bad operation)


What's actually the difference between "ibm-942C" and "ibm-942"?

They have two differences on single byte part:
1. Control Character rotation for 0x1A and 0x1C, 0x7F [2]
2. Character replacement for 0x5C and 0x7E (0xFE, 0xFF)

For IBM-942 [3],
0x1A<=>U+001C,0x1C<=>U+007F,0x5C<=>U+00A5,0x7E<=>U+203E,0x7F<=>U+001A
0xFE<=>U+005C,0xFF<=>U+007E

For IBM-942C,
0x1A<=>U+001A,0x1C<=>U+001C,0x5C<=>U+005C,0x7E<=>U+007E,0x7F<=>U+007F,
0x5C<=U+00A5,0x7E<=U+203E
0xFE=>U+005C,0xFF=>U+007E
(It's ASCII compatible)

IBM-942's single byte part is IBM-1041 [4].
IBM-932's single byte part is IBM-897 [5].

IBM-1041 is not same as IBM-897.
5 characters were added into IBM-1041 [4].
(0x80,0xA0,0xFD,0xFE,0xFF [2])

[2] https://www-01.ibm.com/software/globalization/cdra/appendix_g.html
[3] https://en.wikipedia.org/wiki/Code_page_942
[4] http://www-01.ibm.com/software/globalization/cp/cp01041.html
[5] http://www-01.ibm.com/software/globalization/cp/cp00897.html

On 2018-04-17 23:52, Volker Simonis wrote:

Hi Bhaktavatsal Reddy,

you change looks good, although I can't really verify all the charset
aliases. For example Wikipedia mentions that "ibm-932" is equivalent
to "ibm-942" [1] but you made it an alias for "ibm-942C". What's
actually the difference between "ibm-942C" and "ibm-942"?

I can sponsor your change although I would appreciate if somebody else
from IBM could have another look at your change. I tried to compare
with "IBM Java 9" but it doesn't seem to exist. They only refer to
AdoptOpenJDK and AdoptOpenJDK just uses a vanilla version of OpenJDK.

Finally, I hope you won't mind if I update the copyright years on the
files you changed before pushing (this is a convention in the OpenJDK
project).

Best regards,
Volker

[1] https://en.wikipedia.org/wiki/Code_page_932_(IBM)

On Mon, Apr 16, 2018 at 1:10 PM, Bhaktavatsal R Maram
 wrote:

Hi All,

I've regenerated webrev using "hg rename" to create template files. 
webrev looks much neat now.. Thanks Alan for suggestion.


webrev - http://cr.openjdk.java.net/~gromero/8201540/v2/

Thanks,
Bhaktavatsal Reddy


-"core-libs-dev"  wrote: 
-

To: Alan Bateman 
From: "Bhaktavatsal R Maram"
Sent by: "core-libs-dev"
Date: 04/16/2018 02:38PM
Cc: Tim Ellison , 
ppc-aix-port-...@openjdk.java.net, Java Core Libs 

Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported 
charsets in java.base


Hi Alan,

I deleted IBM943C.java (using hg remove) and added new file 
IBM943C.java.template (using hg add). I now understand that using "hg 
rename" is giving more meaningful representation in webrev/index.html.


I will re-generate webrev by renaming source files to templates using 
"hg rename"


Thanks,
Bhaktavatsal Reddy



-Alan Bateman  wrote: -
To: Bhaktavatsal R Maram , Volker Simonis 


From: Alan Bateman 
Date: 04/16/2018 02:16PM
Cc: Java Core Libs , Tim Ellison 
, ppc-aix-port-...@openjdk.java.net
Subject: Re: RFR(S): 8201540: [AIX] Extend the set of supported 
charsets in java.base



On 16/04/2018 09:22, Bhaktavatsal R Maram wrote:


3. Source files for IBM-942C and IBM-943C are changed to template to 
support #1


You might want to double check the webrev as it looks like you've 
added

templates where as I assume you mean to use "hg rename" to rename
IBM942C.java and IBM943C.java.

-Alan

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

[Magnus Ihse Bursie]

> 17 apr. 2018 kl. 00:52 skrev mark.reinh...@oracle.com:
> 
> 2018/4/12 1:12:36 -0700, raffaello.giulie...@gmail.com:
>> my code is now ready to be uploaded to the OpenJDK reps. Currently it 
>> resides on GitHub and is under the "GPLv2 + Classpath Exception" 
>> license, with myself as the copyright holder.
>> 
>> I asked Oracle about how the copyright notice should be adapted to meet 
>> the OCA requirements but, as of today, I got no answer.
>> 
>> Is there any official reference about the copyright notice on OpenJDK 
>> contributions?
> 
> For library code, the template is in $JDK/make/templates/gpl-cp-header [1].
> It begins:
> 
>  Copyright (c) %YEARS% Oracle and/or its affiliates. All rights reserved.
>  DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
>  This code is free software; you can redistribute it and/or modify it
>  under the terms of the GNU General Public License version 2 only, as
>  ...
> 
> You can just use the Oracle copyright line or, at your option, replace
> it with your own.  In any case %YEARS% should be replaced with the year
> in which the file was created, and if it was modified in any later year
> then the creation year should be followed by the latest year in which
> the file was modified, separated by a comma.

The Oracle praxis is that the year or years should still be followed by a 
comma. E.g:

 Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
or
 Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.

I don’t know if this is an Oracle quirk or and (in)official OpenJDK 
requirement, but it probably doesn’t harm to follow it. :-)

/Magnus

> 
> (We can better advise you on the details once we see the actual code.)
> 
> - Mark
> 
> 
> [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/make/templates/gpl-cp-header

Re: RFR: 8184693: (opt) add Optional.isEmpty

[Stuart Marks]

OK, looks good! +1 from me.

s'marks

On 4/17/18 10:34 PM, Vivek Theeyarath wrote:

Hi Stuart,
Done with the changes 
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.05/ .
Regards
Vivek
-Original Message-
From: Stuart Marks
Sent: Wednesday, April 18, 2018 8:56 AM
To: Vivek Theeyarath 
Cc: core-libs-dev ; Paul Sandoz 

Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty

Hi Vivek,

Thanks for the update. In the test files, please remove the unnecessary imports 
of List and the various Predicate types. In most cases it's not a problem to 
have unnecessary imports. I happened to notice in this case that they're left 
over from the previous version of the webrev, and looking at the current webrev 
by itself, it's clear they're unnecessary.

Thanks,

s'marks

On 4/17/18 6:23 AM, Vivek Theeyarath wrote:

Hi All,
Please find the updated webrev
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.04
Regards
Vivek

-Original Message-
From: Stuart Marks
Sent: Tuesday, April 17, 2018 5:11 AM
To: Vivek Theeyarath 
Cc: core-libs-dev ; Paul Sandoz

Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty

Hi Vivek,

Please add "@since 11" tags to the doc comments of the four Optional*.isEmpty() 
methods.

Regarding the tests, I don't think the various newly added testIsEmpty() tests 
are useful. The setup in those test files already generates a fairly 
comprehensive set of Optional values from a variety of sources. All the 
assertion checking is performed in the checkEmpty() and checkPresent() methods.
It should be sufficient to add an assertTrue(isEmpty()) call to checkEmpty() -- 
as you've done -- and also to add an assertFalse(isEmpty()) call to 
checkPresent(). If these assertions are added, the additional testIsEmpty() 
test is unnecessary.

This applies to all four of the regression test files.

Thanks,

s'marks

On 4/16/18 11:08 AM, Vivek Theeyarath wrote:

Hi All,
Please find the updated webrev 
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.02/ .
Here is the csr which I have raised for this change
https://bugs.openjdk.java.net/browse/JDK-8201606

Regards
Vivek
-Original Message-
From: Chris Hegarty
Sent: Sunday, April 15, 2018 6:48 PM
To: Vivek Theeyarath 
Cc: Remi Forax ; core-libs-dev

Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty




On 15 Apr 2018, at 11:25, Vivek Theeyarath  wrote:

Hi All,
  Please review
http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/


This looks ok to me.

For consistency, can you please update the copyright header year range in 
OptionalInt.

-Chris.


Regards
Vivek
-Original Message-
From: Vivek Theeyarath
Sent: Saturday, April 14, 2018 6:24 PM
To: Remi Forax 
Cc: core-libs-dev 
Subject: RE: RFR: 8184693: (opt) add Optional.isEmpty

I missed that Remi. Thanks for pointing it out. Will address those and get back.

Regards
Vivek
-Original Message-
From: Remi Forax [mailto:fo...@univ-mlv.fr]
Sent: Saturday, April 14, 2018 2:58 PM
To: Vivek Theeyarath 
Cc: core-libs-dev 
Subject: Re: RFR: 8184693: (opt) add Optional.isEmpty

Hi Vivek,
OptionalInt, OptionalLong and OptionalDouble should be changed too.

Rémi

- Mail original -

De: "Vivek Theeyarath" 
À: "core-libs-dev" 
Envoyé: Samedi 14 Avril 2018 08:22:50
Objet: RFR: 8184693: (opt) add Optional.isEmpty



Hi All,

Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8184693

Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.00/



The related jtreg test was run and the test passed .



Regards

Vivek