RFR of JDK-8202291,java/rmi/Naming/LookupIPv6.java failed with Connection refused

[Hamlin Li]

would you please review the patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8202291

webrev: http://cr.openjdk.java.net/~mli/8202291/webrev.00/

In original code, there is a window between get registry and rebind 
which could cause connection refuse.



Thank you

-Hamlin

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

[Stuart Marks]

On 4/18/18 8:20 AM, Claes Redestad wrote:
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.


Hi Claes,

I finally got a chance to look at this. Overall looks fine. Although the 
randomness is "weaker" iterating in both directions will, I think, still have 
the desired effect of flushing out order dependencies.


I have a test (forthcoming) that verifies that iteration order will vary from 
run to run, and it passes with both the old and new code.


Not an issue, but I'm curious as to why the initial index is chosen this way:

idx = Math.floorMod(SALT ^ remaining, elements.length);

The floorMod with a divisor of elements.length makes perfect sense. I'm 
wondering why the dividend is (SALT ^ remaining) and not just SALT for example.


Thanks,

s'marks

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

[mandy chung]

On 4/28/18 6:08 AM, Kim Barrett wrote:

On Apr 26, 2018, at 10:16 AM, mandy chung  wrote:

The semantics of cloning a Reference object is not clearly defined. In 
addition, it is questionable whether it can be meaningfully supported in 
particular with concurrent reference processing.

The reachability state of a Reference object may change during GC reference 
processing. The referent may have been cleared when it reaches its reachability 
state. In addition, it may be enqueued or pending for enqueuing. Cloning a 
Reference object with a referent that is unreachable but not yet cleared might 
mean to resurrect the referent. A cloned enqueued Reference object will never 
be enqueued.  A Reference object cannot be meaningfully cloned.

We propose Reference::clone to throw CloneNotSupportedException.  To clone a 
Reference object, it should create a new instance via its constructor.

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

Webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/

Mandy

The webrev doesn’t have the minor doc change suggested in the CSR.


I have that fixed in my local repo but the webrev was not updated.

diff --git a/src/java.base/share/classes/java/lang/ref/Reference.java 
b/src/java.base/share/classes/java/lang/ref/Reference.java

--- a/src/java.base/share/classes/java/lang/ref/Reference.java
+++ b/src/java.base/share/classes/java/lang/ref/Reference.java
@@ -300,6 +300,20 @@
 return this.queue.enqueue(this);
 }

+    /**
+ * Throws {@link CloneNotSupportedException}. A {@code Reference} 
cannot be

+ * meaningfully cloned. Construct a new {@code Reference} instead.
+ *
+ * @returns never returns normally
+ * @throws  CloneNotSupportedException always
+ *
+ * @since 11
+ */
+    @Override
+    protected Object clone() throws CloneNotSupportedException {
+    throw new CloneNotSupportedException();
+    }
+
 /* -- Constructors -- */



Other than that, looks good.



Thanks.
Mandy

Re: jdk-submit is offline until Monday

[David Holmes]

I should have added that the CI testing system is also offline, so any 
pushes won't hit our internal testing until sometime Monday.


David

On 28/04/2018 9:19 AM, David Holmes wrote:
Just a heads up that due to scheduled maintenance the systems used by 
jdk-submit will be offline until Monday morning Pacific Time US.


David

jdk-submit is offline until Monday

[David Holmes]

Just a heads up that due to scheduled maintenance the systems used by 
jdk-submit will be offline until Monday morning Pacific Time US.


David

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[Joe Wang]

On 4/27/2018 12:50 PM, fo...@univ-mlv.fr wrote:

- Mail original -

De: "Joe Wang" 
À: "Remi Forax" , "Alan Bateman" 
Cc: "nio-dev" , "core-libs-dev" 

Envoyé: Vendredi 27 Avril 2018 21:21:01
Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for 
reading/writing a string from/to a file
Hi Rémi, Alan,

Hi Joe,


I'm not sure we'd want to replace system dependent line separators with
'\n'. There are cases as you described where the replacement makes
sense. However,  there are other cases too. For example, the purpose is
to read, edit a text file and then write it back. If this is on Windows,
and if line separators are replaced with '\n', that would cause the
resulting file not formatted properly in for example Notepad. There are
cases where users write text files on Windows using Java, and only found
the lines were not separated in Notepad.

I agree that why the counterpart of readString() that write the string should 
inserts the platform's line separator.
BTW, i just found that those methods are not named writeString, or 
writeCharSequence, i think they should.


