In that case I’ll verify the state of affairs and file one if needed.
Thanks,
Brian
On Mar 13, 2015, at 2:55 PM, joe darcy wrote:
> If the null handling is not implied by another part of the spec, it should
> have a ccc.
>
> Cheers,
>
> -Joe
>
> On 3/13/2015 2:53 PM, Brian Burkhalter wrote
If the null handling is not implied by another part of the spec, it
should have a ccc.
Cheers,
-Joe
On 3/13/2015 2:53 PM, Brian Burkhalter wrote:
This is too trivial for a CCC request, no?
Thanks,
Brian
On Mar 13, 2015, at 2:08 PM, joe darcy wrote:
Looks fine Brian; thanks,
-Joe
On 3/
This is too trivial for a CCC request, no?
Thanks,
Brian
On Mar 13, 2015, at 2:08 PM, joe darcy wrote:
> Looks fine Brian; thanks,
>
> -Joe
>
> On 3/13/2015 1:40 PM, Brian Burkhalter wrote:
>> Please review at your convenience.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-807
Looks good Brian; thanks,
-Joe
On 3/13/2015 2:45 PM, Brian Burkhalter wrote:
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8075110
Diff:
--- a/test/java/util/prefs/CodePointZeroPrefsTest.java
+++ b/test/java/util/prefs/CodePointZeroPrefsTest.java
@@ -27,6
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8075110
Diff:
--- a/test/java/util/prefs/CodePointZeroPrefsTest.java
+++ b/test/java/util/prefs/CodePointZeroPrefsTest.java
@@ -27,6 +27,7 @@
/*
* @test
* @bug 8068373
+ * @requires os.family == "linux" | os.
Looks fine Brian; thanks,
-Joe
On 3/13/2015 1:40 PM, Brian Burkhalter wrote:
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8073214
Patch: http://cr.openjdk.java.net/~bpb/8073214/webrev.00/
Lines 316 and 342 in Properties.java are not strictly necessary b
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8073214
Patch: http://cr.openjdk.java.net/~bpb/8073214/webrev.00/
Lines 316 and 342 in Properties.java are not strictly necessary but make it a
little more fail-fast.
Thanks,
Brian
> On 13 Mar 2015, at 17:58, Peter Levart wrote:
>
> On 03/12/2015 11:24 PM, Peter Levart wrote:
>>> So if a readObject calls fields() without calling defaultReadObject() then
>>> it has to set every final field. On one hand that ensures that every final
>>> field is set, on the other hand it i
I've tried to address all the points that have been made.
I haven't changed the way the sub-words are read and written because
the code I'm seeing is fairly nearly optimal right now and anything
more complex runs the risk of tripping inlining limits, thus
pessimizing performance. We need a genera
I've tried to address all the points that have been made.
I haven't changed the way the sub-words are read and written because
the code I'm seeing is fairly nearly optimal right now and anything
more complex runs the risk of tripping inlining limits, thus
pessimizing performance. We need a genera
On 13/03/2015 17:40, joe darcy wrote:
Hello,
To support stricter doclint checking for the jdk.compiler module
(http://mail.openjdk.java.net/pipermail/build-dev/2015-March/014560.html),
some javadoc needs to be added to a class for the serialver tool which
is in the jdk repo. Patch below.
I'
On 03/13/2015 05:10 PM, Chris Hegarty wrote:
So if this doesn't have much sense and brings confusion, it can go away.
If we have consensus then I can remove this, artificial, restriction.
Objections?
Hi Chris,
I think the part that checks that a final field is not set more than
once is
On 03/12/2015 11:24 PM, Peter Levart wrote:
So if a readObject calls fields() without calling defaultReadObject()
then it has to set every final field. On one hand that ensures that
every final field is set, on the other hand it is a bit odd because
omitting the call to fields() means they al
looks ok joe
On Mar 13, 2015, at 1:40 PM, joe darcy wrote:
> Hello,
>
> To support stricter doclint checking for the jdk.compiler module
> (http://mail.openjdk.java.net/pipermail/build-dev/2015-March/014560.html),
> some javadoc needs to be added to a class for the serialver tool which is in
Hello,
To support stricter doclint checking for the jdk.compiler module
(http://mail.openjdk.java.net/pipermail/build-dev/2015-March/014560.html),
some javadoc needs to be added to a class for the serialver tool which
is in the jdk repo. Patch below.
I'm not quite sure why serialver is the t
On 12/03/15 16:35, Paul Sandoz wrote:
...
Webrev updated:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/
Looks good to me.
-Chris.
Paul.
Alan,
Thanks for taking the time to try this out.
On 12/03/15 22:24, Peter Levart wrote:
Hi Alan,
I've spent some time looking at this and trying it out. It's very
simple, doesn't impact any existing readObject implementations, and
provides a way to set final fields without restoring to
On 03/13/2015 02:35 PM, Roger Riggs wrote:
Hi Peter,
Right, that is the preferred handling.
In this case, the forwarded interrupt will be passed back to the
Thread from the ThreadPool
and is disregarded there.
I thought that too, but is not necessarily so. For example:
Process p = ...
p.on
Hi Peter,
If delegating to another Process and not needing to return the CF
then the overridden implementation might be:
public CompletableFuture onExit() {
return delegate.onExit();
}
The .thenApply(ph -> this) would be needed only for the return value to
be CF.
The explanatio
Hi Peter,
Right, that is the preferred handling.
In this case, the forwarded interrupt will be passed back to the Thread
from the ThreadPool
and is disregarded there.
Roger
On 3/13/2015 3:56 AM, Peter Levart wrote:
...in addition, I would also try not to swallow interrupts in default
implem
On 3/13/15 6:44 PM, Paul Sandoz wrote:
On Mar 13, 2015, at 11:34 AM, Amy Lu wrote:
Testcase testFlatMappingClose was newly introduced in JDK-8071600 in
CollectorsTest, this test should be marked as serialization-hostile (such tests
will ignored by by lambda serialization testing framework).
On Mar 13, 2015, at 11:34 AM, Amy Lu wrote:
> Testcase testFlatMappingClose was newly introduced in JDK-8071600 in
> CollectorsTest, this test should be marked as serialization-hostile (such
> tests will ignored by by lambda serialization testing framework).
>
> bug: https://bugs.openjdk.java
Testcase testFlatMappingClose was newly introduced in JDK-8071600 in
CollectorsTest, this test should be marked as serialization-hostile
(such tests will ignored by by lambda serialization testing framework).
bug: https://bugs.openjdk.java.net/browse/JDK-8075111
webrev: http://cr.openjdk.java.n
On 12/03/15 22:02, Vitaly Davidovich wrote:
> Is vectorization coming soon? AFAIK, only memory copies are vectorized
> currently but not any arithmetic or the like.
That's true, but the idea is that this is future-proof and will work
well when we get vectorized scatter/gather memory accesses.
The
On 12/03/15 22:15, Vitaly Davidovich wrote:
> Switches currently don't profile well (if at all) - John can shed more
> light on that as this came up on the compiler list a few weeks ago.
My first version used switches and the generated code was horrible.
The version I submitted generates optimal (
...in addition, I would also try not to swallow interrupts in default
implementation:
public CompletableFuture onExit() {
return CompletableFuture.supplyAsync(() -> {
boolean interrupted = false;
while (true) {
try {
waitFo
Hi Rogger,
Now that the method has a non-throwing default implementation, what do
you think of the following implementation note for Process.onExit():
* @implNote
* The default implementation of this method employs a thread from
* {@link java.util.concurrent.ForkJoinPool#commonP
27 matches
Mail list logo
