On 23/04/2015 21:22, Remi Forax wrote:
On 04/23/2015 04:41 PM, Alan Bateman wrote:
On 23/04/2015 13:22, Remi Forax wrote:
I think the name readBytes is not very informative and the name is
too close to read + an array of bytes,
we can not use readFully (from DataInput/DataInputStream) becaus
On 24/04/2015 02:54, Joseph D. Darcy wrote:
Hello,
Any additional comments on marking with tests in question with a
"randomness" keyword?
Thanks,
-Joe
I don't object to this keyword although I should say that most of the
(apparent) randomness that I've seen hasn't been because of tests usi
Hello,
Any additional comments on marking with tests in question with a
"randomness" keyword?
Thanks,
-Joe
On 4/21/2015 7:13 PM, Joseph D. Darcy wrote:
Hello,
As the next step of implementing "Proposed new policies for JDK 9
regression tests: tiered testing, intermittent failures, and
ra
Hi Peter,
Setting the user.timezone property doesn't reset the value returned from
getDefaultRef().
You can see the new value through java.util.TimeZone but not through
java.time.ZoneId.
Its a bad idea to allow the default timezone change and in java.time it
was purposefully
handled as an i
Hi Pavel,
On 4/23/2015 5:12 PM, Pavel Rappo wrote:
Hey Roger,
1. Good catch! This thing also applies to java.io.InputStream.read(byte[], int,
int):
* In every case, elements b[0] through
* b[off] and elements b[off+len] through
* b[b.length-1] are unaffected.
I suppose the
On 04/23/2015 10:33 PM, Roger Riggs wrote:
Hi Peter,
The defaultTimeZone is cached in java.util.TimeZone the first time it
is referenced
and is not updated after that. See java.util.TimeZone.getDefaultRef().
Regards, Roger
But any code (with enough privilege) can update it:
abstract pu
Hey Roger,
1. Good catch! This thing also applies to java.io.InputStream.read(byte[], int,
int):
* In every case, elements b[0] through
* b[off] and elements b[off+len] through
* b[b.length-1] are unaffected.
I suppose the javadoc for the method proposed by Chris has started its
Hi Peter,
The defaultTimeZone is cached in java.util.TimeZone the first time it is
referenced
and is not updated after that. See java.util.TimeZone.getDefaultRef().
Regards, Roger
On 4/23/2015 4:11 PM, Peter Levart wrote:
On 04/23/2015 09:53 PM, nadeesh tv wrote:
Hi all,
Please review
Hi Chris,
A minor inconsistency about the unmodified contents of b[off].
* The first byte read is stored into element {@code b[off]}
vs.
* In every case, elements {@code b[0]} through {@code b[off *-
1*]} and
* elements__{@code b[off+len]} through {@code b[b.length-1]} are
unaffected.
On 04/23/2015 04:41 PM, Alan Bateman wrote:
On 23/04/2015 13:22, Remi Forax wrote:
I think the name readBytes is not very informative and the name is
too close to read + an array of bytes,
we can not use readFully (from DataInput/DataInputStream) because
instead of returning the number of byte
On 04/23/2015 06:21 PM, Chris Hegarty wrote:
On 23 Apr 2015, at 16:58, Bernd Eckenfels wrote:
Hello,
I would use the already established name readFully(byte[]) and
readFully(byte[],int,int) to be consistent with DataInputStream.
I purposefully stayed away from the name ‘readFully' as the s
On 04/23/2015 09:53 PM, nadeesh tv wrote:
Hi all,
Please review this minor change which optimized
Clock.systemDefaultZone() and Clock.system(ZoneId) to avoid creating
new instance of Clock.SystemClock every time they are called.
Bug ID : https://bugs.openjdk.java.net/browse/JDK-8074023
On 04/23/2015 06:21 PM, Chris Hegarty wrote:
On 23 Apr 2015, at 16:58, Bernd Eckenfels wrote:
Hello,
I would use the already established name readFully(byte[]) and
readFully(byte[],int,int) to be consistent with DataInputStream.
I purposefully stayed away from the name ‘readFully' as the
Hi all,
Please review this minor change which optimized
Clock.systemDefaultZone() and Clock.system(ZoneId) to avoid creating
new instance of Clock.SystemClock every time they are called.
Bug ID : https://bugs.openjdk.java.net/browse/JDK-8074023
Webrev : http://cr.openjdk.java.net/~rriggs/
Hello again,
forgive me; this is the wrong list.
Best,
Michael
> Am 23.04.2015 um 21:08 schrieb Michael Haupt :
>
> Hello,
>
> please review and sponsor this change.
> RFE: https://bugs.openjdk.java.net/browse/JDK-8030680
> Webrev: http://cr.openjdk.java.net/~mhaupt/8030680/webrev.00/
>
> Th
Hello,
please review and sponsor this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8030680
Webrev: http://cr.openjdk.java.net/~mhaupt/8030680/webrev.00/
This is a set of simple changes to increase robustness. Tested locally with
jtreg for java.lang.invoke, and with JPRT using the hotspo
Hi Aleksej,
The backport looks fine to me.
Best,
Joe
On 4/22/2015 7:12 AM, Aleksej Efimov wrote:
Hello,
Can I ask for approval of the JDK-8073357 [2] bug fix [1] to JDK8. The
original fix contains only test modifications, but the jaxws part was
introduced during JAXWS synchronization [3] in
On 23 Apr 2015, at 16:58, Bernd Eckenfels wrote:
> Hello,
>
> I would use the already established name readFully(byte[]) and
> readFully(byte[],int,int) to be consistent with DataInputStream.
I purposefully stayed away from the name ‘readFully' as the spec for
DataInputStream.readFully and th
On 23 Apr 2015, at 17:10, Peter Levart wrote:
> On 04/23/2015 04:50 PM, Chris Hegarty wrote:
>> Peter,
>>
>> Ah, good point. Do we really need a new Exception type for this, is this
>> information really that useful? How can you recover?
>>
>> What if this error condition was better cover in t
On 04/23/2015 04:50 PM, Chris Hegarty wrote:
Peter,
Ah, good point. Do we really need a new Exception type for this, is this
information really that useful? How can you recover?
What if this error condition was better cover in the API.
* If an I/O error occurs reading from the input stream
Right you are, David. So this exception could be reused albeit the cause
of "interruption" can be arbitrary IOException thrown in the midst of
two read() calls. But the caller need not care as the outcome is the same.
Regards, Peter
On 04/23/2015 04:30 PM, David M. Lloyd wrote:
I believe this
Hello,
I would use the already established name readFully(byte[]) and
readFully(byte[],int,int) to be consistent with DataInputStream.
Gruss
Bernd
On Apr 23, 2015, at 5:12 PM, Vladimir Ivanov
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8059455
> http://cr.openjdk.java.net/~vlivanov/8059455/webrev.00/
>
> LambdaForm.compileToBytecode() does unnecessary work (constructs invokerType
> & check an assertion) before ensuring that Lambda
https://bugs.openjdk.java.net/browse/JDK-8059455
http://cr.openjdk.java.net/~vlivanov/8059455/webrev.00/
LambdaForm.compileToBytecode() does unnecessary work (constructs
invokerType & check an assertion) before ensuring that LambdaForm hasn't
been already compiled. It happens very often for cac
Peter,
Ah, good point. Do we really need a new Exception type for this, is this
information really that useful? How can you recover?
What if this error condition was better cover in the API.
* If an I/O error occurs reading from the input stream, then it may do
* so after some, but not all, by
On 23/04/2015 13:22, Remi Forax wrote:
I think the name readBytes is not very informative and the name is too
close to read + an array of bytes,
we can not use readFully (from DataInput/DataInputStream) because
instead of returning the number of bytes read, it throws a
EOFException if the end o
I believe this is similar to how InterruptedIOException works, FWIW.
On 04/23/2015 09:20 AM, Peter Levart wrote:
Hi Chris,
Currently InputStream guarantees that either some bytes are read *xor*
EOF (-1) is returned *xor* IOException is thrown. Even with default
implementation of read(byte[], in
Hi Chris,
Currently InputStream guarantees that either some bytes are read *xor*
EOF (-1) is returned *xor* IOException is thrown. Even with default
implementation of read(byte[], int, int) which is implemented in terms
of int read(). This new method can throw IOException after some bytes
hav
On Apr 23, 2015, at 3:23 PM, Chris Hegarty wrote:
> Thanks for bringing this in Paul. The change looks ok to me, and suitable for
> backport.
>
> Trivially, the test does not need the Classpath exception in its license
> header.
>
Doh, thanks, updated locally.
When i create a new class th
Thanks for bringing this in Paul. The change looks ok to me, and suitable for
backport.
Trivially, the test does not need the Classpath exception in its license header.
-Chris.
On 23 Apr 2015, at 14:00, Paul Sandoz wrote:
> Hi.
>
> Please review this patch from Doug that fixes an issue where
Hi.
Please review this patch from Doug that fixes an issue where a submitted task
to a f/j pool never gets executed.
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8078490-fj-missed-submissions/webrev/
I already counted myself and Alexey as reviewers.
The issue manifests itself under certain
I think the name readBytes is not very informative and the name is too
close to read + an array of bytes,
we can not use readFully (from DataInput/DataInputStream) because
instead of returning the number of bytes read, it throws a EOFException
if the end of the stream is reached.
so what about
Hi Chris,
The spec looks good. The only single detail I've noticed is that the "an
exception is thrown" as a possible cause of unblocking the method is missing:
--- dev/jdk/src/java.base/share/classes/java/io/InputStream.java (revision )
+++ dev/jdk/src/java.base/share/classes/java/io/InputStre
A while back when we added the long overdue java.io.InputStream.transferTo
method, there was support for adding a blocking bulk read operation. This has
been sitting in a branch in the sandbox since then. I would like to revive it
with the intention of bringing it into 9. The motivation for this
On 23/04/2015 02:08, joe darcy wrote:
Hello,
Earlier in JDK 9, the diamond syntax was expanded to be usable with
many cases of anonymous classes. [1]
Please review the fix below take advantage of the new syntax (and also
take advantage of the original diamond syntax in some cases) in the
co
35 matches
Mail list logo