While readString() does not modify the original content (e.g. by 
replacing the platform's line separator with '\n'), write(String) won't 
either, by adding extra characters such as the line separator.


I would think interfaces shall read along with the parameters.
    readString(Path) == read as a String from the specified Path (one 
could argue for readToString, readAsString, but we generally omit the preps)
    write(Path, CharSequence) == write the CharSequence to the file, 
since CharSequence is already in the method signature as a parameter, we 
probably don't want to add that to the name, otherwise it would read 
like repeating the word CharSequence.


It is in a similar situation as write(Path, Iterable) where it was 
defined as writeLines(Path, Iterable).





Files.write(Path, Iterable) is also specified to terminate each line
with the platform's line separator. If readString does the replacement,
it would be inconsistent.


Anyway, if we look for consistency the methods writeCharSequence should 
transform the \n in the CharSequence to the platform's line separator.

Files.write(Path, Iterable) is is not a counterpart of readString(), it's 
consistent with Files.lines() or Files.readLines() (or 
BufferedReader.readLine()) that all suppress the line separators. Anyway, 
Files.write(path, readString(path)::line) will be consistent if you replace the 
line separators or not because String.line() suppresses the line separators.


readString pairs with write(String), therefore it's more like 
Files.write(path, readString(path)) than readString(path)::line. The use 
case:


    String s = Files.read(path);
    Files.write(path, s.replace("/config/location", "/new/location"));

would then work as expected.

These two methods are one-off (open/read/write/close file) operation. 
write(String) therefore is not intended for adding/appending multiple 
Strings from other operations such as String.line(). If an app needs to 
put the result of String.line() or any other processes into a file using 
this method, it needs to take care of adding the line separator itself 
when necessary. "when necessary" would be a judgement call by the developer.


That said, if there's a consensus on the idea of terminating the string 
with a line separator, then readString method would need to strip it off 
to go with the write method.





I would think readString behaves like readAllBytes, that would simply read all 
content faithfully.

readString does an interpolation due to the Charset so it's not the real 
content, again, the idea is that developers should not have to care about the 
platform's line separators (they have more important things to think).

The other solution is to just not introduce those new methods, after all 
Files.lines().collect(Collectors.joining("\n")) already does the job, no ?


While there are many ways to do it, none is as straight-forward. "Read 
(entire) file to String"/"Write String to file" are popular requests 
from users. Read to string -> do some String manipulation -> write it 
back is such a simple use case, it really needs to be very easy to do as 
illustrated in the above code snippet.


Cheers,
Joe




Best,
Joe

regards,
Rémi


On 4/27/2018 4:43 AM, fo...@univ-mlv.fr wrote:

Hi Alan,

People do not read the documentation.
So adding something in the documentation about when a method should be used or
not is never a solution.

Here the user want a String and provides a charset so you have no way but to
decode the content to substitute the line separator.

cheers,
Rémi

- Mail original -

De: "Alan Bateman" 
À: "Remi Forax" , "Joe Wang" 
Cc: "nio-dev" , "core-libs-dev"

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

[Kim Barrett]

> On Apr 26, 2018, at 10:16 AM, mandy chung  wrote:
> 
> The semantics of cloning a Reference object is not clearly defined. In 
> addition, it is questionable whether it can be meaningfully supported in 
> particular with concurrent reference processing.
> 
> The reachability state of a Reference object may change during GC reference 
> processing. The referent may have been cleared when it reaches its 
> reachability state. In addition, it may be enqueued or pending for enqueuing. 
> Cloning a Reference object with a referent that is unreachable but not yet 
> cleared might mean to resurrect the referent. A cloned enqueued Reference 
> object will never be enqueued.  A Reference object cannot be meaningfully 
> cloned.
> 
> We propose Reference::clone to throw CloneNotSupportedException.  To clone a 
> Reference object, it should create a new instance via its constructor.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8202260
> 
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/
> 
> Mandy

The webrev doesn’t have the minor doc change suggested in the CSR.

Other than that, looks good.

Re: RFR 8197388: Added not existing bug id in jdk/ProblemList.txt

[Andrey Nazarov]

Hi,

Could you CC any client alias?

—Thanks,
Andrei 

> On 26 Apr 2018, at 11:51, Andrey Nazarov  wrote:
> 
> Hi,
> 
> Please review patch that fixes typo in bug id.
> 
> diff -r 3661f31c6df4 test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt  Thu Apr 26 11:19:05 2018 -0500
> +++ b/test/jdk/ProblemList.txt  Thu Apr 26 11:47:18 2018 -0700
> @@ -243,7 +243,7 @@
> sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java 8144029 macosx-all
> sun/java2d/SunGraphics2D/DrawImageBilinear.java 8191506 generic-all
> sun/java2d/SunGraphics2D/PolyVertTest.java 6986565 generic-all
> -sun/java2d/SunGraphics2D/SimplePrimQuality.java 7992007 generic-all
> +sun/java2d/SunGraphics2D/SimplePrimQuality.java 6992007 generic-all
> sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java 
> 8196191 windows-all,macosx-all
> sun/java2d/pipe/InterpolationQualityTest.java 8171303 
> windows-all,linux-all,macosx-all
> java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java 8169469 
> windows-all
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8197388
> 
> 
> —Thanks,
> Andrei

Re: [11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales

[naoto . sato]

Looks good.

Naoto

On 4/27/18 5:32 AM, Rachna Goel wrote:

One correction:

E.g "pa-PK" wil be replaced by "pa-Arab-PK", as former is a 
deprecated/legacy tag.



On 4/27/18 12:05 PM, Rachna Goel wrote:

Hi,

Kindly review the fix for JDK-8179071.

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

Patch: http://cr.openjdk.java.net/~rgoel/JDK-8179071/webrev.03/index.html

Fix is to parse and store language aliases( Deprecated and Legacy ) 
from CLDR's SupplemetalMetaData file. At run time, If a 
deprectaed/legacy locale tag is found, It will be replaced by its 
replacement tag. E.g "pa-PK" will be replaced by "pa-Guru-PK".

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[forax]

- Mail original -
> De: "Joe Wang" 
> À: "Remi Forax" , "Alan Bateman" 
> Cc: "nio-dev" , "core-libs-dev" 
> 
> Envoyé: Vendredi 27 Avril 2018 21:21:01
> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for 
> reading/writing a string from/to a file

> Hi Rémi, Alan,

Hi Joe,

> 
> I'm not sure we'd want to replace system dependent line separators with
> '\n'. There are cases as you described where the replacement makes
> sense. However,  there are other cases too. For example, the purpose is
> to read, edit a text file and then write it back. If this is on Windows,
> and if line separators are replaced with '\n', that would cause the
> resulting file not formatted properly in for example Notepad. There are
> cases where users write text files on Windows using Java, and only found
> the lines were not separated in Notepad.

I agree that why the counterpart of readString() that write the string should 
inserts the platform's line separator.
BTW, i just found that those methods are not named writeString, or 
writeCharSequence, i think they should.

> 
> Files.write(Path, Iterable) is also specified to terminate each line
> with the platform's line separator. If readString does the replacement,
> it would be inconsistent.


Anyway, if we look for consistency the methods writeCharSequence should 
transform the \n in the CharSequence to the platform's line separator.

Files.write(Path, Iterable) is is not a counterpart of readString(), it's 
consistent with Files.lines() or Files.readLines() (or 
BufferedReader.readLine()) that all suppress the line separators. Anyway, 
Files.write(path, readString(path)::line) will be consistent if you replace the 
line separators or not because String.line() suppresses the line separators.

> 
> I would think readString behaves like readAllBytes, that would simply read 
> all content faithfully.

readString does an interpolation due to the Charset so it's not the real 
content, again, the idea is that developers should not have to care about the 
platform's line separators (they have more important things to think).

The other solution is to just not introduce those new methods, after all 
Files.lines().collect(Collectors.joining("\n")) already does the job, no ?

> 
> Best,
> Joe

regards,
Rémi

> 
> On 4/27/2018 4:43 AM, fo...@univ-mlv.fr wrote:
>> Hi Alan,
>>
>> People do not read the documentation.
>> So adding something in the documentation about when a method should be used 
>> or
>> not is never a solution.
>>
>> Here the user want a String and provides a charset so you have no way but to
>> decode the content to substitute the line separator.
>>
>> cheers,
>> Rémi
>>
>> - Mail original -
>>> De: "Alan Bateman" 
>>> À: "Remi Forax" , "Joe Wang" 
>>> Cc: "nio-dev" , "core-libs-dev"
>>> 
>>> Envoyé: Vendredi 27 Avril 2018 13:34:12
>>> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for
>>> reading/writing a string from/to a file
>>> On 27/04/2018 12:29, Remi Forax wrote:
 I think that having a readString that includes OS dependent line 
 separators is a
 mistake,
 Java does a great job to try to shield the developer from the kind of 
 things
 that makes programs behave differently on different platforms.

 readString should subtitute (\r)?\n to \n otherwise either people will do 
 a call
 replace() which is less efficient or will learn the lesson the hard way.

 raw string literal does the same substitution for the same reason.

>>> Yes, there are several discussion points around this and somewhat timely
>>> with multi-string support.
>>>
>>> One thing that I think Joe will need in this API is some note to make it
>>> clearer what the intended usage is (as I think the intention is simple
>>> cases with mostly single lines of text).
>>>
> >> -Alan.

Re: Update to the Double::toString(double) Javadoc

[raffaello . giulietti]

Hi Joe,

so I beg Brian to get in touch with me for the CSR review.

I'm familiar with the paper of Steele and White.
For background on the design of my contribution see [1].


Greetings
Raffaello


[1] https://9b7022c5f9.files.wordpress.com/2018/04/todec.pdf


On 2018-04-27 20:58, joe darcy wrote:
> Hello Raffaello,
> 
> 
> On 4/27/2018 7:39 AM, raffaello.giulie...@gmail.com wrote:
>> Hi,
>>
>> as may be known, the current Javadoc for Double::toString(double) is not
>> specific enough. As a consequence, different implementations can return
>> different results.
>>
>> To see this, here are some quotes from the Javadoc. It asks: "How many
>> digits must be printed for the fractional part of m or a?" It answers:
>> "There must be at least one digit to represent the fractional part, and
>> beyond that as many, but only as many, more digits as are needed to
>> uniquely distinguish the argument value from adjacent values of type
>> double."
>>
>> One interpretation is: output "as many" digit of m (or a) itself. But
>> this can lead to unnecessarily long results. For example, the true value
>> of the double v closest to 0.3 is
>> v = 0.299988897769753748434595763683319091796875
>> so according to this restricted interpretation the method should return
>> "0.29998"
>> because shorter prefixes do not round to v.
>>
>> Another interpretation exploits the astute word "represent" in the
>> answer, so it might sound: output "as many" digits of a nearby, vaguely
>> determined "short" number that "represents" m (or a) and happens to
>> round to v. In this case the obvious choice is
>> "0.3"
>> which is the result returned by the method.
>>
>> One problem with this interpretation is that sometimes there is more
>> than one choice. For example, both 4.8E-324 and 4.9E-324 round to
>> Double.MIN_VALUE. The method chooses the latter one, presumably because
>> it is closer to the double, but this is not specified. It is also not
>> specified what happens if two equally shortest numbers that round to the
>> same double are also equally close to it.
>>
>> Of course, the same holds for Float::toString(float).
> 
> For background on the design of this printing methodology see  "How to
> Print Floating-Point Numbers Accurately," Guy L. Steele and Jon L. White
> in the proceedings of the 1990 PLDI.
> 
>> The code that was uploaded to this mailing list [1] as a contribution to
>> fix [2], contains a purportedly better Javadoc that imposes a uniquely
>> specified result (see method math.DoubleToDecimal::toString(double) ).
>> It has been carefully written to ensure that the spirit of the current
>> Javadoc is preserved as much as possible and to make sure that the
>> results returned by the contributed code and by the current OpenJDK
>> implementation are consistent (modulo the anomalies discussed in [2]).
>>
>>
>>
>> The question is if this needs to be submitted to the Compatibility &
>> Specification Review Group?
>> If so, what is the correct process to follow for an individual
>> contributor like me?
> 
> It does sound like the change merits CSR review.  On a procedural front,
> to create a CSR, one needs an account in the bug system, so the sponsor
> of your issue with an account, Brian Burkhalter I believe, would need to
> assist here. Conceptually, the CSR process is described on its wiki page
> https://wiki.openjdk.java.net/display/csr/Main. The review is concerned
> with evaluating the compatibility impact of the spec (or behavioral
> change), so information about those matters is provided and considered.
> 
>>
>> I ask because I would like my contribution to be accepted for the next
>> OpenJDK 11 LTS release: I have no idea on how long it would take for a
>> spec change to be approved, if the need arises at all in a case like
>> this one.
>>
> 
> The normal review SLA for CSR review is a week. Note this is time to
> review rather than time to approve since the CSR can have comments that
> need to be addressed, etc.
> 
> HTH and thanks for the code submission,
> 
> -Joe

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[Joe Wang]

Hi Rémi, Alan,

I'm not sure we'd want to replace system dependent line separators with 
'\n'. There are cases as you described where the replacement makes 
sense. However,  there are other cases too. For example, the purpose is 
to read, edit a text file and then write it back. If this is on Windows, 
and if line separators are replaced with '\n', that would cause the 
resulting file not formatted properly in for example Notepad. There are 
cases where users write text files on Windows using Java, and only found 
the lines were not separated in Notepad.


Files.write(Path, Iterable) is also specified to terminate each line 
with the platform's line separator. If readString does the replacement, 
it would be inconsistent.


I would think readString behaves like readAllBytes, that would simply 
read all content faithfully.


Best,
Joe

On 4/27/2018 4:43 AM, fo...@univ-mlv.fr wrote:

Hi Alan,

People do not read the documentation.
So adding something in the documentation about when a method should be used or 
not is never a solution.

Here the user want a String and provides a charset so you have no way but to 
decode the content to substitute the line separator.

cheers,
Rémi

- Mail original -

De: "Alan Bateman" 
À: "Remi Forax" , "Joe Wang" 
Cc: "nio-dev" , "core-libs-dev" 

Envoyé: Vendredi 27 Avril 2018 13:34:12
Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for 
reading/writing a string from/to a file
On 27/04/2018 12:29, Remi Forax wrote:

I think that having a readString that includes OS dependent line separators is a
mistake,
Java does a great job to try to shield the developer from the kind of things
that makes programs behave differently on different platforms.

readString should subtitute (\r)?\n to \n otherwise either people will do a call
replace() which is less efficient or will learn the lesson the hard way.

raw string literal does the same substitution for the same reason.


Yes, there are several discussion points around this and somewhat timely
with multi-string support.

One thing that I think Joe will need in this API is some note to make it
clearer what the intended usage is (as I think the intention is simple
cases with mostly single lines of text).

-Alan.

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[Joe Wang]

On 4/27/2018 4:13 AM, Alan Bateman wrote:

On 27/04/2018 05:50, Joe Wang wrote:

Hi,

We're looking into adding methods to Files to read a file into a 
String/write a String to a file. Below is the current proposal. 
Please review.


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

webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/

specdiff: 
http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html
The javadoc for these 4 methods looks okay. It might be helpful to 
include something in the readString javadoc to make it absolutely 
clear that the String may include line separators. I assume the "Note 
that .." paragraph can be changed to an @apiNote.


Added a statement to indicate that "the resulting string will contain 
line separators as they appear in the file".

Changed the 'note' to @apiNote.




I assume you'll add "@since 11" to the readString methods.


Added.


It would be good to keep the existing formatting/style consistent with 
the existing code if you can, e.g.  tags, 4 space indent rather 
than 8 for the throws, etc.


Fixed  and the throws. I didn't even notice that the IDE (NetBeans) 
added 8 spaces!




I can't tell from your mail if you are just looking for feedback on 
the current implementation + tests or just the API. I assume there are 
alternatives to using StringBuilder for the readString methods for 
example.


Both. I thought webrevs would be helpful where specdiff was not clear 
enough, for example, you won't otherwise notice the formatting/style 
issue :-)


I changed that to new String(readAllBytes(path), charset) as it's 
convenient with readAllBytes handling all situations (OOM and etc.). But 
alternative solution to avoid copying would be nice.


-Joe



-Alan

Re: Update to the Double::toString(double) Javadoc

[joe darcy]

Hello Raffaello,


On 4/27/2018 7:39 AM, raffaello.giulie...@gmail.com wrote:

Hi,

as may be known, the current Javadoc for Double::toString(double) is not
specific enough. As a consequence, different implementations can return
different results.

To see this, here are some quotes from the Javadoc. It asks: "How many
digits must be printed for the fractional part of m or a?" It answers:
"There must be at least one digit to represent the fractional part, and
beyond that as many, but only as many, more digits as are needed to
uniquely distinguish the argument value from adjacent values of type
double."

One interpretation is: output "as many" digit of m (or a) itself. But
this can lead to unnecessarily long results. For example, the true value
of the double v closest to 0.3 is
v = 0.299988897769753748434595763683319091796875
so according to this restricted interpretation the method should return
"0.29998"
because shorter prefixes do not round to v.

Another interpretation exploits the astute word "represent" in the
answer, so it might sound: output "as many" digits of a nearby, vaguely
determined "short" number that "represents" m (or a) and happens to
round to v. In this case the obvious choice is
"0.3"
which is the result returned by the method.

One problem with this interpretation is that sometimes there is more
than one choice. For example, both 4.8E-324 and 4.9E-324 round to
Double.MIN_VALUE. The method chooses the latter one, presumably because
it is closer to the double, but this is not specified. It is also not
specified what happens if two equally shortest numbers that round to the
same double are also equally close to it.

Of course, the same holds for Float::toString(float).


For background on the design of this printing methodology see  "How to 
Print Floating-Point Numbers Accurately," Guy L. Steele and Jon L. White 
in the proceedings of the 1990 PLDI.



The code that was uploaded to this mailing list [1] as a contribution to
fix [2], contains a purportedly better Javadoc that imposes a uniquely
specified result (see method math.DoubleToDecimal::toString(double) ).
It has been carefully written to ensure that the spirit of the current
Javadoc is preserved as much as possible and to make sure that the
results returned by the contributed code and by the current OpenJDK
implementation are consistent (modulo the anomalies discussed in [2]).



The question is if this needs to be submitted to the Compatibility &
Specification Review Group?
If so, what is the correct process to follow for an individual
contributor like me?


It does sound like the change merits CSR review.  On a procedural front, 
to create a CSR, one needs an account in the bug system, so the sponsor 
of your issue with an account, Brian Burkhalter I believe, would need to 
assist here. Conceptually, the CSR process is described on its wiki page 
https://wiki.openjdk.java.net/display/csr/Main. The review is concerned 
with evaluating the compatibility impact of the spec (or behavioral 
change), so information about those matters is provided and considered.




I ask because I would like my contribution to be accepted for the next
OpenJDK 11 LTS release: I have no idea on how long it would take for a
spec change to be approved, if the need arises at all in a case like
this one.



The normal review SLA for CSR review is a week. Note this is time to 
review rather than time to approve since the CSR can have comments that 
need to be addressed, etc.


HTH and thanks for the code submission,

-Joe

Re: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

[Rafael Winterhalter]

Hei Alan and David,
thanks for pointing me to the issue, I have only searched the release notes
for u172 by accident.

The issue is mainly during builds. I run my library on multiple CI servers
to cover Windows/Linux and different Java versions from 6-11.
Unfortunately, I have not full control over what version of Java is run on
these servers. Yesterday, I found some of the builds fail for pull requests
what was a bit confusing. Byte Buddy offers an abstraction over type
descriptions that implement similar semantics to the Java reflection API
when it comes to equality and to textual (toString) representations. These
tests suddenly failed since the JVMs representation is changed, this is
all. The Scala build had a similar problem:
https://github.com/scala/bug/issues/10835

This is not a big deal but I found it surprising to have a change in the
string representation within an update release. Especially since a nested
class does not necessarily have the same name prefix if a class is not
compiled with javac. I would have preferred the consistency over the
redundancy; especially when type names are machine-processed, this often
makes a parser easier to implement.

Thanks for clarifying this for me, best regards,
Rafael

2018-04-27 11:38 GMT+02:00 Alan Bateman :

> On 27/04/2018 10:10, David Holmes wrote:
>
>> Hi Rafael,
>>
>> On 27/04/2018 6:12 PM, Rafael Winterhalter wrote:
>>
>>> Hello,
>>>
>>> I was wondering if the change in ParameterizedType::toString was
>>> intended.
>>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8054213
>>
> See also the discussion from June 2016 [1] on this change.
>
> I can't tell from your mail if it's the repeated class name or the "$"
> issue that is causing you (and Scala) issues.
>
> -Alan
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-Ju
> ne/041869.html
>

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

[Paul Sandoz]

> On Apr 26, 2018, at 11:03 PM, mandy chung  wrote:
> 
> 
> 
> On 4/27/18 3:35 AM, Paul Sandoz wrote:
>> Hi Mandy,
>> 
>> This looks reasonable. I suspect external subtypes of the j.l.ref types are 
>> extremely rare (grep code reports no derived types) and of those it would 
>> likely be even rarer for those subtypes to implement Cloneable, and for that 
>> functionality to operate reliably.
> 
> Thanks for the review.
> 
> Subtypes of java.lang.ref.SoftReference and WeakReference is not uncommon 
> (JDK has plenty of such subtypes). 

Ooops, silly me, grep code only reports direct sub-types when querying for 
derived types, am i queried from Reference.

Paul.

> I guess grep code may show the result of a specific JDK release and reports 
> no derived types.  I do think it's extremely rare for those subtypes to 
> implement Cloneable.  So this change should have low compatibility risk.
> 
> Mandy

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Thomas Stüfe]

