On 07/29/2013 09:06 PM, Brian Burkhalter wrote:
Joe / Chris:
The updated webrev is in the same place,
http://cr.openjdk.java.net/~bpb/8020539/
If this looks good I will need an approval.
It looks ok to me.
-Chris.
On Jul 29, 2013, at 12:05 AM, Joe Darcy wrote:
I recommend a few changes
Joe / Chris:
The updated webrev is in the same place,
http://cr.openjdk.java.net/~bpb/8020539/
If this looks good I will need an approval.
On Jul 29, 2013, at 12:05 AM, Joe Darcy wrote:
> I recommend a few changes here:
>
> * For readability, rename "NonASCIIDigit" as "NonAsciiDigit"
Changed
.
http://cr.openjdk.java.net/~bpb/8020539/
Brian,
Looks fine ( I did not go through the Scanner changes ).
Some minor comments:
1) List
Trivially I wonder why you decided to go with '< '>', rather
than {@code ... }, which I think is more readable.
2) Map
Trivially, I would ke
On 07/18/2013 02:19 PM, Brian Burkhalter wrote:
On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
In Random.java, I would prefer if the size manipulation of the exponent
was removed instead of
373 * All 224 possible
{@code float} values
just
373 * All 224 possible {@code float} val
On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
> In Random.java, I would prefer if the size manipulation of the
> exponent was removed instead of
>
> 373 * All 224 possible
> {@code float} values
>
> just
>
> 373 * All 224 possible {@code float} values.
Done.
> Also, I think the
On Jul 18, 2013, at 12:04 PM, Brian Burkhalter wrote:
> I don't at first glance see a mapping of the regular expression "+" (one or
> more) to something in the JLS grammar. There are
>
> ? => [x] zero or one x
> * => {x} zero or more x
>
On Jul 18, 2013, at 11:50 AM, Joe Darcy wrote:
>> This I interpret to mean the second example in the first block in this
>> section http://docs.oracle.com/javase/specs/jls/se7/html/jls-2.html#jls-2.4.
>
> Right (although the on-line rendering in the browser I'm using while typing
> this doesn't
On 18 Jul 2013, at 19:35, Martin Buchholz wrote:
> As of today, jsr166 CVS src/main is doclint-clean, and will stay that way
> because of the added
>
> in build.xml
>
Thanks Martin, we'll sync these changes soon.
-Chris
>
> On Thu, Jul 18, 2013 at 2:56 AM, Chris Hegarty
> wrote:
>
On 07/18/2013 11:35 AM, Martin Buchholz wrote:
As of today, jsr166 CVS src/main is doclint-clean, and will stay that way
because of the added
in build.xml
Excellent news! Looking forward to the next sync :-)
(Note there are some bugs in doclint that are in the process of being
fixed
On 07/18/2013 11:16 AM, Brian Burkhalter wrote:
On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
In Random.java, I would prefer if the size manipulation of the
exponent was removed instead of
373 * All 224
possible {@code float} values
just
373 * All 224 possible {@code float} va
On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
> In Random.java, I would prefer if the size manipulation of the
> exponent was removed instead of
>
> 373 * All 224 possible
> {@code float} values
>
> just
>
> 373 * All 224 possible {@code float} values.
I previously made that chan
On 07/17/13 21:03, Martin Buchholz wrote:
I'm surprised no one has explained.
The jsr166 project is upstream of openjdk and is primarily maintained by
Doug Lea.
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
Essentially every file that can be found in Doug's CVS under src/main/util
i
Sync's from jsr166 - > jdk8 are in progress. Paul and I have pushed, or
still in flight, a number of changeset over the past number of weeks. I
would hope to have the remainder of changes in jdk8 soon.
doclint issues should be fixed in jsr166 CVS first. Either work with
Doug or Martin to provi
Hello,
In Random.java, I would prefer if the size manipulation of the
exponent was removed instead of
373 * All 224
possible {@code float} values
just
373 * All 224 possible {@code float} values.
Also, I think the changes in Scanner would be better of the JLS-style
grammar syn
I'm not familiar with the JSR 166 CVS so perhaps someone with more history
could enlighten me. Otherwise, I would think that any such sync would be the
subject of a separate issue.
On Jul 17, 2013, at 2:42 PM, Martin Buchholz wrote:
> I believe most doclint warnings have already been fixed for
This is the command which I have been using:
../build/macosx-x86_64-normal-server-fastdebug/jdk/bin/javac
-Xdoclint:all/protected -d /tmp -XDignore.symbol.file
src/share/classes/java/util/
On Jul 17, 2013, at 2:05 PM, Martin Buchholz wrote:
> To follow up, what standard of cleanliness is expec
Will do so once what has been posted is approved.
On Jul 17, 2013, at 2:00 PM, Martin Buchholz wrote:
> Queue.java and Deque.java are primarily maintained in Doug's CVS and should
> be updated there. Please remove them from this change.
>
> Doug and I will work on cleaning up doclint warnings
Hi Joe,
The changes requested below have been made and the webrev updated accordingly:
http://cr.openjdk.java.net/~bpb/8020539/
The HTML for Scanner may be viewed here
http://cr.openjdk.java.net/~bpb/Scanner.html
Thanks,
Brian
On Jul 16, 2013, at 1:59 PM, Joe Darcy wrote:
> For the changes
Hi Brian,
For the changes in j.u.Random,
- * pseudorandomly generated and returned. All 232
+ * pseudorandomly generated and returned. All 2style="font-size:smaller;">32
I would just dispense with the size adjustment of the exponent -- the
tag alone should be sufficient. Plain is us
Reviewers:
Issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020539
Webrev: http://cr.openjdk.java.net/~bpb/8020539/
I think the only dubious change in here is in the Scanner class comments. This
was previously using empty tag pairs for spacing purposes. I replaced
each these with
20 matches
Mail list logo
