Thank you Roger for your review!
Happy New Year to you too! :)
With kind regards,
Ivan
On 1/9/20 10:36 AM, Roger Riggs wrote:
Hi Ivan,
Happy New Year!
This change looks fine.
Roger
On 11/23/19 2:30 AM, Ivan Gerasimov wrote:
Re-sending the request with the correct Subject line - the bug i
FYI. I changed the year to 2020 and pushed the fix.
Thank you Christoph and Alan!
On 1/6/20 11:49 PM, Alan Bateman wrote:
On 07/01/2020 07:09, Ivan Gerasimov wrote:
So, I filed a Jira bug:
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8236705
WEBREV: http://cr.openjdk.java.net/~igerasim/8
+1
> On Jan 9, 2020, at 2:22 PM, Joe Darcy wrote:
>
> Hello,
>
> As noted by Werner [1], one of the discussions of the kinds of types in
> java.lang.annotation was not updated for records. I checked
> java.lang.annotation, java.lang.reflect, and java.lang.Class and found
> another location t
Hi,
On Fri, 2020-01-03 at 15:37 -0500, Bob Vandette wrote:
> Here are a few comments from scanning the webrev.
>
>
> It looks like you can remove line 151
>
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/06-incremental/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupS
+1
Mandy
On 1/9/20 11:22 AM, Joe Darcy wrote:
Hello,
As noted by Werner [1], one of the discussions of the kinds of types
in java.lang.annotation was not updated for records. I checked
java.lang.annotation, java.lang.reflect, and java.lang.Class and found
another location to update:
J
Hello,
As noted by Werner [1], one of the discussions of the kinds of types in
java.lang.annotation was not updated for records. I checked
java.lang.annotation, java.lang.reflect, and java.lang.Class and found
another location to update:
JDK-8236877: Add "record" to descriptions in java.
Hi Ivan,
Happy New Year!
This change looks fine.
Roger
On 11/23/19 2:30 AM, Ivan Gerasimov wrote:
Re-sending the request with the correct Subject line - the bug is not
(only) about the iterator.
On 11/20/19 10:11 PM, Ivan Gerasimov wrote:
Hello!
When a sublist of a sublist of an ArrayLi
New revision:
http://cr.openjdk.java.net/~mcimadamore/8235837_v2
delta from previous iteration:
http://cr.openjdk.java.net/~mcimadamore/8235837_v2_delta
javadoc
http://cr.openjdk.java.net/~mcimadamore/8235837_v2_javadoc
specdiff
http://cr.openjdk.java.net/~mcimadamore/8235837_v2_specdiff/ov
On 09/01/2020 17:48, Chris Hegarty wrote:
Maurizio,
On 9 Jan 2020, at 14:36, Maurizio Cimadamore
wrote:
Hi,
following the JEP 370 code review and CSR, certain comments that have not been
addressed have been added to the tracker issue:
https://bugs.openjdk.java.net/browse/JDK-8235837
For
Maurizio,
> On 9 Jan 2020, at 14:36, Maurizio Cimadamore
> wrote:
>
> Hi,
> following the JEP 370 code review and CSR, certain comments that have not
> been addressed have been added to the tracker issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8235837
>
> For further evaluation. After
There you go
cr.openjdk.java.net/~mcimadamore/8235837_javadoc
Cheers
Maurizio
On 09/01/2020 15:36, Andrew Haley wrote:
On 1/9/20 2:36 PM, Maurizio Cimadamore wrote:
following the JEP 370 code review and CSR, certain comments that have
not been addressed have been added to the tracker issue:
There's a lot of prior art in JSR166TestCase.java.
In general, junit/testng don't have support for test methods that need to
run code in more than one thread, and jsr166 tck tests do that a lot.
Often you want a higher-level blocking API like:
public void await(CountDownLatch latch, long time
On 1/9/20 2:36 PM, Maurizio Cimadamore wrote:
> following the JEP 370 code review and CSR, certain comments that have
> not been addressed have been added to the tracker issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8235837
Where is the spec? I can't find it linked from anywhere
--
Andre
Hi,
following the JEP 370 code review and CSR, certain comments that have
not been addressed have been added to the tracker issue:
https://bugs.openjdk.java.net/browse/JDK-8235837
For further evaluation. After some discussion in the Panama channel (see
[1] and [2]), the Panama team has come t
I see the the problematic there. At least we should clarify the actual
behavior within the load() method specification stating the current
state.
Having done this the question would be what could be an appropriate
method
name/signature for the new behavior?
loadUnique()
loadDistinct()
or
Hi,
This test-only RFR proposes a tool for timeout testing for the JDK test
library. It runs a task in a separate thread and cancels the task if it
doesn't complete within a given timeout. Any exception thrown by the
task is propagated transparently.
TestNG doesn't currently provide this fun
Looks good - thanks!
Maurizio
On 09/01/2020 08:10, Nick Gasson wrote:
Hi Maurizio,
On 08/01/2020 18:23, Maurizio Cimadamore wrote:
I'm happy to split it into two patches. One with the build/test fixes
for jdk/jdk14 and another with the Unsafe and
internal/foreign/Utils.java change for jdk/jd
On 09/01/2020 09:35, Patrick Reinhart wrote:
He everyone,
When loading a properties file using java.util.Properties.load() the
behaviour for duplicate key values is not yet specified.
The actual implementation overwrites existing key/value defined within
the current file by the further down
He everyone,
When loading a properties file using java.util.Properties.load() the
behaviour for duplicate key values is not yet specified.
The actual implementation overwrites existing key/value defined within
the current file by the further down without any warning or exception.
This has l
Hi Maurizio,
On 08/01/2020 18:23, Maurizio Cimadamore wrote:
I'm happy to split it into two patches. One with the build/test fixes
for jdk/jdk14 and another with the Unsafe and
internal/foreign/Utils.java change for jdk/jdk (or panama/dev?). I
think the most important change for jdk14 is the bu
20 matches
Mail list logo