On Fri, Apr 27, 2018 at 5:01 PM, Baesken, Matthias
 wrote:
>> I see tons of exports listed, most of which do not have the static
>> keyword. So, I would expect them to be exported from their compilation
>> unit, but not from the linked shared library? Am I making a thinking
>> error here?
>
> Hi Thomas , I see  "a ton"  of exported symbols as well  when looking into it 
> (e.g. libjvm.so)  with dump .
> More than one would like to have .
>

Okay, thanks for confirming this! I was not sure if I was using nm
correctly, or if it was lying to me.

> However  for now I think we  should progress with the suggested patch as it 
> is.
>

I agree, patch is fine. Thanks for fixing this.

> Once we switch to xlc 13  (or some follow up release of xlc)  that  supports  
> the visibility attributes
> ( as decribed in   
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html
>   )
>  we can open a follow up item  with compiler flag adjustment and  adjust 
> src/java.base/unix/native/include/jni_md.h , I think this file misses  a 
> proper  JNIEXPORT definition for AIX / xlc 13.1  ).
>

Okay, fine with me.

Best Regards, Thomas

>
> Best regards, Matthias
>
>
>
>> -Original Message-
>> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
>> Sent: Freitag, 27. April 2018 10:04
>> To: Langer, Christoph 
>> Cc: Volker Simonis ; Baesken, Matthias
>> ; Simonis, Volker ;
>> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net; build-
>> d...@openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> 12.1
>>
>> On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
>>  wrote:
>> > Hi Thomas,
>> >
>> > let me cite one section from the article:
>> >
>> > --
>> >
>> > Visibility attribute and backward compatibility on AIX
>> >
>> > As we know from the previous article, on AIX, symbols are not visible by
>> default unless we export them at the linking stage, either manually or with
>> the help of CreateExportList. However, on Linux, symbols are, by default,
>> with export (namely default) visibility. This brings a gap between the AIX
>> visibility attribute and the GNU visibility attribute. To be backward
>> compatible, on AIX, XL C/C++ would not set all the symbols to be exported
>> like Linux. It might consider symbol without any visibility setting to be an
>> unspecific visibility, which aligns with an old AIX implementation. For such
>> symbols, AIX compiler, linker, and related tools would handle it as before.
>> However, unspecific visibility does not mean that the symbol is internal or
>> invisible at all. It is just a visibility that is specially designed to keep 
>> the
>> compatibility.
>> >
>> > ...
>> >
>> > --
>> >
>> > It says in the first sentence: " As we know from the previous article, on 
>> > AIX,
>> symbols are not visible by default unless we export them at the linking 
>> stage,
>> either manually or with the help of CreateExportList". I guess that is why I
>> was under the impression that with xlc12 symbols would not be visible...
>> >
>>
>> :) Thanks for that pointer.
>>
>> I did read:
>>
>> "Consequently, as we have mentioned at the beginning of this article,
>> if the programmer does not explicitly specify the visibility attribute
>> for a symbol, on Linux, the visibility of the symbol could be
>> thedefault. But on AIX, the visibility would be unspecified."
>>
>> So I thought, default is "unspecified", which is not hidden.
>>
>> I just had a look at the libjvm.so from our nightly fastdebug build,
>> using "nm -g".
>>
>> I see tons of exports listed, most of which do not have the static
>> keyword. So, I would expect them to be exported from their compilation
>> unit, but not from the linked shared library? Am I making a thinking
>> error here?
>>
>> Anyway. I do not want to hold up this patch if you guys think it is
>> okay to ignore the compiler warning, so it is okay by me.
>>
>> Best Regards, Thomas
>>
>>
>> > Best regards
>> > Christoph
>> >
>> >> -Original Message-
>> >> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
>> >> Sent: Freitag, 27. April 2018 09:21
>> >> To: Langer, Christoph 
>> >> Cc: Volker Simonis ; Baesken, Matthias
>> >> ; Simonis, Volker
>> ;
>> >> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net;
>> build-
>> >> d...@openjdk.java.net
>> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on 
>> >> xlc
>> 12.1
>> >>
>> >> Hi Christoph
>> >>
>> >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
>> >>  wrote:
>> >> > Hi Thomas,
>> >> >
>> >> > Look at this blog:
>> 

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Baesken, Matthias]

