Hi,
Can I get a review for this almost trivial 8u20 back port. The 9 fix reviewed
here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027173.html
applies cleanly except one hunk fails due to a non-backported change updating a
for to a for each:
$ cat
This is fine Henry
Best
Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
On Jun 9, 2014, at 5:39 PM, Henry Jen henry@oracle.com wrote:
Hi,
Please
The type sun.misc.Timer has long since been replaced by the standard
java.util.Timer. As an unneeded part of sun.misc, sun.misc.Timer should
be removed from the platform. This is part of the larger cleanup of
legacy unused classes from sun.misc, see JDK-6852936 [1].
sun.misc.Timeable will
Thanks for the review, Lance.
Cheers,
Henry
On 06/16/2014 04:33 AM, Lance @ Oracle wrote:
This is fine Henry
Best
Lance
http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen|
Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037
Oracle Java Engineering
1
Hi Chris,
Looks good, especially since there are no current uses.
Roger
On 6/16/2014 11:05 AM, Chris Hegarty wrote:
The type sun.misc.Timer has long since been replaced by the standard
java.util.Timer. As an unneeded part of sun.misc, sun.misc.Timer
should be removed from the platform. This
Remove it before someone starts to use it!
Mike
On Jun 16 2014, at 08:05 , Chris Hegarty chris.hega...@oracle.com wrote:
The type sun.misc.Timer has long since been replaced by the standard
java.util.Timer. As an unneeded part of sun.misc, sun.misc.Timer should be
removed from the
http://cr.openjdk.java.net/~vlivanov/8046903/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8046903
j.l.i.InvokerBytecodeGenerator::isStaticallyInvocable doesn't
distinguish between VM anonymous classes and ordinary classes. In some
very specific circumstances (VM anonymous class declared
After some further reflection i have decided to not separate this out and some
bits going to client and some bits going to dev, and have pushed all changes to
dev. I realise this might cause some friction but believe it the right thing to
do.
I remain unconvinced that the separate process for
OK, let's go the non-controversial approach. The webrev has been updated to
simply remove
those redundant/duplicated class files from the builder and use the updated
version of the tzdb
builder.
http://cr.openjdk.java.net/~sherman/8042369/webrev
Thanks!
-Sherman
On 5/20/2014 1:52 PM, roger
Hi, Chris.
Looks great! Long overdue since java.util.Timer was added around Spring 1999
during JDK 1.3 development.
Thanks,
iris
-Original Message-
From: Chris Hegarty
Sent: Monday, June 16, 2014 8:06 AM
To: Core-Libs-Dev
Subject: RFR [9] 8046902: Remove sun.misc.Timer
The type
Hi Joel,
The 8u version looks fine; thanks,
-Joe
On 06/16/2014 03:57 AM, Joel Borggrén-Franck wrote:
Hi,
Can I get a review for this almost trivial 8u20 back port. The 9 fix reviewed
here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027173.html
applies cleanly except
Reviewed. — John
On Jun 16, 2014, at 9:50 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8046903/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8046903
j.l.i.InvokerBytecodeGenerator::isStaticallyInvocable doesn't distinguish
between VM
Hi Claes,
The descriptions of the new methods should take the same form as
the coresponding existing methods. The rationalization about intermediary
objects is not useful in describing the behavior of the method and
should be omitted.
/**
* Parses the string argument starting at fromIndex
On 2014-06-16 21:50, roger riggs wrote:
Hi Claes,
The descriptions of the new methods should take the same form as
the coresponding existing methods. The rationalization about
intermediary
objects is not useful in describing the behavior of the method and
should be omitted.
Point taken!
Hello Claes,
Instead of saying
* Extend upon parseFoo(String, int)
in the javadoc of the new methods paired with an
* @see parseFoo(String, int)
please use an {@link parseFoo} instead.
Thanks,
-Joe
On 06/15/2014 03:22 PM, Claes Redestad wrote:
I've updated the patch to use
Hi Martin,
Thanks for augmenting my patch and pushing it into the JSR166 repo. Here's the
patch rebased against jdk9-dev. Please review.
s'marks
# HG changeset patch
# User smarks
# Date 1402960663 25200
# Mon Jun 16 16:17:43 2014 -0700
# Node ID
Looks good!
On Mon, Jun 16, 2014 at 4:52 PM, Stuart Marks stuart.ma...@oracle.com
wrote:
Hi Martin,
Thanks for augmenting my patch and pushing it into the JSR166 repo. Here's
the patch rebased against jdk9-dev. Please review.
s'marks
# HG changeset patch
# User smarks
# Date
This is somewhat moot at this point, but
I'd recommend against using paragraph end tags /p. Paragraph end tags really
are optional in HTML. I've heard some advocates of end tags, such as commenters
on the linked web page, say that end tags are somehow more correct (wrong) or
that end tags
On 6/16/2014 5:35 PM, Stuart Marks wrote:
This is somewhat moot at this point, but
I'd recommend against using paragraph end tags /p. Paragraph end
tags really are optional in HTML. I've heard some advocates of end
tags, such as commenters on the linked web page, say that end tags are
19 matches
Mail list logo
