Joe,
I am confused over this warning:
* bWarning: When a single object reference is supplied, the returned
* value does not equal the hash code of that object reference./b This
* value can be computed by calling {...@link #hashCode(Object)}.
I first looked into Arrays#deepHashCode and did not
Would be really helpful for those tasks that are paused purposefully or not.
All,
While I agree that the nonNull methods below are useful and should be in
the JDK, I question whether they should be on j.u.Objects.
I believe that there is a whole category of methods to pre-validate the
arguments of a method, such as Commons Lang Validate, or Google Prevalidate.
Hello,
Please review the next version of the fix contributed by Damjan Jovanovic:
RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094
There you can also find some latest comments regarding the fix.
webrev:
http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.1/
Since the patch
Le 14/10/2009 01:32, Joseph D. Darcy a écrit :
Hello.
Following up from threads earlier this year,
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html
I'm willing and interested to
I agree with Stephen. There are a slew of validation methods that
would be beneficial, and if you really want to drive the JDK towards
standard validation, refactor them out into a Validation class. Look
at what Spring has written for themselves:
Hi Rémi,
One quick comment on AbstractStringBuilder.join(String, Object,
Object...) -- I'd propose to check that 'elements' is not null prior
to appending 'first' so that if the preconditions are violated and the
NullPointerException is thrown, there are no side effects. This would
also be a nice
Paul Benedict wrote:
Joe,
I am confused over this warning:
* bWarning: When a single object reference is supplied, the returned
* value does not equal the hash code of that object reference./b This
* value can be computed by calling {...@link #hashCode(Object)}.
I first looked into
Am 07.10.2009 23:01, Xueming Shen schrieb:
Ulf Zibis wrote:
Sherman, thanks for your review ...
Am 07.10.2009 19:56, Xueming Shen schrieb:
Though I did not write the cache code my reading suggests the
existing cache
impl tries to avoid the relatively expensive synchronization for
most use
Am 14.10.2009 17:01, Rémi Forax schrieb:
Le 14/10/2009 16:47, Ulf Zibis a écrit :
Rémi,
can you tell me how you got the cr.openjdk.java.net account ?
Is there any registration link?
Thanks,
Ulf
I've got it because I've the right to push codes on mlvm repository
(the DaVinci machine
Jesús Viñuales wrote:
I agree with Stephen. There are a slew of validation methods that
would be beneficial, and if you really want to drive the JDK towards
standard validation, refactor them out into a Validation class. Look
at what Spring has written for themselves:
2009/10/14 Ulf Zibis ulf.zi...@gmx.de:
Am 14.10.2009 17:01, Rémi Forax schrieb:
Le 14/10/2009 16:47, Ulf Zibis a écrit :
Rémi,
can you tell me how you got the cr.openjdk.java.net account ?
Is there any registration link?
Thanks,
Ulf
I've got it because I've the right to push codes on
Joseph D. Darcy wrote:
If such a validation class is added to the platform, the nonNull
methods can be moved there. Until then, they can live in Objects.
At first glance, such an approach makes perfect sense. However, we
should really stop and question whether it is right or not.
One point
Stephen,
My interpretation of Joe's email was that it would stay in j.u.Objects
unless someone (other than him) contributes the Validate class and
tests. Granting your point, his choice would otherwise stand and
re-factoring it after JDK 7 would be impossible.
I am interested in such a class and
Stephen Colebourne wrote:
Joseph D. Darcy wrote:
If such a validation class is added to the platform, the nonNull
methods can be moved there. Until then, they can live in Objects.
At first glance, such an approach makes perfect sense. However, we
should really stop and question whether it is
Changeset: 86b773b7cb40
Author:jjg
Date: 2009-10-14 15:41 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/86b773b7cb40
6838467: JSR199 FileObjects don't obey general contract of equals.
Reviewed-by: darcy
! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java
Alan, Sean,
Can you review the fix for:
6891707: Eliminate the java.io.FilePermission dependency on PolicyFile
Webrev:
http://cr.openjdk.java.net/~mchung/6891707/webrev.00/
FilePermission and PolicyFile are the two callers to the
sun.security.provider.PolicyFile.canonPath method. Adding a
Changeset: b8936a7930fe
Author:darcy
Date: 2009-10-14 18:56 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b8936a7930fe
6558804: Specification for Elements.getDocComment(Element e) should be clarified
Reviewed-by: jjg
!
Changeset: 16b33372af1c
Author:mchung
Date: 2009-10-14 20:16 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16b33372af1c
6891701: test/java/lang/management/RuntimeMXBean/GetSystemProperties should
restore the system property
Summary: Restore the system properties when the
19 matches
Mail list logo