> I see tons of exports listed, most of which do not have the static
> keyword. So, I would expect them to be exported from their compilation
> unit, but not from the linked shared library? Am I making a thinking
> error here?

Hi Thomas , I see  "a ton"  of exported symbols as well  when looking into it 
(e.g. libjvm.so)  with dump .
More than one would like to have .

However  for now I think we  should progress with the suggested patch as it is.

Once we switch to xlc 13  (or some follow up release of xlc)  that  supports  
the visibility attributes 
( as decribed in   
https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html
  )
 we can open a follow up item  with compiler flag adjustment and  adjust 
src/java.base/unix/native/include/jni_md.h , I think this file misses  a 
proper  JNIEXPORT definition for AIX / xlc 13.1  ).
 

Best regards, Matthias



> -Original Message-
> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> Sent: Freitag, 27. April 2018 10:04
> To: Langer, Christoph 
> Cc: Volker Simonis ; Baesken, Matthias
> ; Simonis, Volker ;
> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net; build-
> d...@openjdk.java.net
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
>  wrote:
> > Hi Thomas,
> >
> > let me cite one section from the article:
> >
> > --
> >
> > Visibility attribute and backward compatibility on AIX
> >
> > As we know from the previous article, on AIX, symbols are not visible by
> default unless we export them at the linking stage, either manually or with
> the help of CreateExportList. However, on Linux, symbols are, by default,
> with export (namely default) visibility. This brings a gap between the AIX
> visibility attribute and the GNU visibility attribute. To be backward
> compatible, on AIX, XL C/C++ would not set all the symbols to be exported
> like Linux. It might consider symbol without any visibility setting to be an
> unspecific visibility, which aligns with an old AIX implementation. For such
> symbols, AIX compiler, linker, and related tools would handle it as before.
> However, unspecific visibility does not mean that the symbol is internal or
> invisible at all. It is just a visibility that is specially designed to keep 
> the
> compatibility.
> >
> > ...
> >
> > --
> >
> > It says in the first sentence: " As we know from the previous article, on 
> > AIX,
> symbols are not visible by default unless we export them at the linking stage,
> either manually or with the help of CreateExportList". I guess that is why I
> was under the impression that with xlc12 symbols would not be visible...
> >
> 
> :) Thanks for that pointer.
> 
> I did read:
> 
> "Consequently, as we have mentioned at the beginning of this article,
> if the programmer does not explicitly specify the visibility attribute
> for a symbol, on Linux, the visibility of the symbol could be
> thedefault. But on AIX, the visibility would be unspecified."
> 
> So I thought, default is "unspecified", which is not hidden.
> 
> I just had a look at the libjvm.so from our nightly fastdebug build,
> using "nm -g".
> 
> I see tons of exports listed, most of which do not have the static
> keyword. So, I would expect them to be exported from their compilation
> unit, but not from the linked shared library? Am I making a thinking
> error here?
> 
> Anyway. I do not want to hold up this patch if you guys think it is
> okay to ignore the compiler warning, so it is okay by me.
> 
> Best Regards, Thomas
> 
> 
> > Best regards
> > Christoph
> >
> >> -Original Message-
> >> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> >> Sent: Freitag, 27. April 2018 09:21
> >> To: Langer, Christoph 
> >> Cc: Volker Simonis ; Baesken, Matthias
> >> ; Simonis, Volker
> ;
> >> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net;
> build-
> >> d...@openjdk.java.net
> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> 12.1
> >>
> >> Hi Christoph
> >>
> >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
> >>  wrote:
> >> > Hi Thomas,
> >> >
> >> > Look at this blog:
> https://www.ibm.com/developerworks/aix/library/au-
> >> aix-symbol-visibility-part2/index.html
> >> >
> >> > if I understand it correctly, the xlc 12 default behavior should be like
> what
> >> we'd expect from -qvisibility=hidden.
> >> >
> >>
> >> Where in this article do you read this?
> >>
> >> ..Thomas
> >>
> >> > Best regards
> >> > Christoph
> >> >
> >> >> -Original Message-
> >> >> From: build-dev 

