Ok, here's a test...
with just the following change:
diff -r 9ea9fb3c0c88 src/java.base/share/classes/java/math/BigInteger.java
--- a/src/java.base/share/classes/java/math/BigInteger.java Wed Mar
23 18:24:35 2016 +0100
+++ b/src/java.base/share/classes/java/math/BigInteger.java Wed Mar
Hi Xuelei,
On 03/23/2016 04:26 AM, Xuelei Fan wrote:
Hi,
Please review the update for the supporting of BigInteger.TWO:
http://cr.openjdk.java.net/~xuelei/8152237/webrev/
BigInteger.valueOf(2) is a common BigInteger value used in binary and
cryptography operation calculation. The BigInte
Hi,
How much is the performance improvement?
I see that BigInteger.valueOf (n <= 16) have predefined constants and
returns an existing instance.
Adding TWO is ok.
Roger
On 3/23/2016 9:44 AM, Wang Weijun wrote:
On Mar 23, 2016, at 7:23 PM, Xuelei Fan wrote:
On 3/23/2016 5:44 PM, Wang Weiju
Thanks!
Xuelei
On 3/23/2016 9:44 PM, Wang Weijun wrote:
>
>> On Mar 23, 2016, at 7:23 PM, Xuelei Fan wrote:
>>
>> On 3/23/2016 5:44 PM, Wang Weijun wrote:
>>> Then why not fix the 2 bugs in a single changeset?
>>>
>> Both need spec update approval. As they are completely different spec
>> upda
> On Mar 23, 2016, at 7:23 PM, Xuelei Fan wrote:
>
> On 3/23/2016 5:44 PM, Wang Weijun wrote:
>> Then why not fix the 2 bugs in a single changeset?
>>
> Both need spec update approval. As they are completely different spec
> update, better to update in 2 enhancements.
>
> As you have concerns
Hi Attila,
Good catch about the comparing. I updated the code in my local
workspace, and I would ask for code review in another enhancement update
soon.
Thanks,
Xuelei
On 3/23/2016 9:15 PM, Attila Szegedi wrote:
> Sorry for beating the dead horse of ObjectIdentifier.java change, but
> I’d sugge
Sorry for beating the dead horse of ObjectIdentifier.java change, but I’d
suggest that if that code is later revisited, it be changed to
"first.compareTo(BigInteger.TWO) > 0" instead of “… == 1”.
Comparing the return value of compareTo to zero (instead of relying on specific
set of return value
On 3/23/2016 5:44 PM, Wang Weijun wrote:
> Then why not fix the 2 bugs in a single changeset?
>
Both need spec update approval. As they are completely different spec
update, better to update in 2 enhancements.
As you have concerns here, I removed ObjectIdentifier.java from this
update. See the
Then why not fix the 2 bugs in a single changeset?
--Max
> 在 2016年3月23日，17:06，Xuelei Fan 写道：
>
>> On 3/23/2016 3:34 PM, Wang Weijun wrote:
>>
>>> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote:
>>>
>>> On 3/23/2016 12:10 PM, Wang Weijun wrote:
Only 3 files touched. Are you going to make
On 3/23/2016 3:34 PM, Wang Weijun wrote:
>
>> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote:
>>
>> On 3/23/2016 12:10 PM, Wang Weijun wrote:
>>> Only 3 files touched. Are you going to make the
>>> s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another
>>> bug fix?
>>>
>> T
> On Mar 23, 2016, at 12:48 PM, Xuelei Fan wrote:
>
> On 3/23/2016 12:10 PM, Wang Weijun wrote:
>> Only 3 files touched. Are you going to make the
>> s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another
>> bug fix?
>>
> There are also uses in security components. I wil
On 3/23/2016 12:10 PM, Wang Weijun wrote:
Only 3 files touched. Are you going to make the
s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug
fix?
There are also uses in security components. I will make the update in
another bug.
Thanks,
Xuelei
Thanks
Max
On
Only 3 files touched. Are you going to make the
s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug
fix?
Thanks
Max
> On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote:
>
> Hi,
>
> Please review the update for the supporting of BigInteger.TWO:
>
> http://cr.openjd
Hi,
Sure, I'll sponsor this for Hadeesh and fix the typo at the same time.
Thanks, Roger
On 4/2/2015 10:24 AM, Ivan Gerasimov wrote:
Looks good.
Can we also fix a typo in the doc with this change?
662 * Return the maximum supported Hijrah ear.
s/ear/year/ :)
Sincerely yours,
Ivan
Looks good.
Can we also fix a typo in the doc with this change?
662 * Return the maximum supported Hijrah ear.
s/ear/year/ :)
Sincerely yours,
Ivan
On 01.04.2015 22:50, nadeesh tv wrote:
Hi all,
Please review this minor change which remove a dead code in
isLeapYear(long prolepticYe
Thanks Vinnie for the review~
Forwarding this request to core-libs-dev per Sean's suggestion.
Changes are for getting rid of compiler warnings in order for JCE
provider build (still using the old build process) to complete
successfully - either add the annotation to suppress rawtype warnings or
On 12/08/2013 10:50, Chris Hegarty wrote:
Thanks Alan,
To clarify, I there are no objections, I'll push the following change
along with Amy's updates for the ProblemList
diff -r ce1c874903cb test/java/util/Collection/MOAT.java
--- a/test/java/util/Collection/MOAT.java Fri Aug 09 17:56:3
Thanks Alan,
To clarify, I there are no objections, I'll push the following change
along with Amy's updates for the ProblemList
diff -r ce1c874903cb test/java/util/Collection/MOAT.java
--- a/test/java/util/Collection/MOAT.java Fri Aug 09 17:56:38 2013
+0100
+++ b/test/java/util/Collecti
On 12/08/2013 09:57, Chris Hegarty wrote:
Thanks for doing this Amy.
The changes look fine to me. I wonder if there would be any opposition
to adding java/util/Collection/MOAT.java, until 8020536 can be addressed.
-Chris.
P.S. I can sponsor this change for you, if you need a sponsor.
Amy's
Thanks for doing this Amy.
The changes look fine to me. I wonder if there would be any opposition
to adding java/util/Collection/MOAT.java, until 8020536 can be addressed.
-Chris.
P.S. I can sponsor this change for you, if you need a sponsor.
On 12/08/2013 09:36, Amy Lu wrote:
ProblemList u
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
Looks fine.
-Sherman
On 08/04/2013 06:28 PM, Weijun Wang wrote:
Please take a look at
http://cr.openjdk.java.net/~weijun/8021788/webrev.00/
The problem is that the method treats no META-INF entry as normal. If we can be
sure that MANIFEST.MF and signature-related files are always at the b
This looks ok to me Max, but I think it would be good to get a second
review on this too.
-Chris.
On 05/08/2013 02:28, Weijun Wang wrote:
Please take a look at
http://cr.openjdk.java.net/~weijun/8021788/webrev.00/
The problem is that the method treats no META-INF entry as normal. If we
can b
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
Vladimir Ivanov has already written tests at the classfile level, which javac
doesn't generate.
They do not all pass yet, which is why they are not on by default.
Let me know if anyone wants to study the details.
Note that there is already a bug filed to remove the bridging and covariant
return
Hi Amy,
On Jul 24, 2013, at 3:30 AM, Amy Lu wrote:
> Thank you Dan !
>
> Please see my comments inline...
>
> On 7/24/13 5:12 AM, Dan Smith wrote:
>> Hi.
>>
>> Per a request from Joel, I've taken a look at DefaultStaticTestData. I
>> don't really have the full context here, but I'm assuming
Hi Dan,
Thanks for looking at this,
On Jul 23, 2013, at 11:12 PM, Dan Smith wrote:
> Hi.
>
> Per a request from Joel, I've taken a look at DefaultStaticTestData. I don't
> really have the full context here, but I'm assuming that the annotations get
> translated into tests that guarantee 1)
Thank you Dan !
Please see my comments inline...
On 7/24/13 5:12 AM, Dan Smith wrote:
Hi.
Per a request from Joel, I've taken a look at DefaultStaticTestData. I don't really have
the full context here, but I'm assuming that the annotations get translated into tests
that guarantee 1) the res
Hi.
Per a request from Joel, I've taken a look at DefaultStaticTestData. I don't
really have the full context here, but I'm assuming that the annotations get
translated into tests that guarantee 1) the result of Class.getMethods is
exactly (no more -- excepting Object methods -- and no less) t
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 the valuable feedback.
>
> Test have been refactored and here comes the updated version:
> https://dl.dropboxusercontent.com/u/5812451/yl1537
Thank you Joel for all the valuable feedback.
Test have been refactored and here comes the updated version:
https://dl.dropboxusercontent.com/u/5812451/yl153753/7184826/webrev.01/index.html
Thanks,
Amy
On 7/10/13 10:17 PM, Joel Borggren-Franck wrote:
Hi Amy, Tristan,
I'm not a Reviewer kind
Hi Amy, Tristan,
I'm not a Reviewer kind of reviewer, but I've started to look at the
code and can sponsor this.
Some comments on test/java/lang/reflect/Method/invoke/DefaultStaticTest.java:
As there are a lot of non-public top-level classes perhaps this test
should be in it own directory.
It i
Yes, I have that removed. Thanks for the review!
- Kurchi
On 6/18/2013 1:57 AM, Chris Hegarty wrote:
For the purposes of this issue, I think your changes to hashCode are
in line with the equals implementation. Trivially, you could also
remove the '(obj != null) && ' from equals ;-) Otherwise,
For the purposes of this issue, I think your changes to hashCode are in
line with the equals implementation. Trivially, you could also remove
the '(obj != null) && ' from equals ;-) Otherwise, looks fine to me.
-Chris.
On 06/18/2013 12:01 AM, Kurchi Hazra wrote:
I spent some more time reviewi
I spent some more time reviewing this, I believe the equals()
implementation is correct. Given one string, we get a unique
Identifier. The Identifier has the associated Type cached - so given an
Identifier, we get a unique Type too. One usage of the
ClassDeclaration#equals() method is in ClassDef
On 6/14/2013 11:56 PM, Alan Bateman wrote:
On 14/06/2013 23:59, Kurchi Hazra wrote:
Hi,
This is to elimnate the overrides warning from ClassDeclaration.java.
This class is used by rmi, but sun/tools/java and
sun/tools/javac also heavily uses it, let me know if anyone else
should also be revi
On 14/06/2013 23:59, Kurchi Hazra wrote:
Hi,
This is to elimnate the overrides warning from ClassDeclaration.java.
This class is used by rmi, but sun/tools/java and
sun/tools/javac also heavily uses it, let me know if anyone else
should also be reviewing it.
Bug: http://bugs.sun.com/view_bug
This has been pending on review for long ... Please help to review. I
also need a sponsor for this.
Thank you very much.
/Amy
On 5/23/13 10:48 PM, Amy Lu wrote:
Please help to review:
More tests for 7184826: (reflect) Add support for Project Lambda
concepts in core reflection
This include
On 5/28/2013 3:50 PM, Alan Bateman wrote:
> On 28/05/2013 02:31, Xuelei Fan wrote:
>> Ping again, any one available to review this changeset?
> It's good to fix up FindBugs warnings and I think these changes are okay.
>
> Can the @SuppressWarnings("unchecked") be removed from
> GenericURLContext.r
On 28/05/2013 02:31, Xuelei Fan wrote:
Ping again, any one available to review this changeset?
It's good to fix up FindBugs warnings and I think these changes are okay.
Can the @SuppressWarnings("unchecked") be removed from
GenericURLContext.removeFromEnvironment now?
-Alan
I'm not familiar with these particular APIs but in general making
defensive copies of mutable objects is good practice. In this case
however it is unclear what the impact may be on existing users of this
code. Eg:
com/sun/jndi/toolkit/ctx/Continuation.java
The "environment" is only stored for
Ping again, any one available to review this changeset?
Thanks,
Xuelei
On 5/13/2013 11:06 PM, Xuelei Fan wrote:
> On 5/13/2013 10:52 PM, Wang Weijun wrote:
>> I'll read them tomorrow.
> OK. It's not a urgent fix.
>
>> One question: are all of them designed to be call-by-value instead of
>> shar
Right - I think I can disable syncing attempts for a file once we get an
EACCESS error code . Locked files
should return EAGAIN. I'll have to check on how this works on
Solaris/Linux/Mac and will follow up.
Thanks for digging up the history.
- Kurchi
On 5/21/2013 10:28 AM, Mike Duigou wrote:
On May 21 2013, at 10:04 , Kurchi Subhra Hazra wrote:
> On 5/21/13 9:53 AM, Kurchi Subhra Hazra wrote:
>> On 5/21/13 9:40 AM, Mike Duigou wrote:
>>> Any chance that it would be possible to stop the periodic attempts to sync
>>> preferences?
>>
>> - I did think of that too - but the syncing may
On May 21 2013, at 09:53 , Kurchi Subhra Hazra wrote:
> On 5/21/13 9:40 AM, Mike Duigou wrote:
>> Any chance that it would be possible to stop the periodic attempts to sync
>> preferences?
>
> - I did think of that too - but the syncing may fail(temporarily) if the
> prefs object could not ret
On 5/21/13 9:53 AM, Kurchi Subhra Hazra wrote:
On 5/21/13 9:40 AM, Mike Duigou wrote:
Any chance that it would be possible to stop the periodic attempts to
sync preferences?
- I did think of that too - but the syncing may fail(temporarily) if
the prefs object could not retrieve the lock to th
On 5/21/13 9:40 AM, Mike Duigou wrote:
Any chance that it would be possible to stop the periodic attempts to sync
preferences?
- I did think of that too - but the syncing may fail(temporarily) if the
prefs object could not retrieve the lock to the
associated prefs file. We could stop syncing
Any chance that it would be possible to stop the periodic attempts to sync
preferences?
The log spamming is a symptom, not the cause.
Could the prefs code be enhanced to better determine if writing is possible
before attempting and failing?
Mike
On May 21 2013, at 01:21 , Mandy Chung wrote:
On 5/21/13 1:35 AM, Mandy Chung wrote:
Kurchi,
The windows implementation also emits warning messages that should be
fixed up too since we don't want to emit anything to interfere the
application logging. The default logging configuration (default level
is INFO) should apply to the applicati
Kurchi,
The windows implementation also emits warning messages that should be
fixed up too since we don't want to emit anything to interfere the
application logging. The default logging configuration (default level
is INFO) should apply to the application logging and the runtime like
this ca
On 5/21/2013 1:42 AM, Kurchi Hazra wrote:
Hi,
Please review this change to fix 718655. The bug complaints about
continuous BackingStoreExceptions
printed on the console, the user is just seeing logged warnings from
BackingStoreExceptions raised in periodic attempts to sync
preferences. Pr
On 5/21/13 3:53 PM, Alan Bateman wrote:
On 20/05/2013 16:07, Amy Lu wrote:
More ProblemList updates to remove three tests, the related issues
have been fixed.
Please review:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8014892/webrev/index.html
Thanks,
Good to catch cases where w
On 20/05/2013 16:07, Amy Lu wrote:
More ProblemList updates to remove three tests, the related issues
have been fixed.
Please review:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8014892/webrev/index.html
Thanks,
Good to catch cases where we neglected to remove the tests from the
On 5/16/13 5:52 PM, Xuelei Fan wrote:
On 5/16/2013 5:22 PM, Weijun Wang wrote:
Hi Xuelei
I'm busy on something else, so probably have no time (or cannot
concentrate) to read in details.
Not urgent fix, so please review these request only when you available.
In my opinion, there are severa
Looks fine Xuelei
best
Lance
On May 16, 2013, at 5:08 AM, Xuelei Fan wrote:
> Hi,
>
> There is another fix to avoid the use of mutable objects.
>
> webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/
>
> Thanks,
> Xuelei
Lance Andersen| Principal Member of Technical Staff | +1.781.
On 5/16/2013 5:22 PM, Weijun Wang wrote:
> Hi Xuelei
>
> I'm busy on something else, so probably have no time (or cannot
> concentrate) to read in details.
>
Not urgent fix, so please review these request only when you available.
> In my opinion, there are several cases as to whether to clone or
Hi Xuelei
I'm busy on something else, so probably have no time (or cannot
concentrate) to read in details.
In my opinion, there are several cases as to whether to clone or not:
1. MUST NOT clone, because the value must be shared so that change at
one side appears on the other side.
2. MUST
Looks fine.
Mike
On May 15 2013, at 09:44 , Joe Darcy wrote:
> On 05/14/2013 06:32 AM, Alan Bateman wrote:
>> On 10/05/2013 22:01, Joe Darcy wrote:
>>> Hello,
>>>
>>> Please (re)review this change to introduce Objects.requireNonNull(T,
>>> Supplier):
>>>
>>>http://cr.openjdk.java.net/~dar
On 15/05/2013 17:44, Joe Darcy wrote:
:
Sorry for introduce the javadoc issue.
Please review this patch
--- a/src/share/classes/java/util/Objects.javaMon May 13 22:16:55
2013 -0700
+++ b/src/share/classes/java/util/Objects.javaWed May 15 09:43:16
2013 -0700
@@ -269,7 +269,7 @@
On 05/14/2013 06:32 AM, Alan Bateman wrote:
On 10/05/2013 22:01, Joe Darcy wrote:
Hello,
Please (re)review this change to introduce Objects.requireNonNull(T,
Supplier):
http://cr.openjdk.java.net/~darcy/8014365.0/
The original change had to be pulled out because of a build issue
(80123
On 10/05/2013 22:01, Joe Darcy wrote:
Hello,
Please (re)review this change to introduce Objects.requireNonNull(T,
Supplier):
http://cr.openjdk.java.net/~darcy/8014365.0/
The original change had to be pulled out because of a build issue
(8012343: Objects.requireNonNull(Object,Supplier) b
Thanks for the review Mike,
-Joe
On 05/13/2013 10:06 PM, Mike Duigou wrote:
Looks fine to me. Welcome back Objects.requireNonNull(obj, Supplier)!
Mike
On May 10 2013, at 14:01 , Joe Darcy wrote:
Hello,
Please (re)review this change to introduce Objects.requireNonNull(T,
Supplier):
ht
Looks fine to me. Welcome back Objects.requireNonNull(obj, Supplier)!
Mike
On May 10 2013, at 14:01 , Joe Darcy wrote:
> Hello,
>
> Please (re)review this change to introduce Objects.requireNonNull(T,
> Supplier):
>
>http://cr.openjdk.java.net/~darcy/8014365.0/
>
> The original change ha
On 5/13/2013 10:52 PM, Wang Weijun wrote:
> I'll read them tomorrow.
OK. It's not a urgent fix.
> One question: are all of them designed to be call-by-value instead of
> shareable?
>
I'm not sure I understand the term "call-by-value" or "shareable". From
my understand, they are public classes, a
I'll read them tomorrow. One question: are all of them designed to be
call-by-value instead of shareable?
Thanks
Max
On May 13, 2013, at 10:05 PM, Xuelei Fan wrote:
> Hi,
>
> There is some constructors issues about mutable objects in
> com.sun.jndi.toolkit.
>
> webrev: http://cr.openjdk.java
Good. They look fine.
-Max
On 5/9/13 10:31 AM, Xuelei Fan wrote:
Oops, here is the webrev:
http://cr.openjdk.java.net/~xuelei/8005598/webrev.00/
Xuelei
On 5/9/2013 10:30 AM, Xuelei Fan wrote:
Hi,
It's a correction of previous fix of JDK-8003265:
http://hg.openjdk.java.net/jdk8/tl/jdk/r
Oops, here is the webrev:
http://cr.openjdk.java.net/~xuelei/8005598/webrev.00/
Xuelei
On 5/9/2013 10:30 AM, Xuelei Fan wrote:
> Hi,
>
> It's a correction of previous fix of JDK-8003265:
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4472a641b4dc
>
> Which introduced compiler warning and er
[email protected]; [email protected]
> Subject: Re: Code review request for 8012044: Give more information about
> self-suppression from Throwable.addSuppressed
>
> On 04/14/2013 07:36 PM, Joe Darcy wrote:
> > On 04/12/2013 07:29 PM, Jason Mehrens wrote:
> >> Joe,
&
On 04/14/2013 07:36 PM, Joe Darcy wrote:
On 04/12/2013 07:29 PM, Jason Mehrens wrote:
Joe,
You'll have guard ise.addSuppressed against null. Looks good otherwise.
private static void initCauseNull() {
Throwable t1 = new Throwable();
t1.initCause(null);
try {
t1.initCa
o: [email protected]
> CC: [email protected]; [email protected]
> Subject: Re: Code review request for 8012044: Give more information about
> self-suppression from Throwable.addSuppressed
>
> On 13/04/2013 5:08 AM, Joe Darcy wrote:
> > On 04/12/2013 11:22 AM,
On 13/04/2013 5:08 AM, Joe Darcy wrote:
On 04/12/2013 11:22 AM, Jason Mehrens wrote:
The landmines are the retrofitted exception classes as shown here
https://netbeans.org/bugzilla/show_bug.cgi?id=150969 and
https://issues.jboss.org/browse/JBREM-552. Really, if the ISE or IAE
is thrown it is goi
ion(NULL_CAUSE_MESSAGE);
Cheers,
-Joe
Jason
Date: Fri, 12 Apr 2013 12:08:07 -0700
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: Code review request for 8012044: Give more information about
self-suppression from Throwable.addSuppr
2 Apr 2013 12:08:07 -0700
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: Code review request for 8012044: Give more information about
self-suppression from Throwable.addSuppressed
On 04/12/2013 11:22 AM, Jason Mehrens wrote:
The landmines ar
On 04/12/2013 11:22 AM, Jason Mehrens wrote:
The landmines are the retrofitted exception classes as shown here
https://netbeans.org/bugzilla/show_bug.cgi?id=150969 and
https://issues.jboss.org/browse/JBREM-552. Really, if the ISE or IAE
is thrown it is going to suppress 'this' and 'cause'. It
ee the given
'cause' show up in a log file when tracking down this type of bug. Date: Fri,
12 Apr 2013 10:35:40 -0700
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: Code review request for 8012044: Give more informatio
Hi Jason,
Hmm. This is the current initCause implementation from JDK 8:
public synchronized Throwable initCause(Throwable cause) {
if (this.cause != this)
throw new IllegalStateException("Can't overwrite cause");
if (cause == this)
throw new IllegalArg
Joe, Should this same logic be applied to the exceptions thrown from initCause?
Seems like that would be consistent with this change. Jason
> Date: Thu, 11 Apr 2013 18:19:30 -0700
> From: [email protected]
> To: [email protected]
> Subject: Code review request for 8012044: Give m
Hi Joe,
There were certainly debates about why self-suppression is not a good
thing when project Coin's try-with-resources has been developed, but I
don't quite remember the reason why it was designed this way. Couldn't
the logic just make the self-suppression a no-op? The addSuppressed was
d
It doesn't feel very right to say the exception is the "cause" of the IAE.
If the user code reuses an exception instance "x", as reported by OP,
there is a possibility that the IAE is later added as a suppressed
exception to "x", forming a loop x->IAE->x.
Zhong Yu
On Thu, Apr 11, 2013 at 8:19 P
On 04/05/2013 05:46 AM, Alan Bateman wrote:
On 03/04/2013 17:38, Joe Darcy wrote:
Hi Peter,
On 04/03/2013 01:26 AM, Peter Levart wrote:
Hi Joe,
Why not using StringBuilder instead of StringBuffer in
Class.toGenericString ?
No reason. Thanks for catching this; I'll use StringBuilder in the
On 03/04/2013 17:38, Joe Darcy wrote:
Hi Peter,
On 04/03/2013 01:26 AM, Peter Levart wrote:
Hi Joe,
Why not using StringBuilder instead of StringBuffer in
Class.toGenericString ?
No reason. Thanks for catching this; I'll use StringBuilder in the
final push.
Modifier.toString can probably
Hi Peter,
On 04/03/2013 01:26 AM, Peter Levart wrote:
Hi Joe,
Why not using StringBuilder instead of StringBuffer in
Class.toGenericString ?
No reason. Thanks for catching this; I'll use StringBuilder in the final
push.
Thanks,
-Joe
Regards, Peter
On 04/03/2013 09:27 AM, Joe Darcy wr
Hi Joe,
Why not using StringBuilder instead of StringBuffer in
Class.toGenericString ?
Regards, Peter
On 04/03/2013 09:27 AM, Joe Darcy wrote:
Hello,
This is combined code review request for
629 (reflect) Add toGenericString to java.lang.Class and
getTypeName to java.lang.reflect.
On Mar 12 2013, at 06:51 , Paul Sandoz wrote:
>> - should be replace with {@code}
>>
>
> It is mostly consistent with the rest of the Map documentation. We should do
> a global replace in that case?
We are incrementally updating the source with this change. Nobody is going out
of their way t
Max,
Does this overlap with the testlibrary for supporting muli-process tests
that Katja Kantserova added recently?
-Alan.
On 13/03/2013 11:18, Weijun Wang wrote:
http://cr.openjdk.java.net/~weijun/8009977/webrev.00
/**
* This is a test library that makes writing a Java test that spawns
Hi Mike,
On Mar 12, 2013, at 2:29 AM, Mike Duigou wrote:
> AbstractTask::
>
> - "that describes a portion of the input" -> describes the he portion of the
> input associated with the subtree rooted at this task.
>
> - setRawResult() : needs better docs. Why does getRawResult return local
>
On Mar 12, 2013, at 2:29 AM, Mike Duigou wrote:
> Some notes:
>
> - Copyrights update.
>
Pushed to lambda repo:
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/40c0a71455d7
> - The order of notes on files is the order that I read the files. It seems
> like not a bad order to review the
On Mar 12, 2013, at 12:13 AM, Paul Benedict wrote:
> 3) StreamShape: Javadoc should be formatted to be within 80 characters.
>
Hmm... that is linked to an old version.
It should be the same as:
http://hg.openjdk.java.net/lambda/lambda/jdk/raw-file/9ccdccc3c754/src/share/classes/java/util/strea
On 03/12/2013 02:29 AM, Mike Duigou wrote:
Some notes:
- Copyrights update.
- The order of notes on files is the order that I read the files. It seems like
not a bad order to review them.
- package docs? Coming next?
java.util.Map::
- @since 1.8 missing for defaults
- should be replace wi
2) I find X_IN and X_OUT type parameters to be disruptive to reading.
Sticking to a simple "I" and "O" would be much easier to read.
I'll answer this one because we've gotten it from a few places.
This is a nice idea, and it works fine up to a certain level of
complexity. But when you have a
Some notes:
- Copyrights update.
- The order of notes on files is the order that I read the files. It seems like
not a bad order to review them.
- package docs? Coming next?
java.util.Map::
- @since 1.8 missing for defaults
- should be replace with {@code}
- default methods need the notice
My comments...
1) TerminalOp: When default methods are very simple (i.e., a one-liner),
you are sometimes (not always) putting the body on a new line. I think you
should use a consistent coding style and always start the body on the next
line.
2) I find X_IN and X_OUT type parameters to be disrup
I've posted an updated webrev incorporating comments received to date:
http://cr.openjdk.java.net/~briangoetz/jdk-8008670.2/webrev/
On 2/21/2013 2:16 PM, Brian Goetz wrote:
At:
http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
there is a webrev of a subset of the implementation
On Feb 26, 2013, at 2:50 PM, Remi Forax wrote:
> On 02/25/2013 06:31 PM, Paul Sandoz wrote:
>> Hi Remi,
>>
>> Thanks for the feedback i have addressed some of this, mostly related to
>> inner classes, in following change set to the lambda repo:
>>
>> http://hg.openjdk.java.net/lambda/lambda/j
On 02/25/2013 06:31 PM, Paul Sandoz wrote:
Hi Remi,
Thanks for the feedback i have addressed some of this, mostly related to inner
classes, in following change set to the lambda repo:
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
We can update the webrev next week.
There a
On 02/26/2013 02:11 PM, Paul Sandoz wrote:
On Feb 25, 2013, at 10:45 PM, David Holmes wrote:
On 26/02/2013 3:31 AM, Paul Sandoz wrote:
Hi Remi,
Thanks for the feedback i have addressed some of this, mostly related to
inner classes, in following change set to the lambda repo:
http://hg.openj
On Feb 25, 2013, at 10:45 PM, David Holmes wrote:
> On 26/02/2013 3:31 AM, Paul Sandoz wrote:
>> Hi Remi,
>>
>> Thanks for the feedback i have addressed some of this, mostly related to
>> inner classes, in following change set to the lambda repo:
>>
>> http://hg.openjdk.java.net/lambda/lambda/
On 26/02/2013 3:31 AM, Paul Sandoz wrote:
Hi Remi,
Thanks for the feedback i have addressed some of this, mostly related to
inner classes, in following change set to the lambda repo:
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
I see a lot of private things that are now packa
Hi Remi,
Thanks for the feedback i have addressed some of this, mostly related to inner
classes, in following change set to the lambda repo:
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
We can update the webrev next week.
On Feb 23, 2013, at 11:51 AM, Remi Forax wrote:
> On
On 02/25/2013 04:07 AM, David Holmes wrote:
On 23/02/2013 8:51 PM, Remi Forax wrote:
On 02/21/2013 08:17 PM, Brian Goetz wrote:
At
http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/
I've posted a webrev for about half the classes in java.util.stream.
None of these are public classes,
1 - 100 of 686 matches
Mail list logo
