://cr.openjdk.java.net/~chegar/readBytes/webrev.00
-Chris.
On 7 May 2015, at 15:10, Chris Hegarty chris.hega...@oracle.com wrote:
Thanks for the comments. All have been considered and incorporated ( where
applicable ).
I sketched out a readAllBytes, added some basic tests, and moved this into a
webrev. I
,
Patrick
On 2015-05-13 12:12, Chris Hegarty wrote:
Given your previous contributions [1] and ongoing involvement in
OpenJDK, it would be reasonable for you to request an author role [2]
for the JDK 9 project. An author has an account on
cr.openjdk.java.net. But of course, this is your choice
10.05.2015 um 21:16 schrieb Chris Hegarty chris.hega...@oracle.com:
I have not looked at the changes in detail yet, but I think it is going in the
right direction. Just a few comments:
On 13 May 2015, at 22:45, Remi Forax fo...@univ-mlv.fr wrote:
may return 0, is when len == 0. And it's never the case here. Unless, of
course,
some misbehaving implementation of InputStream is used.
The other reason to have read that returns 0 is if the underlying channel is
in
Hi Alexander,
On 13/05/15 15:52, Alexander Kulyakhtin wrote:
Hi,
Could you please, review the following tests-only changes to the hs-rt/jdk and hs-rt/test
repositories. These changes are a part of the changes for JDK-8075327: Merge jdk
and hotspot test libraries
I suspect that these
Alexander,
On 13 May 2015, at 16:46, Alexander Kulyakhtin
alexander.kulyakh...@oracle.com wrote:
Hi Chris,
I suspect that these changes are best going directly into jdk9/dev, as
opposed to a a downstream forest.
Yes, they are going directly to jdk9/dev, I forgot to add the group,
I have not looked at the changes in detail yet, but I think it is going in the
right direction. Just a few comments:
On 9 May 2015, at 00:00, Patrick Reinhart patr...@reini.net wrote:
diff -r 7101bcceb43d make/src/classes/build/tools/module/ModuleArchive.java
---
Looks ok to me Felix.
-Chris.
On 08/05/15 15:57, FELIX YANG wrote:
Hi all,
java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java
has been observed to fail intermittently. This fix is to mark it with
keyword 'intermittent'.
Bug:
, is this referring to computeIfAbsent? I think a small
comment about concurrency would be sufficient.
-Chris.
-Pavel
On 21 Apr 2015, at 09:08, Chris Hegarty chris.hega...@oracle.com wrote:
On 21 Apr 2015, at 03:00, David Holmes david.hol...@oracle.com wrote:
On 21/04/2015 1:24 AM, Chris Hegarty wrote
this version, less review comments, covers the most common use-cases.
http://cr.openjdk.java.net/~chegar/readBytes/webrev.00/
-Chris.
On 5 May 2015, at 10:54, Alan Bateman alan.bate...@oracle.com wrote:
On 02/05/2015 09:27, Chris Hegarty wrote:
:
Thanks, this was an editing issue. Removed.
I think
Thanks for looking at this Roger.
On 1 May 2015, at 15:20, Roger Riggs roger.ri...@oracle.com wrote:
Hi Chris,
There is some duplication in the descriptions of the buffer contents; see
below.
On 5/1/2015 5:54 AM, Chris Hegarty wrote:
This latest version addresses all comments so far
/04/15 09:44, Chris Hegarty wrote:
On 23 Apr 2015, at 22:24, Roger Riggs roger.ri...@oracle.com wrote:
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):
Yes, good catch indeed.
* p
java/lang/Runtime/exec/LotsOfOutput.java fails intermittently with Process
consumes memory
On 4/28/2015 3:56 AM, Chris Hegarty wrote:
On 27 Apr 2015, at 21:54, Roger Riggs roger.ri...@oracle.com wrote:
Please review adding diagnostic output to identify an intermittent failure.
I agree
On 28 Apr 2015, at 01:44, Brian Burkhalter brian.burkhal...@oracle.com wrote:
Hi Joe,
On Apr 27, 2015, at 5:32 PM, joe darcy joe.da...@oracle.com wrote:
The patch looks pretty good. A few questions / comments:
The test ParseHexFloatingPoint.java didn't get the (use -Dseed=X to set
On 27 Apr 2015, at 21:54, Roger Riggs roger.ri...@oracle.com wrote:
Please review adding diagnostic output to identify an intermittent failure.
I agree with the adding additional diagnostic output. Maybe the bug description
should be updated to indicate that?
Webrev:
On 23 Apr 2015, at 17:10, Peter Levart peter.lev...@gmail.com 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
was thrown.
*/
public int getBytesRead() {
return bytesRead;
}
}
Regards, Peter
On 04/23/2015 11:01 AM, Chris Hegarty wrote:
A while back when we added the long overdue java.io.InputStream.transferTo
method, there was support for adding a blocking
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
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 paul.san...@oracle.com wrote:
Hi.
Please review this patch from Doug that
On 21 Apr 2015, at 03:00, David Holmes david.hol...@oracle.com wrote:
On 21/04/2015 1:24 AM, Chris Hegarty wrote:
On 20/04/15 16:17, Lance Andersen wrote:
Hi Pavel,
So we are just documenting/clarifying the current behavior from what I
can tell from the change?
Looking at the testcase
On 20/04/15 16:17, Lance Andersen wrote:
Hi Pavel,
So we are just documenting/clarifying the current behavior from what I can tell
from the change?
Looking at the testcase, it passes with the current JDK 9 ( and 8 ), so
this is just documenting existing behavior.
If so, this looks OK
On 13 Apr 2015, at 17:29, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Hi!
Preparing a backport to 8, I found that some files aren't properly mapped
from 9 to 8.
Thank you for updating this list. The change looks good to me.
-Chris.
The following simple patch fixes the issue:
---
This is a request for review for a small change to address 8076442 [1].
Seems to be a day one bug in the internal BitSetIterator, for a boundary
condition when the Integer.MAX_VALUE bit is set. The change to the iterator,
and test, is in line with the advise in BitSet.nextSetBit(int) (
Peter,
Some more thought is needed in that area of the field setter API. If there are
no strong objections, then I’d like to proceed with this version of better
failure atomicity, and follow up as needed.
-Chris.
On 20 Mar 2015, at 16:30, Chris Hegarty chris.hega...@oracle.com wrote:
Hi
On 3 Apr 2015, at 14:20, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi Kasper,
I assume your questions are all about WebSocket part, right? If so, then
1)
Would it possible to add a connect timeout parameter.
builder.setConnectTimeout(long timeout, TimeUnit unit)
For some reason it
On 27/03/15 19:24, Mark Sheppard wrote:
Hi
based on feedback webrev has been updated as follows:
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev.01/
The changes in the corba repo look good to me Mark.
-Chris.
Just an update on this...
Checking of final fields aside, the Field Setter API, in its current
form, has become stuck. It falls foul of the fact that ObjectInputStream
is subclass-able, and contains almost no final methods, or at least no
implementation that can be counted on, or appropriate
On 24/03/15 19:25, Martin Buchholz wrote:
On Tue, Mar 24, 2015 at 7:42 AM, Chris Hegarty chris.hega...@oracle.com
mailto:chris.hega...@oracle.com wrote:
3) process reaper”, maybe
“Process-Reaper-“ + monotonically increasing ID ( similar to
ForkJoin worker threads
Peter,
On 25/03/15 12:24, Peter Levart wrote:
On 03/23/2015 04:45 PM, Chris Hegarty wrote:
Here is an updated version of the FieldSetter API, with all comments
to date incorporated.
http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html
Final spec comments welcome
On 25 Mar 2015, at 17:32, Peter Levart peter.lev...@gmail.com wrote:
On 03/25/2015 05:55 PM, Peter Levart wrote:
On 03/25/2015 04:49 PM, Chris Hegarty wrote:
I have been thinking about this and I see several solutions:
1. provide protected final methods
segments.
+ */
private static final ObjectStreamField[] serialPersistentFields = {
new ObjectStreamField(segments, Segment[].class),
new ObjectStreamField(segmentMask, Integer.TYPE),
On Tue, Mar 24, 2015 at 2:38 AM, Chris Hegarty chris.hega...@oracle.com
mailto:chris.hega
On 23 Mar 2015, at 21:25, Mark Sheppard mark.shepp...@oracle.com wrote:
….
ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
This resulted in modification to the readObject and writeObject methods,
and in particular, former serial fields were removed, resulting in
for testing with ;-(
-Chris.
my original fix had similar PutField change to writeObject, but I left it
from this review so
that it could be addressed separately.
regards
Mark
On 24/03/2015 09:38, Chris Hegarty wrote:
Martin,
On 23 Mar 2015, at 22:15, Martin Buchholz marti...@google.com
Martin,
On 23 Mar 2015, at 22:15, Martin Buchholz marti...@google.com wrote:
Let us know if the serialization code of the collection classes can be
improved.
I think there are a few minor cleanups that would be beneficial in CHM:
1) Add @serialField so that the serializable stream fields
Roger,
I think the API is looking much better now ( just a few comments below on small
specific issues ), so I’ve taken a pass over the implementation changes in the
sandbox. Here are some comments:
1) Some operations on ProcessHandle require RuntimePermission
manageProcess, but I don't
Thanks for the feedback Alan.
On 24 Mar 2015, at 11:27, Alan Bateman alan.bate...@oracle.com wrote:
On 23/03/2015 15:45, Chris Hegarty wrote:
Here is an updated version of the FieldSetter API, with all comments to date
incorporated.
http://cr.openjdk.java.net/~chegar/8071472/02/specdiff
On 24 Mar 2015, at 17:32, Roger Riggs roger.ri...@oracle.com wrote:
...
2) Can ProcessImpl.waitForProcessExit and its native counterpart be
removed? ( since its function is now performed through ProcessHandleImpl
)
I'll look at that again; the two behaviors:
1) waiting for and reaping
I wonder if we, optionally, pass the exception type, either CME or IAE,
could we add CHM to the DataProvider?
On 21/03/15 13:43, Paul Sandoz wrote:
On Mar 20, 2015, at 10:23 PM, Brent Christian brent.christ...@oracle.com
wrote:
Here's the latest:
On 20/03/15 22:23, Martin Buchholz wrote:
I probably implemented it the way it is intentionally. I would leave it.
Just move
long remainingNanos = unit.toNanos(timeout);
...
Webrev:
://cr.openjdk.java.net/~rriggs/webrev-npe-8067796/
Either change is fine with me. I do like
Here is an updated version of the FieldSetter API, with all comments to
date incorporated.
http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html
Final spec comments welcome, after which I intend to submit a CCC request.
-Chris.
On 23/03/15 11:35, Paul Sandoz wrote:
On Mar 23, 2015, at 12:16 PM, Chris Hegarty chris.hega...@oracle.com wrote:
I wonder if we, optionally, pass the exception type, either CME or IAE, could
we add CHM to the DataProvider?
Possibly, but I suspect any tests for CHM will be more fragile
On 20 Mar 2015, at 09:52, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 19, 2015, at 11:31 PM, Brent Christian brent.christ...@oracle.com
wrote:
Hi, Paul
Thank you for the suggested doc adjustments. They're applied here:
http://cr.openjdk.java.net/~bchristi/8071667/webrev.3/
Trivial change that came up a few months ago, and again recently, that
java.util.Date should call default[Read|Write]Object to strictly conform to the
Serialization spec ( even though it does not have any persistent state, which
it could conceivably do at some point in the future, but probably
On 20 Mar 2015, at 13:03, David M. Lloyd david.ll...@redhat.com wrote:
...
An interesting aspect of this approach is that it deals with a problem in the
serialization spec [1] where it specifically says that serializable classes
should be reading/writing stream fields always, and before
Hi Peter,
On 20 Mar 2015, at 14:06, Peter Levart peter.lev...@gmail.com wrote:
On 03/19/2015 10:26 PM, Chris Hegarty wrote:
The current implementation of defaultReadObject sets non-primitive field
values one at a time, without first checking that all their types are
assignable
The current implementation of defaultReadObject sets non-primitive field
values one at a time, without first checking that all their types are
assignable. If, for example, the assignment of the last non-primitive
value fails, a CCE is thrown, and the previously set fields remain set.
The
On 19/03/15 15:21, Peter Levart wrote:
On 03/19/2015 11:35 AM, Peter Firmstone wrote:
Chris / Peter,
Perhaps you could consider passing GetFields as a parameter to a
static method (identified by an annotation) and use fieldSetter to
change the fields before they're written?
Interesting idea.
On 17/03/15 11:52, Peter Levart wrote:
On 03/17/2015 10:57 AM, Chris Hegarty wrote:
Peter, Alan,
After further thought I think that requiring all final fields to be set is
reasonable behaviour. Since there is no compile time checking, this is a
reasonable runtime effort to catch what
On 17/03/15 13:42, Alan Bateman wrote:
On 17/03/2015 12:21, Peter Levart wrote:
Hi Alan,
I agree that not calling defaultReadObject() from readObject() and
having a final field is potentially a bug. But need not be in case
some other means of setting final fields was used (Unsafe or
setter API.
-Chris.
On 13 Mar 2015, at 19:36, Chris Hegarty chris.hega...@oracle.com wrote:
On 13 Mar 2015, at 17:58, Peter Levart peter.lev...@gmail.com wrote:
On 03/12/2015 11:24 PM, Peter Levart wrote:
So if a readObject calls fields() without calling defaultReadObject
On 16/03/15 14:04, Paul Sandoz wrote:
Hi,
This is a fix for a silly regression introduced with JDK-8067969 (optimized
count operations) that i should have caught in review.
I also missed it :-(
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8075230-count-prims-shape/webrev/
Looks fine
On 13 Mar 2015, at 17:58, Peter Levart peter.lev...@gmail.com 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
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 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.
On 12 Mar 2015, at 09:44, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis bibou...@gmail.com wrote:
Hi all,
Please review the patch for the count terminal operator on SIZED streams.
https://bugs.openjdk.java.net/browse/JDK-8067969
This is looking good, still looking at the detail… just a quick comment.
It may be possible to remove the UOE from Process.onExit, if you implement the
“never to be used” default without using ProcessHandle?
diff --git a/src/java.base/share/classes/java/lang/Process.java
On 12 Mar 2015, at 13:56, Peter Levart peter.lev...@gmail.com wrote:
On 03/11/2015 08:58 PM, Roger Riggs wrote:
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
That's strange. Process no
On 12 Mar 2015, at 11:25, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 12, 2015, at 12:05 PM, Chris Hegarty chris.hega...@oracle.com wrote:
On 12 Mar 2015, at 09:44, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis bibou...@gmail.com wrote
On 11/03/15 10:06, Paul Sandoz wrote:
On Mar 10, 2015, at 4:41 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi Paul,
On 3/10/2015 11:22 AM, Paul Sandoz wrote:
Any sub-type of Process that does not override getPid will essentially result
in that USO being propagated to many ProcessHandle
On 11/03/15 11:34, Peter Levart wrote:
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
can be removed, no?
long getPID() throws USO { throw new USO; }
I think ProcessHandle needs a protected constructor, otherwise it
cannot be implemented outside of the platform. Or is this the intent
.
That would probably be ok too, and then the UOE could be removed from
Process.getPid() too, right? Which solves that small API wart.
-Chris.
Roger
On 3/9/2015 6:10 AM, Chris Hegarty wrote:
On 06/03/15 19:34, Jason Mehrens wrote:
Hi Chris,
Since getPid can throw UOE that means that compareTo
On 06/03/15 19:34, Jason Mehrens wrote:
Hi Chris,
Since getPid can throw UOE that means that compareTo could now throw UOE.
Ooh... I don't like this.
Has any consideration been given to getPid returning -1, if unknown or
the default implementation? Or would this be any better?
-Chris
Roger,
I’ve taken a look at these changes in the sandbox ( JDK-8046092-branch ).
Overall I welcome this addition.
Some comments, most of which I stuffed into a webrev based on your branch,
http://cr.openjdk.java.net/~chegar/process_comments/webrev/
1) ProcessHandle.compareTo() can drop the
Hi,
Peter Levart and I have been working on an API to support setting of final
fields during custom deserialization. Dealing with final fields during
deserialization is a pain point only partially addressed in JSR 133 ( in Java 5
). What we are proposing is a simple API solution to resolve
On 4 Mar 2015, at 21:02, Stuart Marks stuart.ma...@oracle.com wrote:
On 3/4/15 11:14 AM, Chris Hegarty wrote:
On 4 Mar 2015, at 18:10, Stuart Marks stuart.ma...@oracle.com wrote:
Hi Chris,
Instead of creating a socket factory for this purpose, this test can use
RMI's test library
- support *listening* on
an ephemeral port
Fixed.
-Chris.
Roger
[1] http://en.wikipedia.org/wiki/Ephemeral_port
On 3/4/2015 10:01 AM, Chris Hegarty wrote:
This is a small, test only, review request to fix an intermittently
failing test.
There is an inherent race, and possible failure
here.
-Chris.
Roger
On 3/4/2015 9:59 AM, Chris Hegarty wrote:
This is a small, test only, review request to fix an intermittently
failing test.
It replaces a bad technique, heap exhaustion, with the less bad
technique of calling System.gc, potentially multiple times, to clear
weak references
more than once.
In my testing it only ever goes through once.
Maybe some indication of that can be added to the test output.
I added some output ( updated the webrev in-place). The test should be
quiet unless there is a problem.
-Chris.
Thanks, Roger
On 3/4/2015 10:57 AM, Chris Hegarty
/4/15 8:15 AM, Chris Hegarty wrote:
On 04/03/15 15:58, Roger Riggs wrote:
Hi Chris,
ok, though if System.gc is good enough it would not need a loop and
timeout logic.
Ah ok, so some common library function taking a Predicate, or similar. I got
you
now.
It would be interesting to know
TestLibrary.getRegistryPort().
s'marks
On 3/4/15 7:01 AM, Chris Hegarty wrote:
This is a small, test only, review request to fix an intermittently failing
test.
There is an inherent race, and possible failure, following the
getUnusedRandomPort pattern. This test can be modified to use
This is a small, test only, review request to fix an intermittently
failing test.
There is an inherent race, and possible failure, following the
getUnusedRandomPort pattern. This test can be modified to use a custom
socket factory, supporting listening on an ephemeral port, without
changing
This is a small, test only, review request to fix an intermittently
failing test.
It replaces a bad technique, heap exhaustion, with the less bad
technique of calling System.gc, potentially multiple times, to clear
weak references. With this change the test runs much quicker, and has
not
On 27/02/15 02:04, Stuart Marks wrote:
On 2/19/15 9:33 AM, Chris Hegarty wrote:
It came up recently that java.util.Arrays was missing subrange
overloads for setAll and parallelSetAll. These methods can be easily
written with IntStream.range. Rather than adding eight new methods
On 24 Feb 2015, at 15:07, Chris Hegarty chris.hega...@oracle.com wrote:
On 24 Feb 2015, at 11:45, Peter Levart peter.lev...@gmail.com wrote:
...
That's better now. Let me just try to measure the overhead of tracking on
simple objects to see if it actually pays off or is contra-productive
On 26 Feb 2015, at 11:38, Chris Hegarty chris.hega...@oracle.com wrote:
On 24 Feb 2015, at 15:07, Chris Hegarty chris.hega...@oracle.com wrote:
On 24 Feb 2015, at 11:45, Peter Levart peter.lev...@gmail.com wrote:
...
That's better now. Let me just try to measure the overhead of tracking
On 24 Feb 2015, at 00:58, Mandy Chung mandy.ch...@oracle.com wrote:
In fact, find another redundant in jdk.httpserver. I have updated the
synopsis of JDK-8073696 to remove redundant imports in java.corba and
jdk.httpserver
On 24 Feb 2015, at 11:45, Peter Levart peter.lev...@gmail.com wrote:
...
- You are tracking the requiresFreeze flag in readSerialData() method for
each class slot the deserialized object is composed of. This can be
optimized and the 'hasFinalField' flag pre-computed for the whole object
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
On 20/02/15 15:09, Peter Levart wrote:
...
This looks good now. But I wonder if issuing fences after nested calls
to readObject() makes
, David Holmes david.hol...@oracle.com
mailto:david.hol...@oracle.com wrote:
Hi Chris,
On 23/02/2015 9:01 PM, Chris Hegarty wrote:
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
http://cr.openjdk.java.net/~__chegar
On 23/02/15 12:30, David Holmes wrote:
Hi Chris,
On 23/02/2015 9:01 PM, Chris Hegarty wrote:
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
It seems reasonable
Thanks.
but I
), and then set the field with it after the looping is over.
Anyway, your call.
That is better. Done.
Thanks,
-Chris.
On Mon, Feb 23, 2015 at 10:32 AM, Chris Hegarty
chris.hega...@oracle.com mailto:chris.hega...@oracle.com wrote:
On 23/02/15 14:08, Vitaly Davidovich wrote:
Likewise, seems
On 23/02/15 15:59, Paul Sandoz wrote:
On Feb 23, 2015, at 4:40 PM, Chris Hegarty chris.hega...@oracle.com wrote:
On 23/02/15 15:30, Vitaly Davidovich wrote:
Ok Chris, sounds good.
It could be, but I omitted it as it requires a pesky explicit
assignment of false in the case where
, the changes in this webrev are overly defensive in the face of
recursive calls to readObject/Unshared. This should be ok, but probably
not strictly necessary.
-Chris.
David
sent from my phone
On Feb 19, 2015 11:32 AM, Chris Hegarty chris.hega...@oracle.com
wrote:
Additional note
my phone
On Feb 20, 2015 6:28 AM, Chris Hegarty chris.hega...@oracle.com
mailto:chris.hega...@oracle.com wrote:
On 20/02/15 00:27, David Holmes wrote:
On 20/02/2015 10:13 AM, Vitaly Davidovich wrote:
In addition to Peter's comment, full fence seems
A number of years ago there was a proposal to use Unsafe.put*Volatile methods
to set final fields during default deserialisation [1][2], but it never made it
due to concerns about the potential negative impact of the additional fences.
Now we have a, private, fences API in the platform, I think
It came up recently that java.util.Arrays was missing subrange overloads for
setAll and parallelSetAll. These methods can be easily written with
IntStream.range. Rather than adding eight new methods for this, it makes sense
to point developers to IntStream.range. It seems reasonable to add a
On 13 Feb 2015, at 16:11, Alan Bateman alan.bate...@oracle.com wrote:
On 10/02/2015 16:20, Chris Hegarty wrote:
On 10 Feb 2015, at 11:35, Alan Bateman alan.bate...@oracle.com wrote:
On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http
On 3 Feb 2015, at 13:48, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
Looks like a useful addition.
Trivially, the handling of null caught my eye: If a mapped stream is {@code
null} an empty stream is used,
On 10 Feb 2015, at 12:46, Paul Sandoz paul.san...@oracle.com wrote:
Hi David,
On Feb 10, 2015, at 1:02 PM, David Holmes david.hol...@oracle.com wrote:
Hi Paul,
When we added j.u.c there was reluctance to add these methods to Thread -
this was the normal policy (for the time) of don't
On 10 Feb 2015, at 11:35, Alan Bateman alan.bate...@oracle.com wrote:
On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http://cr.openjdk.java.net/~chegar/8064924/04/
The updated javadoc looks good. I haven't had a chance yet to look
Thank you for the comments Alan.
On 06/02/15 10:20, Alan Bateman wrote:
On 04/02/2015 15:11, Chris Hegarty wrote:
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
I think the approach and naming is good. A few small comments
On 04/02/15 16:01, Peter Levart wrote:
On 02/04/2015 04:45 PM, Alan Bateman wrote:
On 04/02/2015 15:10, Weijun Wang wrote:
It should be checked, otherwise a non-initialized parent object comes
into being.
In general then permission checks in constructors are a bad idea but
we have an
On 02/02/15 20:52, Alan Bateman wrote:
I'm happy with this approach. One outstanding point from the discussion
is whether the URLStreamHandlerFactory implementation will need to be
granted RuntimePermission(setFactory), if so then this will need to go
into the javadoc.
I think that we
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
-Chris.
On 04/02/15 14:44, Alan Bateman wrote:
On 04/02/2015 14:29, Peter Levart wrote:
:
I agree that this is the most appropriate way with which you can force
some provider's class code
Hi Peter,
On 2 Feb 2015, at 11:16, Peter Firmstone peter.firmst...@zeus.net.au wrote:
As mentioned I've been experimenting with an invariant validating
ObjectInputStream, that's backward and forward compatible with Java's Object
Serialization stream protocol.
No changes have been made to
On 2 Feb 2015, at 11:36, Paul Sandoz paul.san...@oracle.com wrote:
...
This was a nasty race. In fact there is no guarantee that the CF, that sets
the AtomicReference would even complete, without join/get, right ?
I think the async completion of the thenComposed task will trigger (in the
the implementation changes, so we can agree
the spec changes first. They are much simpler now.
-Chris.
On 02/02/15 09:15, Chris Hegarty wrote:
Just catching up…
On 2 Feb 2015, at 08:42, Alan Bateman alan.bate...@oracle.com wrote:
On 01/02/2015 10:45, Peter Levart wrote:
:
I see
On 02/02/15 11:00, Paul Sandoz wrote:
On Jan 30, 2015, at 10:10 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 30/01/2015 15:35, Chris Hegarty wrote:
:
Update webrev and spec diffs:
http://cr.openjdk.java.net/~chegar/8064924/01/
I think the javadoc looks much better now, thanks
On 02/02/15 09:29, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072030-thenComposeException-test-race-condition/webrev/
I introduced a silly race condition in the test ThenComposeExceptionTest.java.
This manifested itself in hotspot testing where various VM options
Just catching up…
On 2 Feb 2015, at 08:42, Alan Bateman alan.bate...@oracle.com wrote:
On 01/02/2015 10:45, Peter Levart wrote:
:
I see. But if URLStreamHandlerFactories are only supposed to be located via
the system class loader, is that different from what we have now when
901 - 1000 of 2067 matches
Mail list logo