Update to the Double::toString(double) Javadoc

[raffaello . giulietti]

Hi,

as may be known, the current Javadoc for Double::toString(double) is not
specific enough. As a consequence, different implementations can return
different results.

To see this, here are some quotes from the Javadoc. It asks: "How many
digits must be printed for the fractional part of m or a?" It answers:
"There must be at least one digit to represent the fractional part, and
beyond that as many, but only as many, more digits as are needed to
uniquely distinguish the argument value from adjacent values of type
double."

One interpretation is: output "as many" digit of m (or a) itself. But
this can lead to unnecessarily long results. For example, the true value
of the double v closest to 0.3 is
v = 0.299988897769753748434595763683319091796875
so according to this restricted interpretation the method should return
"0.29998"
because shorter prefixes do not round to v.

Another interpretation exploits the astute word "represent" in the
answer, so it might sound: output "as many" digits of a nearby, vaguely
determined "short" number that "represents" m (or a) and happens to
round to v. In this case the obvious choice is
"0.3"
which is the result returned by the method.

One problem with this interpretation is that sometimes there is more
than one choice. For example, both 4.8E-324 and 4.9E-324 round to
Double.MIN_VALUE. The method chooses the latter one, presumably because
it is closer to the double, but this is not specified. It is also not
specified what happens if two equally shortest numbers that round to the
same double are also equally close to it.

Of course, the same holds for Float::toString(float).



The code that was uploaded to this mailing list [1] as a contribution to
fix [2], contains a purportedly better Javadoc that imposes a uniquely
specified result (see method math.DoubleToDecimal::toString(double) ).
It has been carefully written to ensure that the spirit of the current
Javadoc is preserved as much as possible and to make sure that the
results returned by the contributed code and by the current OpenJDK
implementation are consistent (modulo the anomalies discussed in [2]).



The question is if this needs to be submitted to the Compatibility &
Specification Review Group?
If so, what is the correct process to follow for an individual
contributor like me?

I ask because I would like my contribution to be accepted for the next
OpenJDK 11 LTS release: I have no idea on how long it would take for a
spec change to be approved, if the need arises at all in a case like
this one.



Greetings
Raffaello



[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052696.html
[2] https://bugs.openjdk.java.net/browse/JDK-4511638

Re: [11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales

[Rachna Goel]

One correction:

E.g "pa-PK" wil be replaced by "pa-Arab-PK", as former is a 
deprecated/legacy tag.



On 4/27/18 12:05 PM, Rachna Goel wrote:

Hi,

Kindly review the fix for JDK-8179071.

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

Patch: http://cr.openjdk.java.net/~rgoel/JDK-8179071/webrev.03/index.html

Fix is to parse and store language aliases( Deprecated and Legacy ) 
from CLDR's SupplemetalMetaData file. At run time, If a 
deprectaed/legacy locale tag is found, It will be replaced by its 
replacement tag. E.g "pa-PK" will be replaced by "pa-Guru-PK".




--
Thanks,
Rachna

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[forax]

Hi Alan,

People do not read the documentation.
So adding something in the documentation about when a method should be used or 
not is never a solution.

Here the user want a String and provides a charset so you have no way but to 
decode the content to substitute the line separator.

cheers,
Rémi

- Mail original -
> De: "Alan Bateman" 
> À: "Remi Forax" , "Joe Wang" 
> Cc: "nio-dev" , "core-libs-dev" 
> 
> Envoyé: Vendredi 27 Avril 2018 13:34:12
> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for 
> reading/writing a string from/to a file

> On 27/04/2018 12:29, Remi Forax wrote:
>> I think that having a readString that includes OS dependent line separators 
>> is a
>> mistake,
>> Java does a great job to try to shield the developer from the kind of things
>> that makes programs behave differently on different platforms.
>>
>> readString should subtitute (\r)?\n to \n otherwise either people will do a 
>> call
>> replace() which is less efficient or will learn the lesson the hard way.
>>
>> raw string literal does the same substitution for the same reason.
>>
> Yes, there are several discussion points around this and somewhat timely
> with multi-string support.
> 
> One thing that I think Joe will need in this API is some note to make it
> clearer what the intended usage is (as I think the intention is simple
> cases with mostly single lines of text).
> 
> -Alan.

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

[Remi Forax]

This seems to promote the wrong way to do such thing,
the usual use case is that you want to compare the content of a well know file 
with the content of a bunch of other files, so hashing is better.

Rémi

- Mail original -
> De: "Joe Wang" 
> À: "nio-dev" , "core-libs-dev" 
> 
> Envoyé: Vendredi 27 Avril 2018 06:51:08
> Objet: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file 
> contents

> Hi,
> 
> Considering extending isSameFile to add isSameContent to Files. Please
> review.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
> 
> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/
> 
> specdiff:
> http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html
> 
> Thanks,
> Joe

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[Alan Bateman]

On 27/04/2018 12:29, Remi Forax wrote:

I think that having a readString that includes OS dependent line separators is 
a mistake,
Java does a great job to try to shield the developer from the kind of things 
that makes programs behave differently on different platforms.

readString should subtitute (\r)?\n to \n otherwise either people will do a 
call replace() which is less efficient or will learn the lesson the hard way.

raw string literal does the same substitution for the same reason.

Yes, there are several discussion points around this and somewhat timely 
with multi-string support.


One thing that I think Joe will need in this API is some note to make it 
clearer what the intended usage is (as I think the intention is simple 
cases with mostly single lines of text).


-Alan.

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

[Alan Bateman]

On 27/04/2018 05:51, Joe Wang wrote:

Hi,

Considering extending isSameFile to add isSameContent to Files. Please 
review.


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

webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/

specdiff: 
http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html
I assume we should ignore the implementation for now as the eventual 
implementation won't use readAllBytes (at least not for for large files).


The existing isSameFile is specified as "Tests if two paths locate the 
same file" and it would be good if the new method could be somewhat 
consistent with that, e.g. "Tests if the content of two files is identical".


Specifying that two path that locate the same file always returns true 
is reasonable. This could be make clearer by say that the returning 
always returns true when path and path2 are equals, if event if the file 
does not exist.


The @return should say that it returns true if path and path2 locate the 
same file or the content of both files is identical.


The javadoc for SecurityException has "to the file", I assume this 
should be "to both files".


-Alan

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[Remi Forax]

I think that having a readString that includes OS dependent line separators is 
a mistake,
Java does a great job to try to shield the developer from the kind of things 
that makes programs behave differently on different platforms.

readString should subtitute (\r)?\n to \n otherwise either people will do a 
call replace() which is less efficient or will learn the lesson the hard way.

raw string literal does the same substitution for the same reason.

regards
Rémi   

- Mail original -
> De: "Alan Bateman" 
> À: "Joe Wang" 
> Cc: "nio-dev" , "core-libs-dev" 
> 
> Envoyé: Vendredi 27 Avril 2018 13:13:52
> Objet: Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for 
> reading/writing a string from/to a file

> On 27/04/2018 05:50, Joe Wang wrote:
>> Hi,
>>
>> We're looking into adding methods to Files to read a file into a
>> String/write a String to a file. Below is the current proposal. Please
>> review.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8201276
>>
>> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/
>>
>> specdiff:
>> http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html
> The javadoc for these 4 methods looks okay. It might be helpful to
> include something in the readString javadoc to make it absolutely clear
> that the String may include line separators. I assume the "Note that .."
> paragraph can be changed to an @apiNote.
> 
> I assume you'll add "@since 11" to the readString methods.
> 
> It would be good to keep the existing formatting/style consistent with
> the existing code if you can, e.g.  tags, 4 space indent rather than
> 8 for the throws, etc.
> 
> I can't tell from your mail if you are just looking for feedback on the
> current implementation + tests or just the API. I assume there are
> alternatives to using StringBuilder for the readString methods for example.
> 
> -Alan

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[Alan Bateman]

On 27/04/2018 05:50, Joe Wang wrote:

Hi,

We're looking into adding methods to Files to read a file into a 
String/write a String to a file. Below is the current proposal. Please 
review.


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

webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/

specdiff: 
http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html
The javadoc for these 4 methods looks okay. It might be helpful to 
include something in the readString javadoc to make it absolutely clear 
that the String may include line separators. I assume the "Note that .." 
paragraph can be changed to an @apiNote.


I assume you'll add "@since 11" to the readString methods.

It would be good to keep the existing formatting/style consistent with 
the existing code if you can, e.g.  tags, 4 space indent rather than 
8 for the throws, etc.


I can't tell from your mail if you are just looking for feedback on the 
current implementation + tests or just the API. I assume there are 
alternatives to using StringBuilder for the readString methods for example.


-Alan

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

[Jonathan Bluett-Duncan]

Hi Joe,

I wonder if the method `isSameContent` should be named `haveSameContents`
so as to read more fluently in English.

Cheers,
Jonathan

On 27 April 2018 at 11:58, Daniel Fuchs  wrote:

> Hi Joe,
>
> On the specification side, I think I would reword the API
> documentation to first explain how the method checks the
> content of the two files.
>
> The fact that it doesn't check the actual content if
> the two files are 'the same' is kind of an optimization.
>
> So I would suggest to invert the order of the two paragraph
> in the documentation, and combine them into one - something like:
>
> 1536  * 
>   * This method first calls {@link #isSameFile(java.nio.file.Path,
> java.nio.file.Path) isSameFile(path, path2)} to determine whether the two
> files are the same.
> 1537  * If {@code isSameFile(path, path2)} returns false, this method
> will proceed
> 1538  * to read the files and compare them byte by byte to determine
> if they contain
> 1539  * the same contents.
>   * Otherwise, this method will return true without further
>   * processing.
>
>
> On the implementation side I don't think it's reasonable to call
> readAllBytes() and hold the content of the two files in memory
> for comparing their content, especially if it's to discover that
> the first byte differs.
>
> Some lock-step reading of the two files would seem more appropriate.
>
> best regards,
>
> -- daniel
>
>
>
>
>
> On 27/04/2018 05:51, Joe Wang wrote:
>
>> Hi,
>>
>> Considering extending isSameFile to add isSameContent to Files. Please
>> review.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
>>
>> webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/
>>
>> specdiff: http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/jav
>> a/nio/file/Files.html
>>
>> Thanks,
>> Joe
>>
>>
>

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

[Daniel Fuchs]

Hi Joe,

On the specification side, I think I would reword the API
documentation to first explain how the method checks the
content of the two files.

The fact that it doesn't check the actual content if
the two files are 'the same' is kind of an optimization.

So I would suggest to invert the order of the two paragraph
in the documentation, and combine them into one - something like:

1536  * 
  * This method first calls {@link 
#isSameFile(java.nio.file.Path, java.nio.file.Path) isSameFile(path, 
path2)} to determine whether the two files are the same.
1537  * If {@code isSameFile(path, path2)} returns false, this 
method will proceed
1538  * to read the files and compare them byte by byte to determine 
if they contain

