On 30/07/2015 8:41 PM, Peter Levart wrote:
On 07/30/2015 12:24 PM, David Holmes wrote:
On 30/07/2015 8:20 PM, Peter Levart wrote:
On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
Hi Peter,
I'm glad you're looking at this too! We can't have too many eyes :-)
On 30/07/15 10:38, Peter Levart
On 30/07/2015 9:57 PM, Peter Levart wrote:
On 07/30/2015 01:44 PM, David Holmes wrote:
r.isEnqueued() q.poll() == null r.isEnqueued() == true
What is surprising in the above expression evaluating to true is the
fact that 'r' appears to be enqueued before and after the q.poll()
returns
On 30/07/15 13:37, Peter Levart wrote:
poll() returning null by itself is not surprising, but if 'r' appears to
be enqueued before and after the fact, this is surprising.
Agreed - not disputing this.
The question for me is whether this should be fixed in the same
changeset - or whether we
On 07/30/2015 12:48 PM, Daniel Fuchs wrote:
On 30/07/15 12:20, Peter Levart wrote:
On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
Hi Peter,
I'm glad you're looking at this too! We can't have too many eyes :-)
On 30/07/15 10:38, Peter Levart wrote:
Suppose we have a Reference 'r' and it's
Hi,
Please find below an updated webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
Instead of removing the CLITest.java - I copied
Process.java into the test hierarchy, renamed it to
ProcessXSLT.java, modified it so that it no longer uses
internal APIs, and changed the
On 07/30/2015 01:44 PM, David Holmes wrote:
r.isEnqueued() q.poll() == null r.isEnqueued() == true
What is surprising in the above expression evaluating to true is the
fact that 'r' appears to be enqueued before and after the q.poll()
returns null. I can easily imagine code that would fail
Hi,
Please review this simple fix to the JavaDoc on j.u.stream.Collector.finisher.
I am also opportunistically fixing some internal comments identified by Tagir.
Paul.
diff -r 4e3135fac8cc src/java.base/share/classes/java/util/stream/Collector.java
---
Looks good Roger. Only minor quibble would be the name of the new type
JavaInetAddressAccess could be JavaNetInetAddressAccess to be consistent.
Michael
On 30/07/15 15:49, Roger Riggs wrote:
Please review this refactoring of SharedSecret initialization to
create and
InetAddressAccess access
Hi,
I renamed the new interface and its uses as recommended.
The webrev updated in place:
http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/
I deferred renaming JavaNetAccess because it (getURLClassPath) is used
in install and deploy
and I was not certain it would still be
Please review this refactoring of SharedSecret initialization to create and
InetAddressAccess access that is independent of the initialization
of JavaNetAccess in URLClassLoader.
(jprt in progress)
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/
Issue:
On 30/07/2015 15:49, Roger Riggs wrote:
Please review this refactoring of SharedSecret initialization to
create and
InetAddressAccess access that is independent of the initialization
of JavaNetAccess in URLClassLoader.
(jprt in progress)
Webrev:
Hi,
can somebody please review this test fix:
http://cr.openjdk.java.net/~simonis/webrevs/2015/8132704/
https://bugs.openjdk.java.net/browse/JDK-8132704
The initial test checked that all the files in the bin/ directory are
executable by everybody. Unfortunately this was too optimistic because
On Thu, Jul 30, 2015 at 5:34 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi Volker,
Possibly the real bug is that there is non-executable file in the bin
directory.
There is a /conf directory which would probably be a better place for that.
Yes, I agree. But I thought you want a fast fix
Thanks for doing this Roger. The changes look good to me.
-Chris.
On 30 Jul 2015, at 15:49, Roger Riggs roger.ri...@oracle.com wrote:
Please review this refactoring of SharedSecret initialization to create and
InetAddressAccess access that is independent of the initialization
of
Hi Volker,
Possibly the real bug is that there is non-executable file in the bin
directory.
There is a /conf directory which would probably be a better place for that.
Roger
On 7/30/2015 11:28 AM, Volker Simonis wrote:
Hi,
can somebody please review this test fix:
On 31/07/2015 5:54 AM, Kim Barrett wrote:
On Jul 30, 2015, at 8:09 AM, David Holmes david.hol...@oracle.com wrote:
On 30/07/2015 9:57 PM, Peter Levart wrote:
'r' has been enqueued.
Thread-1:
r.isEnqueued()
q.poll() == null
r.isEnqueued()
Thread-2:
q.poll();
Sequence of actions:
T1:
On Jul 30, 2015, at 8:09 AM, David Holmes david.hol...@oracle.com wrote:
On 30/07/2015 9:57 PM, Peter Levart wrote:
'r' has been enqueued.
Thread-1:
r.isEnqueued()
q.poll() == null
r.isEnqueued()
Thread-2:
q.poll();
Sequence of actions:
T1: r.isEnqueued() == true
T2:
I vote for 1.
:-)
cheers,
-- daniel
On 7/30/15 9:54 PM, Kim Barrett wrote:
On Jul 30, 2015, at 8:09 AM, David Holmes david.hol...@oracle.com wrote:
On 30/07/2015 9:57 PM, Peter Levart wrote:
'r' has been enqueued.
Thread-1:
r.isEnqueued()
q.poll() == null
r.isEnqueued()
Thread-2:
On 07/30/2015 03:01 PM, David Holmes wrote:
On 31/07/2015 1:41 AM, Xueming Shen wrote:
On 07/30/2015 01:37 AM, Volker Simonis wrote:
On Thu, Jul 30, 2015 at 9:51 AM, Alan
Batemanalan.bate...@oracle.com wrote:
On 30/07/2015 06:21, Xueming Shen wrote:
:
Each platform has a list of supported
Looks fine Stuart,
-Joe
On 7/30/2015 3:39 PM, Stuart Marks wrote:
Hi all,
Please review this quick cleanup to this test I moved into the open
yesterday. It changes the JVM's locale, and out of an abundance of
caution it's safer to run things that change JVM global state in
/othervm mode.
+1
On 07/30/2015 03:40 PM, Joseph D. Darcy wrote:
Looks fine Stuart,
-Joe
On 7/30/2015 3:39 PM, Stuart Marks wrote:
Hi all,
Please review this quick cleanup to this test I moved into the open yesterday.
It changes the JVM's locale, and out of an abundance of caution it's safer to
run
Hello,
I doubt you can compile a list of all charsets supported by the various
(national) linux distributions and versions (and installed runtime
packages). Especially not for OpenJDK which can be much less restrictive in
picking supported (non enterprise) distributions.
And I also wonder why it
On Jul 30, 2015, at 5:33 PM, David Holmes david.hol...@oracle.com wrote:
So I think I can either:
1. Go ahead with my change + Peter's change.
2. Give this back to core-libs while I step carefully away :-)
I *think* option (1) is at least an improvement. But I completely
missed
On 7/29/15 11:36 AM, Volker Simonis wrote:
!! ProcessHandleImpl_unix: 709-738: I still disagree with returning
truncated or incomplete
values for the executable or arguments.
Can anyone be a tie-breaker (with a good rational and suggestion for how an
application can use the data).
As I
On 31/07/2015 1:41 AM, Xueming Shen wrote:
On 07/30/2015 01:37 AM, Volker Simonis wrote:
On Thu, Jul 30, 2015 at 9:51 AM, Alan
Batemanalan.bate...@oracle.com wrote:
On 30/07/2015 06:21, Xueming Shen wrote:
:
Each platform has a list of supported locale/encoding. All these
Hi Paul,
Changes look good. (The webrev changesets are a bit odd, though; are you running
webrev on a branchy repo or something?)
Stefan, Tagir, thanks for spotting these issues.
s'marks
On 7/30/15 9:32 AM, Paul Sandoz wrote:
Hi Stefan, Tagir,
Updated:
Hi Sherman,
The change looks fine to me.
s'marks
On 7/30/15 10:34 AM, Xueming Shen wrote:
Hi,
Please help review the change for
issue: https://bugs.openjdk.java.net/browse/JDK-8080252
webrev: http://cr.openjdk.java.net/~sherman/8080252/
It appears we updated the j.u.Formatter
Looks good!
Thanks,
David
On 31/07/2015 8:56 AM, Kim Barrett wrote:
On Jul 30, 2015, at 5:33 PM, David Holmes david.hol...@oracle.com wrote:
So I think I can either:
1. Go ahead with my change + Peter's change.
2. Give this back to core-libs while I step carefully away :-)
I *think*
On 7/28/15 5:50 AM, Paul Sandoz wrote:
I agree that if we make a policy decision here, we can change it and the
compatibility impact is minimal.
Since there already exists an implicit policy governed by like 99.9% of the
existing behaviour i do not see the need to be explicit about that
On 7/30/15 4:55 PM, Bernd wrote:
Hello,
I doubt you can compile a list of all charsets supported by the
various (national) linux distributions and versions (and installed
runtime packages). Especially not for OpenJDK which can be much less
restrictive in picking supported (non enterprise)
On 30/07/2015 04:54, Xueming Shen wrote:
Here is the webrev to add those missing charsets. The assumption
back then was that the linux platform has
successfully migrated to the utf-8 default world.
http://cr.openjdk.java.net/~sherman/8132459/
This looks okay to me.
-Alan
Hi,
Let me chime in and add some comments...
On 07/30/2015 01:46 AM, Kim Barrett wrote:
On Jul 29, 2015, at 4:32 AM, David Holmes david.hol...@oracle.com wrote:
On 29/07/2015 5:57 PM, Kim Barrett wrote:
... The race is being fixed by reordering a pair
of volatile assignments.
While this
On 30 Jul 2015, at 08:08, Tagir F. Valeev amae...@gmail.com wrote:
Hello!
PS I don’t particular want to add a special spliterator for this
PS case to avoid some profile pollution. Will it not just push the
PS pollution further down the road to Spliterator.forEachRemaining? or to
within
On 30/07/2015 06:21, Xueming Shen wrote:
:
Each platform has a list of supported locale/encoding. All these
encodings/charsets need to be in
base module for that particular platform, to support the jvm to start
(in a particular locale/encoding)
under module system. The charsets in our
On Thu, Jul 30, 2015 at 9:51 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 30/07/2015 06:21, Xueming Shen wrote:
:
Each platform has a list of supported locale/encoding. All these
encodings/charsets need to be in
base module for that particular platform, to support the jvm to start
On 07/30/2015 10:38 AM, Peter Levart wrote:
[This suggests the r.queue = NULL assignment in reallyPoll() should be
moved later, though I think the assignment order in reallyPoll()
doesn't matter.]
I think the assignment to r.queue = NULL in realyPoll() should be
moved *before* the
Hi Volker,
There is already as task for JMC to move that file but who knows exactly
when.
A list of exception(s) would be better I think, because generally,
everything in bin should be executable.
WDYT?
Roger
On 7/30/2015 11:40 AM, Volker Simonis wrote:
On Thu, Jul 30, 2015 at 5:34 PM,
Hi Daniel,
On 7/30/2015 6:38 AM, Daniel Fuchs wrote:
Hi,
Please find below an updated webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
Looks good to me. The only nit is it seems createDefaultErrorHandler
method is a dup of createDefaultErrorListener?
Instead of
Hello!
Seems that you have an extra parenthesis here:
diff -r 4e3135fac8cc src/java.base/share/classes/java/util/stream/SliceOps.java
--- a/src/java.base/share/classes/java/util/stream/SliceOps.javaFri Jul
24 15:33:13 2015 -0700
+++
On 30/07/15 18:16, huizhe wang wrote:
On 7/30/2015 9:08 AM, Daniel Fuchs wrote:
On 30/07/15 17:55, huizhe wang wrote:
Hi Daniel,
On 7/30/2015 6:38 AM, Daniel Fuchs wrote:
Hi,
Please find below an updated webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
Looks good to
Hello!
PS I don’t particular want to add a special spliterator for this
PS case to avoid some profile pollution. Will it not just push the
PS pollution further down the road to Spliterator.forEachRemaining? or to
within other code?
I just thought that the current idea is to create specialized
On Thu, Jul 30, 2015 at 5:47 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi Volker,
There is already as task for JMC to move that file but who knows exactly
when.
A list of exception(s) would be better I think, because generally,
everything in bin should be executable.
WDYT?
OK, I'm
Hi Stefan, Tagir,
Updated:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/
Paul.
On 30 Jul 2015, at 18:08, Stefan Zobel splitera...@gmail.com wrote:
Hi Paul,
perhaps you could take the opportunity and also add the missing @since
1.9 tags to all the new
On 30/07/2015 16:21, Roger Riggs wrote:
Hi,
I renamed the new interface and its uses as recommended.
The webrev updated in place:
http://cr.openjdk.java.net/~rriggs/webrev-inetaccess-8132705/
I deferred renaming JavaNetAccess because it (getURLClassPath) is used
in install and deploy
and I
Hi Paul,
perhaps you could take the opportunity and also add the missing @since
1.9 tags to all the new dropWhile() / takeWhile() methods (JDK-8071597).
Also in dropWhile() / takeWhile() there is a small typo (I guess) in the
Javadoc:
takeWhile: takes all elements (the result is the same is
On 30/07/15 17:55, huizhe wang wrote:
Hi Daniel,
On 7/30/2015 6:38 AM, Daniel Fuchs wrote:
Hi,
Please find below an updated webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
Looks good to me. The only nit is it seems createDefaultErrorHandler
method is a dup of
On 7/30/2015 9:08 AM, Daniel Fuchs wrote:
On 30/07/15 17:55, huizhe wang wrote:
Hi Daniel,
On 7/30/2015 6:38 AM, Daniel Fuchs wrote:
Hi,
Please find below an updated webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
Looks good to me. The only nit is it seems
Hi all,
Please review this quick cleanup to this test I moved into the open yesterday.
It changes the JVM's locale, and out of an abundance of caution it's safer to
run things that change JVM global state in /othervm mode.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8132745
Patch
Hi,
Please help review the change for
issue: https://bugs.openjdk.java.net/browse/JDK-8080252
webrev: http://cr.openjdk.java.net/~sherman/8080252/
It appears we updated the j.u.Formatter implementation to use the newly
introduced
method System.lineSeparator() in jdk7, but did not update the
Hi Paul,
looks good.
Stefan
2015-07-30 18:32 GMT+02:00 Paul Sandoz paul.san...@oracle.com:
Hi Stefan, Tagir,
Updated:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/
Paul.
On 07/30/2015 12:24 PM, David Holmes wrote:
On 30/07/2015 8:20 PM, Peter Levart wrote:
On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
Hi Peter,
I'm glad you're looking at this too! We can't have too many eyes :-)
On 30/07/15 10:38, Peter Levart wrote:
Suppose we have a Reference 'r' and
On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
Hi Peter,
I'm glad you're looking at this too! We can't have too many eyes :-)
On 30/07/15 10:38, Peter Levart wrote:
Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'.
Currently it can happen that the following evaluates to
On 30/07/2015 8:20 PM, Peter Levart wrote:
On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
Hi Peter,
I'm glad you're looking at this too! We can't have too many eyes :-)
On 30/07/15 10:38, Peter Levart wrote:
Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'.
Currently it
Hi Peter,
I'm glad you're looking at this too! We can't have too many eyes :-)
On 30/07/15 10:38, Peter Levart wrote:
Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'.
Currently it can happen that the following evaluates to true, which is
surprising:
q.poll() == null
54 matches
Mail list logo
