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
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/op
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 reach
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 mor
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
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
> 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
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
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-8
- 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,
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:
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 Wind
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:
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 Javado
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
> 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 ra
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 Th
> 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 i
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?"
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
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
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é: V
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 subtitu
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/82
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
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/8201
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
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 ord
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
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
___
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
va
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 NestedSpecifiedType
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 visib
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 manuall
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 f
35 matches
Mail list logo