1539  * the same contents.
  * Otherwise, this method will return true without further
  * processing.


On the implementation side I don't think it's reasonable to call
readAllBytes() and hold the content of the two files in memory
for comparing their content, especially if it's to discover that
the first byte differs.

Some lock-step reading of the two files would seem more appropriate.

best regards,

-- daniel




On 27/04/2018 05:51, Joe Wang wrote:

Hi,

Considering extending isSameFile to add isSameContent to Files. Please 
review.


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

webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/

specdiff: 
http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html 



Thanks,
Joe

Re: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

[Alan Bateman]

On 27/04/2018 10:10, David Holmes wrote:

Hi Rafael,

On 27/04/2018 6:12 PM, Rafael Winterhalter wrote:

Hello,

I was wondering if the change in ParameterizedType::toString was 
intended.


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

See also the discussion from June 2016 [1] on this change.

I can't tell from your mail if it's the repeated class name or the "$" 
issue that is causing you (and Scala) issues.


-Alan

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041869.html

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

[Bernd Eckenfels]

If this really stays this way and reads all bytes into memory it should at 
least state so, as this can easily overflow heap. Besides the Javadoc is pretty 
specific but fails to mention the size comparison.

Greetings
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: core-libs-dev  on behalf of Joe 
Wang 
Sent: Friday, April 27, 2018 6:51:08 AM
To: nio-dev; core-libs-dev
Subject: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file 
contents

Hi,

Considering extending isSameFile to add isSameContent to Files. Please
review.

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

webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/

specdiff:
http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html

Thanks,
Joe

Re: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

[David Holmes]

Hi Rafael,

On 27/04/2018 6:12 PM, Rafael Winterhalter wrote:

Hello,

I was wondering if the change in ParameterizedType::toString was intended.


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

Cheers,
David
-


I just found my to break after an update due to a test relying on a certain
value for this method.

My example is:

public abstract class AbstractTypeDescriptionGenericTest {
   public static class NestedSpecifiedTypeVariableType {
 NestedSpecifiedTypeVariableType.Placeholder foo;
 class Placeholder { }
   }
}

which changed the toString value for the generic type of "foo"
(NestedSpecifiedTypeVariableType.class.getDeclaredField("foo").getGenericType().toString())
from:

AbstractTypeDescriptionGenericTest.AbstractTypeDescriptionGenericTest$NestedSpecifiedTypeVariableType.Placeholder

to

AbstractTypeDescriptionGenericTest$NestedSpecifiedTypeVariableType$Placeholder

I am wondering if the latter is the new expected format. This does
apparently also break Scala on the latest JDK.

Thanks for any information.
Best regards, Rafael

Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

[Rafael Winterhalter]

Hello,

I was wondering if the change in ParameterizedType::toString was intended.
I just found my to break after an update due to a test relying on a certain
value for this method.

My example is:

public abstract class AbstractTypeDescriptionGenericTest {
  public static class NestedSpecifiedTypeVariableType {
NestedSpecifiedTypeVariableType.Placeholder foo;
class Placeholder { }
  }
}

which changed the toString value for the generic type of "foo"
(NestedSpecifiedTypeVariableType.class.getDeclaredField("foo").getGenericType().toString())
from:

AbstractTypeDescriptionGenericTest.AbstractTypeDescriptionGenericTest$NestedSpecifiedTypeVariableType.Placeholder

to

AbstractTypeDescriptionGenericTest$NestedSpecifiedTypeVariableType$Placeholder

I am wondering if the latter is the new expected format. This does
apparently also break Scala on the latest JDK.

Thanks for any information.
Best regards, Rafael

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Thomas Stüfe]

On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
 wrote:
> Hi Thomas,
>
> let me cite one section from the article:
>
> --
>
> Visibility attribute and backward compatibility on AIX
>
> As we know from the previous article, on AIX, symbols are not visible by 
> default unless we export them at the linking stage, either manually or with 
> the help of CreateExportList. However, on Linux, symbols are, by default, 
> with export (namely default) visibility. This brings a gap between the AIX 
> visibility attribute and the GNU visibility attribute. To be backward 
> compatible, on AIX, XL C/C++ would not set all the symbols to be exported 
> like Linux. It might consider symbol without any visibility setting to be an 
> unspecific visibility, which aligns with an old AIX implementation. For such 
> symbols, AIX compiler, linker, and related tools would handle it as before. 
> However, unspecific visibility does not mean that the symbol is internal or 
> invisible at all. It is just a visibility that is specially designed to keep 
> the compatibility.
>
> ...
>
> --
>
> It says in the first sentence: " As we know from the previous article, on 
> AIX, symbols are not visible by default unless we export them at the linking 
> stage, either manually or with the help of CreateExportList". I guess that is 
> why I was under the impression that with xlc12 symbols would not be visible...
>

:) Thanks for that pointer.

I did read:

"Consequently, as we have mentioned at the beginning of this article,
if the programmer does not explicitly specify the visibility attribute
for a symbol, on Linux, the visibility of the symbol could be
thedefault. But on AIX, the visibility would be unspecified."

So I thought, default is "unspecified", which is not hidden.

I just had a look at the libjvm.so from our nightly fastdebug build,
using "nm -g".

I see tons of exports listed, most of which do not have the static
keyword. So, I would expect them to be exported from their compilation
unit, but not from the linked shared library? Am I making a thinking
error here?

Anyway. I do not want to hold up this patch if you guys think it is
okay to ignore the compiler warning, so it is okay by me.

Best Regards, Thomas


