On 28/08/2013 22:10, Henry Jen wrote:
Hi,
Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/webrev/
Based on the feedback/discussion from last time, the EG decided to
weaken AutoCloseable contract(see RFR 8022176[1]), and have Stream
extend AutoCloseable.
A quick b
On 28/08/2013 23:18, Dan Xu wrote:
Thank you, Alan.
I have updated my webrev to
http://cr.openjdk.java.net/~dxu/4792059/webrev.01/.
-Dan
Looks fine.
-Alan
On 29/08/2013 6:26 AM, Joel Borggrén-Franck wrote:
Hi David,
On Aug 27, 2013, at 5:21 AM, David Holmes wrote:
Hi Joel,
On 26/08/2013 10:39 PM, Joel Borggren-Franck wrote:
Hi,
Please review doc fix and test for
http://bugs.sun.com/view_bug.do?bug_id=5047859
http://cr.openjdk.java.net/~jfr
I will update the javadoc in the webrev and repost tomorrow.
Brian
On Aug 28, 2013, at 7:03 PM, Guy Steele wrote:
> In any case, I think everyone is now agreed on "the right thing" for going
> forward.
What Mike said. It's basically the same problem as for serialization,
so you keep a hashtable of all objects traversed---but you need not record
objects that have no subobjects and have "simple" or "short" printed
representations
(such as numbers and maybe short strings).
In full generality it r
Thanks for this context, Joe. And, truth be told, the fact there was a
discrepancy
between the textual and code descriptions of the operation may well have been
my error. (I don't have a clear memory either way, but it's the sort of text
I would have worked on rather than Bill.)
In any case, I
On 8/28/2013 6:39 AM, Joel Borggrén-Franck wrote:
Hi Mandy,
Thanks for your comments,
On 2013-08-26, Mandy Chung wrote:
Joel,
The spec of the getFields and getDeclaredFields() methods both states this:
This method returns an array of length 0 if the class
or interface declares no fiel
Hello,
On 8/23/2013 1:36 PM, Guy Steele wrote:
The specification of java.lang.Math.round in the first edition of the
Java Language Specification is quite clear:
public static int round(float a)
The result is rounded to an integer by adding 1/2, taking the floor of
the result, and casting
On 08/27/2013 07:15 AM, Dan Xu wrote:
On 08/27/2013 12:12 AM, Alan Bateman wrote:
On 27/08/2013 01:18, Dan Xu wrote:
Hi All,
MaxPathLength.javais a troublesome testcase, and fails
intermittently in the nightly test. And it also runs for a long
time, especially on Windows platforms. Inorder
On Aug 28 2013, at 15:54 , Alan Eliasen wrote:
> On 08/28/2013 04:47 PM, Guy Steele wrote:
>> *ahem* Y'know, Common Lisp had a good solution for
>> printing self-referential structures (by a user-extensible print
>> function) back in 1984.
>>
>> It leaned on the solution that had been provided
On 08/28/2013 04:47 PM, Guy Steele wrote:
> *ahem* Y'know, Common Lisp had a good solution for
> printing self-referential structures (by a user-extensible print
> function) back in 1984.
>
> It leaned on the solution that had been provided in Interlisp in
> 1974. On a machine with one megabyte
On Aug 28, 2013, at 6:13 PM, Mike Duigou wrote:
>
> On Aug 28 2013, at 11:48 , Martin Buchholz wrote:
>
>> This isn't just about hashCode - I'm not sure why you are singling it out.
>> What about toString?
>
> A reasonable point. The bug reports are just about as common for toString()
> be
Changeset: 189942cdf585
Author:jjg
Date: 2013-08-28 15:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/189942cdf585
8010310: [javadoc] Error processing sources with -private
Reviewed-by: vromero, mcimadamore
! src/share/classes/com/sun/tools/javac/code/Symbol.java
!
Thank you, Alan.
I have updated my webrev to
http://cr.openjdk.java.net/~dxu/4792059/webrev.01/.
-Dan
On 08/28/2013 04:05 AM, Alan Bateman wrote:
On 28/08/2013 00:20, Dan Xu wrote:
Hi,
When GeneralSolaris testcase follows symbolic link to pick up an
existing file or directory for testing
On Aug 28 2013, at 11:48 , Martin Buchholz wrote:
> This isn't just about hashCode - I'm not sure why you are singling it out.
> What about toString?
A reasonable point. The bug reports are just about as common for toString()
being "broken" for self-referential collections.
> Or really, any
Alan,
My mailbox suggests that you have already reviewed this one back to the
past May, somehow I dropped the ball some where. Here is the webrev and
CCC again (the change is a trivial spec clarification, which I should have
done 8 years ago).
http://cr.openjdk.java.net/~sherman/6341345
http://c
On 08/24/2013 01:40 PM, Alan Bateman wrote:
> On 24/08/2013 14:09, Doug Lea wrote:
>>
>> "resource specification", while accurate, looked confusing here.
>> But we could include both terms, which seems like an improvement.
>> See below.
> This looks better to me, thanks.
>
Updated webrev as concl
Hi,
Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8017513/1/webrev/
Based on the feedback/discussion from last time, the EG decided to
weaken AutoCloseable contract(see RFR 8022176[1]), and have Stream
extend AutoCloseable.
A quick briefing of the webrev,
- Remove Closeabl
On 28/08/2013 14:25, Masayoshi Okutsu wrote:
(adding core-libs-dev)
Hi Christian,
RFC 4647 defines The Language Priority List [1]. The use of
java.util.List would be a natural fit, which is the reason why List is
used. But use of Iterable does work (as API design). The parameter
name `priori
Hi David,
On Aug 27, 2013, at 5:21 AM, David Holmes wrote:
> Hi Joel,
>
> On 26/08/2013 10:39 PM, Joel Borggren-Franck wrote:
>> Hi,
>>
>> Please review doc fix and test for
>> http://bugs.sun.com/view_bug.do?bug_id=5047859
>>
>> http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
>>
>>
Changeset: b1f41565b806
Author:psandoz
Date: 2013-08-28 22:11 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1f41565b806
8023155: Ensure functional consistency across Random, ThreadLocalRandom,
SplittableRandom
Reviewed-by: mduigou
Contributed-by: Doug Lea , Paul Sandoz
Changeset: 7de7100c30ce
Author:henryjen
Date: 2013-08-28 10:17 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7de7100c30ce
8014566: Remove @ignore tags from MethodReference66 and InInterface when
8013875 is fixed
Reviewed-by: briangoetz, jjg
! test/tools/javac/lambda/
TLS 1 specification contained verbal statement
"The result is rounded to an integer by adding , taking the floor of the
result, and casting the result to type int".
and Java code
Math.floor(f + 0.5).
It seems to me that the verbal statement says about mathematical "+" .
It maps a pair of reals to
On Aug 28, 2013, at 10:55 AM, Dmitry Nadezhin wrote:
> TLS 1 specification contained verbal statement
> "The result is rounded to an integer by adding , taking the floor of the
> result, and casting the result to typeint".
> and Java code
> Math.floor(f + 0.5).
>
> It seems to me that the verbal
On 08/28/2013 10:45 AM, Martin Buchholz wrote:
get16 can not return negative values, right?
correct. will remove it in a separate push. thanks!
So elide the
sz < 0 below
666 if (sz < 0 || (off + 4 + sz) > len) {
667 break;
668 }
Otherwise, looks good
Changeset: 690b2931baef
Author:sherman
Date: 2013-08-28 09:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/690b2931baef
8023713: ZipFileSystem crashes on old zip file
Summary: to handle extra data field copy correctly even the extra data does not
follow the spec
Reviewed-b
On 08/28/2013 03:56 AM, Alan Bateman wrote:
On 28/08/2013 00:09, Xueming Shen wrote:
On 08/27/2013 03:07 PM, Martin Buchholz wrote:
It does seem vaguely reasonable to support any extra data.
Don't you want to also handle arbitrary byte arrays, if e.g. one the 16-bit
size fields overflows the
Thanks Stephen,
I am fine with your wording. Any other votes or suggested wordings?
Mike
On Aug 28 2013, at 02:55 , Stephen Colebourne wrote:
> I lke the idea, but the wording feels a little opaque as the result is
> typically StackOverflow.
>
> Also, I prefer a style with the @apiNote on a li
On Aug 27, 2013, at 7:44 PM, Dmitry Nadezhin wrote:
> Is it reasonable to make specification clearer ?
>
> Either to return JLS 1 specification:
> <<<
> The result is rounded to an integer by adding , taking the floor of the
> result, and casting the result to type long.
> >>>
This verbiage wou
Changeset: 378acd4d03c8
Author:alanb
Date: 2013-08-28 15:50 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/378acd4d03c8
8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil
Reviewed-by: chegar
! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
! src/macosx/classes/
Changeset: 2efa310226f7
Author:alanb
Date: 2013-08-28 14:07 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2efa310226f7
8023717: (process) ProcessBuilder should catch SecurityException rather than
AccessControlException
Reviewed-by: wetmore, alanb
Contributed-by: marti...@go
Hi Mandy,
Thanks for your comments,
On 2013-08-26, Mandy Chung wrote:
> Joel,
>
> The spec of the getFields and getDeclaredFields() methods both states this:
>
> This method returns an array of length 0 if the class
> or interface declares no fields, or if this|Class| object
> represents
(adding core-libs-dev)
Hi Christian,
RFC 4647 defines The Language Priority List [1]. The use of
java.util.List would be a natural fit, which is the reason why List is
used. But use of Iterable does work (as API design). The parameter name
`priorityIterable' sounds a bit odd, though.
Does u
- Original Message -
> On 08/27/2013 03:00 AM, Masayoshi Okutsu wrote:
> > /etc/sysconfig/clock used to be supported, but it was removed in JDK 7.
> > The problem is discussed in bug #6456628.
> >
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628
>
> Thanks for that link. I d
On 08/28/2013 12:10 PM, Paul Sandoz wrote:
Hi,
Intermittent failures were reported with the CHM toArray test in the JDK.
I updated the tests to increase the number of runs and the number of workers
and i can reliably reproduce on my laptop, see below.
The test presumes the size should always
On 08/28/2013 06:10 AM, Paul Sandoz wrote:
Hi,
Intermittent failures were reported with the CHM toArray test in the JDK.
I updated the tests to increase the number of runs and the number of workers
and i can reliably reproduce on my laptop, see below.
The test presumes the size should always
On 28/08/2013 00:17, Mike Duigou wrote:
Hello all;
I have updated the changeset for this issue based upon feedback from the
earlier version. As a result of intervening work this version contains even
more cleanup.
http://cr.openjdk.java.net/~mduigou/JDK-8015068/1/webrev/
Since the last revis
On 28/08/2013 00:20, Dan Xu wrote:
Hi,
When GeneralSolaris testcase follows symbolic link to pick up an
existing file or directory for testing, it will fail the assertion in
check()method because the file path canonicalization process will
result in the real path not a path containing symboli
On 28/08/2013 00:09, Xueming Shen wrote:
On 08/27/2013 03:07 PM, Martin Buchholz wrote:
It does seem vaguely reasonable to support any extra data.
Don't you want to also handle arbitrary byte arrays, if e.g. one the
16-bit size fields overflows the extra data?
It looks to me like getExtraLen
On Aug 27, 2013, at 11:47 PM, Mike Duigou wrote:
> ThreadLocalRandom::
>
> - I don't understand the point of having a writeObject() if the readResolve()
> ignores the result. My expectation for a serialized TLR might be that upon
> de-serialization the seeding state is restored. If that isn't p
Hi,
Intermittent failures were reported with the CHM toArray test in the JDK.
I updated the tests to increase the number of runs and the number of workers
and i can reliably reproduce on my laptop, see below.
The test presumes the size should always increase but fails when it observes a
new ne
Sorry about that. I thought the two fixes were travelling together else
I would have taken steps to put them together. :(
David
On 28/08/2013 8:04 PM, Dawid Weiss wrote:
Thanks Andreas, I'll switch to that revision.
On Wed, Aug 28, 2013 at 12:00 PM, Andreas Rieber
wrote:
Hi Dawid,
the fix
Thanks Andreas, I'll switch to that revision.
On Wed, Aug 28, 2013 at 12:00 PM, Andreas Rieber
wrote:
> Hi Dawid,
>
> the fix is in jdk8tl already, just missed to come into jdk8. It's only a few
> lines.
>
> Andreas
>
> Here the changeset:
>
> Changeset: 3b8fed46b2a8
> Author:dholmes
> Date:
Hi Dawid,
the fix is in jdk8tl already, just missed to come into jdk8. It's only a
few lines.
Andreas
Here the changeset:
Changeset: 3b8fed46b2a8
Author:dholmes
Date: 2013-08-21 05:56 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8fed46b2a8
8023460: OPENJDK build fa
I lke the idea, but the wording feels a little opaque as the result is
typically StackOverflow.
Also, I prefer a style with the @apiNote on a line of its own, rather
like a heading. It makes the documentation easier to read in source
code, and has no effect on the output Javadoc.
@apiNote
If the
David,
Is the fix for this committed anywhere? I've just tried building from
scratch and I'm getting the same error.
Dawid
On Wed, Aug 21, 2013 at 10:55 AM, David Holmes wrote:
> Fix on the way. This exposed another piece that was missing from the
> original change. But mea culpa for not doing
On 28/08/2013 00:09, Xueming Shen wrote:
On 08/27/2013 03:07 PM, Martin Buchholz wrote:
It does seem vaguely reasonable to support any extra data.
Don't you want to also handle arbitrary byte arrays, if e.g. one the
16-bit size fields overflows the extra data?
It looks to me like getExtraLen co
47 matches
Mail list logo
