Hi Stuart,
Looks good to go back; thanks,
-Joe
On 2/26/2014 4:44 PM, Stuart Marks wrote:
Hi all,
Any takers for this review?
s'marks
On 2/18/14 6:47 PM, Stuart Marks wrote:
Hi all,
Please review this change to remove a redundant timing-retry loop
from the
rmidRunning() routine of the
On 2/19/2014 12:16 PM, Martin Buchholz wrote:
The jsr166 CVS version of this file already has serialVersionUIDs added.
jsr166 CVS src/main has been jdk8/jdk9 warning-clean for a while now.
Thanks for the update Martin; looking forward to the next sync to get
rid of a few more warnings :-)
I've removed the incorrect-for-JBS multiple release values of 8-pool,
9 in the fixVersion field of the main bug record.
-Joe
On 1/24/2014 10:39 AM, Volker Simonis wrote:
Hi Vladimir,
I've just pushed this to jdk9/dev.
I also received an email stating that this bug needs to be updated,
Hi Brian,
On 1/16/2014 10:51 AM, Brian Burkhalter wrote:
Hi Joe,
On Jan 16, 2014, at 9:23 AM, Joe Darcy wrote:
A few comments here. If you are making this change in Double, you would make
the corresponding change in Float too.
Please see the updated webrev
Hi Brian,
Lots good other than a few quibbles:
We usually use
/*
*
*/
for long multi-line comments rather than
//
//
//
In the test update, we don't usually include mention of the bug id other
than the @bug line.
Thanks,
-Joe
On 1/14/2014 11:56 AM, Brian
Sound good to me :-)
Thanks
-Joe
On 12/13/2013 4:19 PM, Brian Burkhalter wrote:
The patch in questions was already approved in this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023611.html
so unless there are objections I shall push it to the new Java 9
On 12/10/2013 5:05 PM, Mike Duigou wrote:
Hello all;
This is a documentation only fix for a bug reported by Michael McMahon. The reduce
methods of the primitive streams classes currently reference an apply method
rather than the appropriate applyAsInt, applyAsLong or applyAsDouble methods.
Hi Brian,
I've taken a look at the change, but I don't understand why the problem
wasn't surfaced before?
-Joe
On 12/4/2013 1:34 PM, Brian Burkhalter wrote:
Hello,
Issue: https://bugs.openjdk.java.net/browse/JDK-8029514
Webrev: http://cr.openjdk.java.net/~bpb/8029514/webrev/
The problem
Looks good Brian; thanks,
-Joe
On 12/3/2013 5:33 PM, Brian Burkhalter wrote:
Hello,
Issue: https://bugs.openjdk.java.net/browse/JDK-8029501
Webrev: http://cr.openjdk.java.net/~bpb/8029501/webrev/
This patch would change the division algorithm selection heuristic as
previously described in
Hi Stuart,
Looks good; thanks,
-Joe
On 12/3/2013 5:40 PM, Stuart Marks wrote:
Hi all,
Please review the following small javadoc change. The StringJoiner doc
for a couple methods uses i.e. in the first sentence, which screws
up the javadoc logic that pulls the first sentence into the Method
Hi Brian,
The new thresholds look reasonable, as is planned follow-up tuning in JDK 9.
Thanks,
-Joe
On 12/2/2013 12:54 PM, Brian Burkhalter wrote:
Hello,
Issue: https://bugs.openjdk.java.net/browse/JDK-8022181
Webrev: http://cr.openjdk.java.net/~bpb/8022181/webrev/
Based on numerous
Joel,
If you haven't done so already, please file an rfe to capture Peter's
suggestions.
Thanks,
-Joe
On 11/4/2013 7:29 AM, Joel Borggrén-Franck wrote:
Hi Peter,
As always, thanks for doing this!
On 2 nov 2013, at 22:58, Peter Levart peter.lev...@gmail.com wrote:
Hi,
I propose a set
Hello,
Catching up on email, the specification of java.lang.Class does not
explicitly promise that its notion of equality must be identity for all
time. Therefore, while not required for today's implementations, I would
prefer that new code we write in the JDK use equals rather than == when
Hello,
The incident 9002739 became bug JDK-8014852 (zipfs)
ZipFileSystemProvider: newFileSystem URI format issue, which in turn
was marked as a duplicate of JDK-7156873 (zipfs)
FileSystems.newFileSystem(uri, env) fails for uri with escaped octets.:
Approved!!
-Joe
On 11/7/2013 7:02 PM, Stuart Marks wrote:
Hi all,
Please review this quick one-liner to change the serialver tool so
that it emits a serialVersionUID declaration with the 'private'
modifier, which comports with the recommendation in the
java.io.Serializable page.
Bug:
Hi Andreas,
Approved; thanks,
-Joe
On 10/29/2013 3:26 AM, Andreas Lundblad wrote:
Hi,
Please review the fix for JDK-8016725 below.
Description:
DefaultMethodModeling.java and Equals.java in
jdk/test/java/lang/reflect/Method interfered with each other since
both tests defines a class named
Hi Brian,
On 10/17/2013 12:26 PM, Brian Burkhalter wrote:
This post concerns this issue:
https://bugs.openjdk.java.net/browse/JDK-4891331
I performed some tests using JMH [1] on Mac OS X [2] and Windows 7 [3]. The
tests were equivalent to calling multiply() with argument == this for bit
Hi Eric,
Looks fine; thanks,
-Joe
On 10/10/2013 3:48 PM, Eric McCorkle wrote:
Hello,
Please review this simple patch that adds javadoc comments to
MalformedParametersException to quiet doclint warnings.
Note this patch involves no code changes.
The bug report is here:
I'll pushed with the terminal op reordering you've suggested; thanks for
the reviews,
-Joe
On 10/9/2013 6:17 PM, Mike Duigou wrote:
For consistency I would move the this is a terminal operation paragraph to
just before the @apiNote. I would suggest after the @apiNote but there's no mechanism
Hi Joel,
The code changes look fine, but I'd like to see some refactoring to the
tests. In particular, please put the logic in
81 try {
82 Class? c256 = Class.forName(name256);
83 error++;
84 System.err.println(ERROR: could create + c256);
Hello,
I skimmed the patch and it looked fine.
More generally, we want every package and top-level class in the
com.sun.* namespace to be either explicitly exported or not.
Cheers,
-Joe
On 10/6/2013 1:03 PM, Alan Bateman wrote:
As a follow-up to Joe Darcy's rename of jdk.Supported to
Without comments on the contents of the patch, a change in documented
behavior would require a ccc request.
Cheers,
-Joe
On 10/3/2013 5:58 PM, Brian Burkhalter wrote:
I have reviewed this proposed change a couple of times in its current form and
it looks good to me.
It would be good to see
Enum constructors (as compiled by javac) have synthetic parameters;
constructors of nested classes [1] can have either implicit or synthetic
parameters.
HTH,
-Joe
[1] https://blogs.oracle.com/darcy/entry/nested_inner_member_and_top
On 9/30/2013 8:25 PM, Eric Wang wrote:
Including the
Looks fine; cheers,
-Joe
On 9/16/2013 3:49 PM, Mike Duigou wrote:
Ping!
(still need a reviewer on this)
Mike
On Sep 4 2013, at 11:44 , Mike Duigou wrote:
Hello all;
I have updated the proposed changeset for this issue. I have moved the note to
the interface documentation for Collection
Looks fine; cheers,
-Joe
On 9/13/2013 12:07 PM, roger riggs wrote:
Ping, Reviewer needed for these minor updates, the test is now more
robust thanks to Peter's nudging.
http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
Please review for two corrections:
- The
On 9/10/2013 10:08 AM, David M. Lloyd wrote:
On 09/10/2013 11:54 AM, Mandy Chung wrote:
On 9/10/13 9:47 AM, Joe Darcy wrote:
On 9/10/2013 6:28 AM, Alan Bateman wrote:
On 06/09/2013 04:23, mark.reinh...@oracle.com wrote:
:
Well, looking ahead to when the platform will be composed of modules,
Hello,
Sending along some responses to these questions from Alex:
On 8/25/2013 7:03 AM, Kasper Nielsen wrote:
Hi,
just 2 short questions/commons on java.lang.reflect.Parameter
1)
I was wondering if there is any reason for java.lang.reflect.Parameter not
to expose the index field?
Not sure
Looks fine; cheers,
-Joe
On 9/5/2013 3:46 PM, Stuart Marks wrote:
Hi all,
Please review this specification-only change to allow RMI activation
to be optional. RMI activation, unlike the rest of RMI, pretty much
requires the ability to fork processes at will. This causes
difficulties in
On 9/5/2013 2:20 AM, Alan Bateman wrote:
On 20/03/2013 01:32, Joseph Darcy wrote:
Following up in the same thread, the JEP for this work is now
available for your reading pleasure at:
JEP 179: Document JDK API Support and Stability
http://openjdk.java.net/jeps/179
Joe - do you want
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
Hi Joel,
The new version is better, but for the testing in question I would
prefer to see something even simpler like:
public static void main(String[] args) throws Exception {
int failed = 0;
Class?[] testData = {/* list of class literals*/}
for (Class? toTest:
Hi Vicente,
Looks fine; approved to go back.
Thanks,
-Joe
On 8/6/2013 6:59 AM, Vicente-Arturo Romero-Zaldivar wrote:
Hello,
Please review this patch, which updates test
jdk/test/java/lang/reflect/Method/GenericStringTest.java for it to
pass after changes introduced to generation of bridge
Hello,
Sorry for the repeated review delays.
This looks fine to go back.
Thanks,
-Joe
On 7/22/2013 6:27 AM, Joel Borggren-Franck wrote:
Hi Amy,
I'm happy with the current iteration. I'll help you find an official
reviewer.
cheers
/Joel
On 2013-07-22, Amy Lu wrote:
Thank you Joel for all
On 7/29/2013 9:31 PM, Alan Bateman wrote:
On 29/07/2013 19:17, David M. Lloyd wrote:
Your phrasing makes me think I missed something: is the
Reflection.getCallerClass() method being removed due to some
technical issue that it can only be somehow emulated as a
workaround? Or is it just a
Looks good Mike; cheers,
-Joe
On 7/26/2013 5:06 PM, Mike Duigou wrote:
Hello all;
JDK-6799426 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b) was
pushed without a unit test. (Always recheck for unit tests when breathing life
back into a stale old patch). A unit test is needed.
An update, I played around with the declarations a bit more, but wasn't
about to find something workable so I pushed the already-reviewed version.
If someone else wants to take a crack at improving the generics, I think
that would be a fine refactoring.
Thanks,
-Joe
On 7/25/2013 2:16 PM,
Hi Brian,
Almost there! A few additional comments.
On 7/22/2013 4:47 PM, Brian Burkhalter wrote:
An updated webrev is in the same location:
http://cr.openjdk.java.net/~bpb/6476168/.
On Jul 19, 2013, at 5:38 PM, Joseph Darcy wrote:
A spec quibble decimal separator isn't really
Hi Brian,
Acknowledged, sounds good; thanks,
-Joe
On 7/17/2013 4:42 PM, Brian Burkhalter wrote:
Hi Joe,
I've updated the webrev
http://cr.openjdk.java.net/~bpb/8020641/
to include the minor changes pointed out by Tim
On 7/18/2013 3:20 PM, Brian Burkhalter wrote:
Hi Joe,
On Jul 17, 2013, at 10:31 PM, Joe Darcy wrote:
In the javadoc change, is there a reason for
#91;1,nbsp;12#93;,
rather than just
[1,nbsp;12],
?
Not really.
The update should discuss how normal (that is non-subnormal) values
On 7/9/2013 12:46 PM, Brian Burkhalter wrote:
On Jul 9, 2013, at 12:17 PM, Joe Darcy wrote:
If the specification change
[...] If
2596 * {@code compareMagnitude(BigDecimal.ZERO) == 0}, then
2597 * {@code BigDecimal.ZERO} is returned.
is modified to something like If
Hello,
A quick note on this issue, before the recent work to use better
algorithms for BigInteger arithmetic operation, working with huge
numbers was impractical and thus BigInteger.bitLength misbehavior was
mostly an academic concern. With the better algorithms, exposure to
these large
We generally don't delve into low-level presentation details, but the
change looks fine -- approved to go back.
Cheers,
-Joe
On 7/1/2013 8:04 AM, Eric McCorkle wrote:
Pinging this one again...
On 06/24/13 15:20, Eric McCorkle wrote:
Pinging this RFR. It still needs a capital R reviewer.
On 6/7/2013 2:51 PM, Martin Buchholz wrote:
tt is denigrated in favor of {@code ?
It is by me anyway!
-Joe
Hi Lance,
Looks fine; approved.
Cheers,
-Joe
On 6/6/2013 1:41 PM, Lance Andersen - Oracle wrote:
Hi Aleksey,
The change is 2 lines, not worth a webrev. Here it is again in case it was
truncated in last email (looked OK on my end)
new-host-2:serial lanceandersen$ hg diff
diff -r
Hi Remi,
On 5/22/2013 8:36 AM, Remi Forax wrote:
On 05/21/2013 03:16 AM, Joseph Darcy wrote:
Hi Remi,
On 5/20/2013 2:28 PM, Remi Forax wrote:
On 05/20/2013 11:10 PM, Joe Darcy wrote:
Hello,
Please review the patch below which implements
8014836: Have GenericDeclaration extend
Looks fine.
-Joe
On 5/21/2013 3:42 PM, Mike Duigou wrote:
Hello all;
A lot more people have been playing with using concurrency lately with JTReg and most
have found that tests will frequently fail or error out because of OOM errors. The
problem is that the jdk/test/Makefile currently
is a
Mersenne prime? (2^61 -1 is a Mersenne prime; 2^63 - 1 is not.)
-Joe
On 5/21/2013 3:45 PM, Mike Duigou wrote:
Ping!
I need a final review on this issue.
Thanks,
Mike
On May 16 2013, at 14:02 , Mike Duigou wrote:
On May 15 2013, at 19:09 , Joseph Darcy wrote:
Hi Mike,
Looks fine. Are you
Hi Remi,
On 5/20/2013 2:28 PM, Remi Forax wrote:
On 05/20/2013 11:10 PM, Joe Darcy wrote:
Hello,
Please review the patch below which implements
8014836: Have GenericDeclaration extend AnnotatedElement
All the existing implementations of GenericDeclaration in the JDK
already implement
Hi Mike,
Looks fine. Are you satisfied with the test coverage provided by the
existing regression tests?
-Joe
On 5/15/2013 6:17 PM, Mike Duigou wrote:
Hello all;
This issue was originally part of JDK-8006627 (improve performance of UUID
parsing/formatting) but was split out because it
Acknowledged; thanks for checking,
-Joe
On 4/23/2013 7:46 AM, Eric McCorkle wrote:
I believe so. Alex Buckley recommended the exact wording.
On 04/22/13 22:09, Joseph Darcy wrote:
Hello,
240 * Returns the number of formal parameters (whether explicitly
241 * declared
Hello,
Just reasserting the request for a review of the latest version of this
patch:
http://cr.openjdk.java.net/~darcy/8012044.2
I believe this version does an appropriate job of propagating exception
information when there is misuse of the methods on Throwable.
Thanks,
-Joe
On
Hello,
240 * Returns the number of formal parameters (whether explicitly
241 * declared or implicitly declared or neither) for the executable
Are there parameters that are neither explicitly nor implicitly declared?
I still think the follow comment is better deleted given the
On 4/10/2013 5:02 AM, Remi Forax wrote:
On 04/09/2013 11:12 PM, Joe Darcy wrote:
Hello,
Please review my changes for
8011800: Add java.util.Objects.requireNonNull(T, SupplierString)
http://cr.openjdk.java.net/~darcy/8011800.0/
which add a new method to java.util.Objects to take a
On 2/4/2013 1:36 PM, Stephen Colebourne wrote:
On 4 February 2013 19:31, Joe Darcy joe.da...@oracle.com wrote:
The stripTrailingZeros method has acted in this surprising way since the
IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped
in 2004.
This situation is
Looks fine as far as I can see.
Thanks,
-Joe
On 1/24/2013 3:30 PM, Eric McCorkle wrote:
As far as Coleen and I are aware, this is internal-only. If anyone
knows otherwise, please comment before the end of tomorrow.
Other than that, do you see any problems, Joe?
On 01/24/13 15:41, Joe Darcy
Akhil,
In javadoc like this
298 * as {@code BinaryOperatorlt;Booleangt;}.
you don't have to use lt; and the like inside {@code}; please change to
298 * as {@code BinaryOperatorBoolean}.
As a general comment, if the operations for primitive type Foo are put
into java.lang.Foo, then
Hi Roger,
The changes look fine. However, I suggest adding an explanatory note
along the lines of Normal integer division operates under the round to
zero rounding mode (truncation). This operation instead acts under the
round to negative infinity (floor) rounding mode. The floor rounding
Hello,
Thanks for the patch Louis.
On 7/12/2012 3:21 AM, Andrew Haley wrote:
On 07/12/2012 10:32 AM, Louis Wasserman wrote:
It was attached to the previous message? I don't know if this list works
with attachments. Alternately, the patch was attached here:
Hi Kurchi,
Looks fine,
-Joe
On 5/22/2012 6:32 PM, Kurchi Hazra wrote:
Hi,
This is a minor change to java_props_md.c to return Windows 8 as
the os.name for Windows version 6.2.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169
Webrev:
Hi Remi,
On 4/27/2012 3:38 PM, Rémi Forax wrote:
On 04/27/2012 05:29 AM, Joe Darcy wrote:
On 4/24/2012 8:01 AM, Alan Bateman wrote:
On 24/04/2012 14:56, Rémi Forax wrote:
Here, I don't really ask for tweaking something but more to remove
an assert
which do something which is unrelated to
Looks fine.
Cheers,
-Joe
On 3/28/2012 10:39 AM, Kumar Srinivasan wrote:
Hi,
We are adding new test to test the tool functionality of the launcher:
1. verify the options intended for a tool does gets to it intact,
Steve Sides
from SQE has contributed this test, which applies various
Looks fine,
-Joe
On 2/3/2012 1:23 PM, Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/
fdlibm needs to be compiled with optimization disabled, as on Linux.
Thanks
Michael.
Hello,
On 2/1/2012 1:37 PM, Kumar Srinivasan wrote:
Hi,
Here are some improvements to the launcher tests, contributed by Sonali
Goel of the SQE team, please review:
http://cr.openjdk.java.net/~ksrini/7141141/webrev.0/
The CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141141
Thanks
Hello,
On 1/26/2012 9:13 AM, Ulf Zibis wrote:
Am 26.01.2012 17:11, schrieb Roger Riggs:
[snip]
Its unfortunate that between the method name and need to qualify
with the class (or use static imports) that the code is longer and
not always clearer.
+1
- static import could become
Hello Darryl,
On 1/23/2012 3:19 PM, Darryl Mocek wrote:
Re-sending this with the synopsis in the subject line (and the correct
bug #).
Hello core-libs. Please review this patch to fix Bug #7129185. This
fix addresses comments made by Jason Mehrens to the commit of the fix
for bug
On 1/18/2012 7:52 PM, Ulf Zibis wrote:
Am 18.01.2012 03:54, schrieb Joe Darcy:
I've posted a revised webrev at
http://cr.openjdk.java.net/~darcy/4504839.2
Instead
code'#92;u0030'/code
you can use
{@code '\u005Cu0030'}
That is a fine cleanup, but I'll do a bulk conversion of all the
66 matches
Mail list logo