> Best regards
> Christoph
>
>> -Original Message-
>> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
>> Sent: Freitag, 27. April 2018 09:21
>> To: Langer, Christoph 
>> Cc: Volker Simonis ; Baesken, Matthias
>> ; Simonis, Volker ;
>> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net; build-
>> d...@openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> 12.1
>>
>> Hi Christoph
>>
>> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
>>  wrote:
>> > Hi Thomas,
>> >
>> > Look at this blog: https://www.ibm.com/developerworks/aix/library/au-
>> aix-symbol-visibility-part2/index.html
>> >
>> > if I understand it correctly, the xlc 12 default behavior should be like 
>> > what
>> we'd expect from -qvisibility=hidden.
>> >
>>
>> Where in this article do you read this?
>>
>> ..Thomas
>>
>> > Best regards
>> > Christoph
>> >
>> >> -Original Message-
>> >> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf
>> Of
>> >> Thomas Stüfe
>> >> Sent: Freitag, 27. April 2018 06:55
>> >> To: Volker Simonis ; Baesken, Matthias
>> >> 
>> >> Cc: Simonis, Volker ; ppc-aix-port-
>> >> d...@openjdk.java.net; core-libs-dev@openjdk.java.net; build-
>> >> d...@openjdk.java.net
>> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on 
>> >> xlc
>> 12.1
>> >>
>> >> Hi,
>> >>
>> >> This was added by "8200178: Remove mapfiles for JDK native libraries".
>> >> But if the flag is not accepted, what is the default behavior? Do we
>> >> now export everything?
>> >>
>> >> I'd like to understand this first before removing the flag to get rid
>> >> of the warnings.
>> >>
>> >> Best Regards, Thomas
>> >>
>> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
>> >>  wrote:
>> >> > Hi Matthias,
>> >> >
>> >> > after Bhaktavatsal Reddy's report about the problems with
>> >> > "-qvisibility" with xlC 13 and taking into account that we can't test
>> >> > this anyway because we don't currently have xlC 13
>> >> >  on our machines I think it would be best to completely remove this
>> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
>> >> >
>> >> > Thanks,
>> >> > Volker
>> >> >
>> >> >
>> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
>> >> >  wrote:
>> >> >> Hi Matthias,
>> >> >>
>> >> >> At this point, I think we can remove the flag as you found that it 

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Langer, Christoph]

Hi Thomas,

let me cite one section from the article:

--

Visibility attribute and backward compatibility on AIX

As we know from the previous article, on AIX, symbols are not visible by 
default unless we export them at the linking stage, either manually or with the 
help of CreateExportList. However, on Linux, symbols are, by default, with 
export (namely default) visibility. This brings a gap between the AIX 
visibility attribute and the GNU visibility attribute. To be backward 
compatible, on AIX, XL C/C++ would not set all the symbols to be exported like 
Linux. It might consider symbol without any visibility setting to be an 
unspecific visibility, which aligns with an old AIX implementation. For such 
symbols, AIX compiler, linker, and related tools would handle it as before. 
However, unspecific visibility does not mean that the symbol is internal or 
invisible at all. It is just a visibility that is specially designed to keep 
the compatibility.

...

--

It says in the first sentence: " As we know from the previous article, on AIX, 
symbols are not visible by default unless we export them at the linking stage, 
either manually or with the help of CreateExportList". I guess that is why I 
was under the impression that with xlc12 symbols would not be visible...

Best regards
Christoph

> -Original Message-
> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> Sent: Freitag, 27. April 2018 09:21
> To: Langer, Christoph 
> Cc: Volker Simonis ; Baesken, Matthias
> ; Simonis, Volker ;
> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net; build-
> d...@openjdk.java.net
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> Hi Christoph
> 
> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
>  wrote:
> > Hi Thomas,
> >
> > Look at this blog: https://www.ibm.com/developerworks/aix/library/au-
> aix-symbol-visibility-part2/index.html
> >
> > if I understand it correctly, the xlc 12 default behavior should be like 
> > what
> we'd expect from -qvisibility=hidden.
> >
> 
> Where in this article do you read this?
> 
> ..Thomas
> 
> > Best regards
> > Christoph
> >
> >> -Original Message-
> >> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf
> Of
> >> Thomas Stüfe
> >> Sent: Freitag, 27. April 2018 06:55
> >> To: Volker Simonis ; Baesken, Matthias
> >> 
> >> Cc: Simonis, Volker ; ppc-aix-port-
> >> d...@openjdk.java.net; core-libs-dev@openjdk.java.net; build-
> >> d...@openjdk.java.net
> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> 12.1
> >>
> >> Hi,
> >>
> >> This was added by "8200178: Remove mapfiles for JDK native libraries".
> >> But if the flag is not accepted, what is the default behavior? Do we
> >> now export everything?
> >>
> >> I'd like to understand this first before removing the flag to get rid
> >> of the warnings.
> >>
> >> Best Regards, Thomas
> >>
> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
> >>  wrote:
> >> > Hi Matthias,
> >> >
> >> > after Bhaktavatsal Reddy's report about the problems with
> >> > "-qvisibility" with xlC 13 and taking into account that we can't test
> >> > this anyway because we don't currently have xlC 13
> >> >  on our machines I think it would be best to completely remove this
> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
> >> >
> >> > Thanks,
> >> > Volker
> >> >
> >> >
> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
> >> >  wrote:
> >> >> Hi Matthias,
> >> >>
> >> >> At this point, I think we can remove the flag as you found that it is 
> >> >> not
> >> supported in XLC < 13. And with XLC 13, it require more work to use this
> flag.
> >> >>
> >> >> Thanks,
> >> >> Bhaktavatsal Reddy
> >> >>
> >> >>
> >> >>
> >> >> -"Baesken, Matthias"  wrote: -
> >> >> To: "Langer, Christoph" , "'build-
> >> d...@openjdk.java.net'" , "ppc-aix-port-
> >> d...@openjdk.java.net" , "core-
> libs-
> >> d...@openjdk.java.net" 
> >> >> From: "Baesken, Matthias" 
> >> >> Date: 04/26/2018 08:23PM
> >> >> Cc: "Simonis, Volker" , Bhaktavatsal R
> Maram
> >> 
> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on 
> >> >> xlc
> >> 12.1
> >> >>
> >> >>
> >> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported
> (and
> >> probably not working anyway)  for the OpenJDK  build .
> >> >>  I am only aware   of  XLC  versions  

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Thomas Stüfe]

Hi Christoph

On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
 wrote:
> Hi Thomas,
>
> Look at this blog: 
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
>
> if I understand it correctly, the xlc 12 default behavior should be like what 
> we'd expect from -qvisibility=hidden.
>

Where in this article do you read this?

..Thomas

> Best regards
> Christoph
>
>> -Original Message-
>> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of
>> Thomas Stüfe
>> Sent: Freitag, 27. April 2018 06:55
>> To: Volker Simonis ; Baesken, Matthias
>> 
>> Cc: Simonis, Volker ; ppc-aix-port-
>> d...@openjdk.java.net; core-libs-dev@openjdk.java.net; build-
>> d...@openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> 12.1
>>
>> Hi,
>>
>> This was added by "8200178: Remove mapfiles for JDK native libraries".
>> But if the flag is not accepted, what is the default behavior? Do we
>> now export everything?
>>
>> I'd like to understand this first before removing the flag to get rid
>> of the warnings.
>>
>> Best Regards, Thomas
>>
>> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
>>  wrote:
>> > Hi Matthias,
>> >
>> > after Bhaktavatsal Reddy's report about the problems with
>> > "-qvisibility" with xlC 13 and taking into account that we can't test
>> > this anyway because we don't currently have xlC 13
>> >  on our machines I think it would be best to completely remove this
>> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
>> >
>> > Thanks,
>> > Volker
>> >
>> >
>> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
>> >  wrote:
>> >> Hi Matthias,
>> >>
>> >> At this point, I think we can remove the flag as you found that it is not
>> supported in XLC < 13. And with XLC 13, it require more work to use this 
>> flag.
>> >>
>> >> Thanks,
>> >> Bhaktavatsal Reddy
>> >>
>> >>
>> >>
>> >> -"Baesken, Matthias"  wrote: -
>> >> To: "Langer, Christoph" , "'build-
>> d...@openjdk.java.net'" , "ppc-aix-port-
>> d...@openjdk.java.net" , "core-libs-
>> d...@openjdk.java.net" 
>> >> From: "Baesken, Matthias" 
>> >> Date: 04/26/2018 08:23PM
>> >> Cc: "Simonis, Volker" , Bhaktavatsal R Maram
>> 
>> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on 
>> >> xlc
>> 12.1
>> >>
>> >>
>> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  
>> >> (and
>> probably not working anyway)  for the OpenJDK  build .
>> >>  I am only aware   of  XLC  versions  12.1  and 13.1which  work / in 
>> >> case of
>> 13.1  “might” work   for OpenJDK compilation .
>> >>  And for 12.1  I want to remove the flags  .
>> >>
>> >>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  
>> >> prefers it
>> I remove them for all xlC versions including 13.1 )
>> >>
>> >>  Best regards, Matthias
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>  From: Langer, Christoph
>> >>  Sent: Donnerstag, 26. April 2018 16:38
>> >>  To: Baesken, Matthias ; 'build-
>> d...@openjdk.java.net' ; ppc-aix-port-
>> d...@openjdk.java.net; core-libs-dev@openjdk.java.net
>> >>  Cc: Simonis, Volker 
>> >>  Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on 
>> >> xlc
>> 12.1
>> >>
>> >>  Hi Matthias,
>> >>
>> >>  to me the change in principal looks good.
>> >>
>> >>  I’m wondering if it is possible to do a comparison like xlc < 13 (e.g. 
>> >> extract
>> major number before the first dot, then compare numerically) – but maybe it
>> is too complicated and the current single version compare suits  our needs ?
>> >>
>> >>  Best regards
>> >>  Christoph
>> >>
>> >>
>> >>
>> >>
>> >>  From: Baesken, Matthias
>> >>  Sent: Donnerstag, 26. April 2018 16:14
>> >>  To: 'build-...@openjdk.java.net' ; ppc-
>> aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
>> >>  Cc: Langer, Christoph ; Simonis, Volker
>> 
>> >>  Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> >> 12.1
>> >>
>> >>  Hello  ,  could you please review this small adjustment to  the symbol
>> visibility compilation settings on AIX ?
>> >>  Currently  we use  XLC 12.1  to compile  JDK on AIX .
>> >>
>> >>  However XLC 12.1   does not support  the “-qvisibility=hidden”  setting
>> currently set on AIX.
>> >>  It was introduced with  XLC 13.1 . Christoph found some info about it 
>> >> here
>> :
>> >>
>> >>  https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
>> 

