Hello Serguei, the com/sun/jdi tests were executed , same number of passed
and errors in a patched and unpatched JDK .
We do not need a sponsor because the change is in JDK not HS .
Best regards, Matthias
-Original Message-
From: serguei.spit...@oracle.com [mailto:serguei.spit...@
Hello Matthias,
It is great, you are able to push this fix!
Thanks,
Serguei
On 5/22/17 01:49, Baesken, Matthias wrote:
Hello Serguei, the com/sun/jdi tests were executed , same number of passed
and errors in a patched and unpatched JDK .
We do not need a sponsor because the change is
Hi Rob,
updated change looks good and does the job (in jdk8 and jdk9) of
eliminating the socket connection build up
regressions tests show no side effects.
noticed what appears to be a peculiarity in the test, in that the test's
server object is exported on the same port as the
Registry! B
There's not likely to be any support for local context anywhere in
java.util.concurrent, but it seems not too hard to roll your own support
with a custom executor to be used with CompletableFuture that kept track of
any local context.
On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo wrote:
> General
https://bugs.openjdk.java.net/browse/JDK-8180767
http://cr.openjdk.java.net/~bpb/8180767/webrev.00/
java.io.File#lastModified() returns zero if the file in question does not
exist. If however the file does exist and by some fantastic improbability has a
last-modified time equal to the epoch, the
I have seen such filesystems in the wild. Imagine that a virtual
filesystem has to make up metadata for an object not actually stored, e.g.
a directory for a file system backed by a source code control system that
does not have directory artifacts. Filesystem authors are likely to pick
the value
So are you suggesting that this would be a bad idea, an incompatible change as
they would be looking for zero instead of unity?
On May 22, 2017, at 1:36 PM, Martin Buchholz wrote:
> I have seen such filesystems in the wild. Imagine that a virtual filesystem
> has to make up metadata for an ob
> On May 19, 2017, at 2:31 PM, joe darcy wrote:
>
> Hello,
>
> Please review the webrev to fix
>
>JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value
>http://cr.openjdk.java.net/~darcy/8074977.3/
This fix looks okay to me. Deferring a more complete solution to JDK
I have no opinion on how to address the problem - just pointing out that
the problem is real.
I might choose an even less likely value than 1 if I were to switch from 0.
(this is not a review!)
On Mon, May 22, 2017 at 1:38 PM, Brian Burkhalter <
brian.burkhal...@oracle.com> wrote:
> So are you
On May 22, 2017, at 1:42 PM, Martin Buchholz wrote:
> I have no opinion on how to address the problem - just pointing out that the
> problem is real.
>
> I might choose an even less likely value than 1 if I were to switch from 0.
Perhaps Long.MAX_VALUE.
> (this is not a review!)
Not so i
Heya Josh,
I only want this question to be discussed on ci rather on core-libs-dev :-) I'm
not the OP.
> On 22 May 2017, at 23:01, Josh Humphries wrote:
>
> Pavel,
> It sounds like you want
[...]
http://cr.openjdk.java.net/~iignatyev//8180802/webrev.00/index.html
> 143 lines changed: 71 ins; 72 del; 0 mod;
Hi all,
could you please review this patch which moves ThreadMXBeanTool from jdk
testlibrary to the top level testlibrary?
please be aware that there are tests outside jdk repository w
On 5/19/17 11:59 AM, Brian Burkhalter wrote:
https://bugs.openjdk.java.net/browse/JDK-6791812
--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -932,7 +932,9 @@
* @return A long value representing the time the file was
*
On May 22, 2017, at 3:52 PM, Stuart Marks wrote:
>> --- a/src/java.base/share/classes/java/io/File.java
>> +++ b/src/java.base/share/classes/java/io/File.java
>> @@ -932,7 +932,9 @@
>> * @return A long value representing the time the file was
>> * last modified, measured in mi
On 5/22/17 1:45 PM, Brian Burkhalter wrote:
On May 22, 2017, at 1:42 PM, Martin Buchholz wrote:
I have no opinion on how to address the problem - just pointing out that the
problem is real.
I might choose an even less likely value than 1 if I were to switch from 0.
Perhaps Long.MAX_VALU
On May 22, 2017, at 4:15 PM, Stuart Marks wrote:
> So yes, I'd say that returning 1L (or any other value) instead of 0L would be
> an incompatible change.
I think the correct solution would be to throw a FNFE for a non-extant file but
that is also incompatible.
> The specification for File.la
16 matches
Mail list logo