Re: (M) RFR: 8200167: Validate more special case invocations

[Tobias Hartmann]

Hi David,

On 27.04.2018 00:04, David Holmes wrote:

>> src/hotspot/share/c1/c1_Canonicalizer.cpp
>> ...
>>   void Canonicalizer::do_CheckCast  (CheckCast*   x) {
>> -  if (x->klass()->is_loaded()) {
>> +  if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check())
>>
>> It seems like it's not something specific to invokespecial, but a generic 
>> problem in how interface
>> casts are handled in C1: it's not correct to eliminate the cast if 
>> obj->declared_type() is an
>> interface. I assume that's what happens in your case. FTR I'm fine with 
>> handling it separately.
> 
> The above came from Tobias. If you think there is a more general issue here 
> then we should file a
> separate bug and formulate a test case.

To clarify, I've quickly debugged this problem before going on vacation and 
rather than a full fix,
the intention of the above change was to quickly verify that the problem is 
indeed an incorrectly
eliminated receiver cast.

I'm also fine with handling this in a separate bug or to push this as a quick 
fix and file a follow
up bug for further investigation if other changes are necessary.

Thanks,
Tobias

[11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales

[Rachna Goel]

Hi,

Kindly review the fix for JDK-8179071.

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

Patch: http://cr.openjdk.java.net/~rgoel/JDK-8179071/webrev.03/index.html

Fix is to parse and store language aliases( Deprecated and Legacy ) from 
CLDR's SupplemetalMetaData file. At run time, If a deprectaed/legacy 
locale tag is found, It will be replaced by its replacement tag. E.g 
"pa-PK" will be replaced by "pa-Guru-PK".


--
Thanks,
Rachna

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Langer, Christoph]

Hi Thomas,

Look at this blog: 
https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
 

if I understand it correctly, the xlc 12 default behavior should be like what 
we'd expect from -qvisibility=hidden.

Best regards
Christoph

> -Original Message-
> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of
> Thomas Stüfe
> Sent: Freitag, 27. April 2018 06:55
> To: Volker Simonis ; Baesken, Matthias
> 
> Cc: Simonis, Volker ; ppc-aix-port-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net; build-
> d...@openjdk.java.net
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> Hi,
> 
> This was added by "8200178: Remove mapfiles for JDK native libraries".
> But if the flag is not accepted, what is the default behavior? Do we
> now export everything?
> 
> I'd like to understand this first before removing the flag to get rid
> of the warnings.
> 
> Best Regards, Thomas
> 
> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
>  wrote:
> > Hi Matthias,
> >
> > after Bhaktavatsal Reddy's report about the problems with
> > "-qvisibility" with xlC 13 and taking into account that we can't test
> > this anyway because we don't currently have xlC 13
> >  on our machines I think it would be best to completely remove this
> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
> >
> > Thanks,
> > Volker
> >
> >
> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
> >  wrote:
> >> Hi Matthias,
> >>
> >> At this point, I think we can remove the flag as you found that it is not
> supported in XLC < 13. And with XLC 13, it require more work to use this flag.
> >>
> >> Thanks,
> >> Bhaktavatsal Reddy
> >>
> >>
> >>
> >> -"Baesken, Matthias"  wrote: -
> >> To: "Langer, Christoph" , "'build-
> d...@openjdk.java.net'" , "ppc-aix-port-
> d...@openjdk.java.net" , "core-libs-
> d...@openjdk.java.net" 
> >> From: "Baesken, Matthias" 
> >> Date: 04/26/2018 08:23PM
> >> Cc: "Simonis, Volker" , Bhaktavatsal R Maram
> 
> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> 12.1
> >>
> >>
> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  
> >> (and
> probably not working anyway)  for the OpenJDK  build .
> >>  I am only aware   of  XLC  versions  12.1  and 13.1which  work / in 
> >> case of
> 13.1  “might” work   for OpenJDK compilation .
> >>  And for 12.1  I want to remove the flags  .
> >>
> >>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  
> >> prefers it
> I remove them for all xlC versions including 13.1 )
> >>
> >>  Best regards, Matthias
> >>
> >>
> >>
> >>
> >>
> >>
> >>  From: Langer, Christoph
> >>  Sent: Donnerstag, 26. April 2018 16:38
> >>  To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' ; ppc-aix-port-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net
> >>  Cc: Simonis, Volker 
> >>  Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on 
> >> xlc
> 12.1
> >>
> >>  Hi Matthias,
> >>
> >>  to me the change in principal looks good.
> >>
> >>  I’m wondering if it is possible to do a comparison like xlc < 13 (e.g. 
> >> extract
> major number before the first dot, then compare numerically) – but maybe it
> is too complicated and the current single version compare suits  our needs ?
> >>
> >>  Best regards
> >>  Christoph
> >>
> >>
> >>
> >>
> >>  From: Baesken, Matthias
> >>  Sent: Donnerstag, 26. April 2018 16:14
> >>  To: 'build-...@openjdk.java.net' ; ppc-
> aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
> >>  Cc: Langer, Christoph ; Simonis, Volker
> 
> >>  Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> >> 12.1
> >>
> >>  Hello  ,  could you please review this small adjustment to  the symbol
> visibility compilation settings on AIX ?
> >>  Currently  we use  XLC 12.1  to compile  JDK on AIX .
> >>
> >>  However XLC 12.1   does not support  the “-qvisibility=hidden”  setting
> currently set on AIX.
> >>  It was introduced with  XLC 13.1 . Christoph found some info about it here
> :
> >>
> >>  https://www.ibm.com/developerworks/aix/library/au-aix-symbol-
> visibility-part2/index.html
> >>
> >>  Setting it  only generates  hundreds  of warnings  in the build log ,
> warnings look like this :
> >>  XlC12.1
> >>
> >>  bash-4.4$ xlC -qversion
> >>  IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
> >>  Version: 12.01..0019
> >>
> >>  bash-4.4$ xlC 

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

[mandy chung]

On 4/27/18 3:35 AM, Paul Sandoz wrote:

Hi Mandy,

This looks reasonable. I suspect external subtypes of the j.l.ref types are 
extremely rare (grep code reports no derived types) and of those it would 
likely be even rarer for those subtypes to implement Cloneable, and for that 
functionality to operate reliably.


Thanks for the review.

Subtypes of java.lang.ref.SoftReference and WeakReference is not 
uncommon (JDK has plenty of such subtypes).  I guess grep code may show 
the result of a specific JDK release and reports no derived types.  I do 
think it's extremely rare for those subtypes to implement Cloneable.  So 
this change should have low compatibility risk.


Mandy

Paul.


On Apr 26, 2018, at 7:16 AM, mandy chung  wrote:

The semantics of cloning a Reference object is not clearly defined. In 
addition, it is questionable whether it can be meaningfully supported in 
particular with concurrent reference processing.

The reachability state of a Reference object may change during GC reference 
processing. The referent may have been cleared when it reaches its reachability 
state. In addition, it may be enqueued or pending for enqueuing. Cloning a 
Reference object with a referent that is unreachable but not yet cleared might 
mean to resurrect the referent. A cloned enqueued Reference object will never 
be enqueued.  A Reference object cannot be meaningfully cloned.

We propose Reference::clone to throw CloneNotSupportedException.  To clone a 
Reference object, it should create a new instance via its constructor.

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

Webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/

Mandy