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 te
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
! src/share/classes/javax/lang/model/util/Elements.
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 th
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: 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
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 r
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
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 tha
2009/10/14 Ulf Zibis :
> 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 rig
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:
http://static.springsource.
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 reposito
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 s
Question for anyone on the list. What do you think about adding a
limited number of String constants to identify common warning types? I
personally don't like raw string in my code and would prefer to use
constants for them.
I would prefer something like:
@SuppressWarnings(UNCHECKED) // static imp
Paul Benedict wrote:
Joe,
I am confused over this warning:
* Warning: When a single object reference is supplied, the returned
* value does not equal the hash code of that object reference. This
* value can be computed by calling {...@link #hashCode(Object)}.
I first looked into Array
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
> 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:
>
>http://static.springsource.org/spring/doc
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 repository).
I can use the same openjdk account to
Rémi,
can you tell me how you got the cr.openjdk.java.net account ?
Is there any registration link?
Thanks,
Ulf
Am 06.02.2009 21:59, Rémi Forax schrieb:
Hi all,
bug 5015163 is a RFE that advocate to add a method join (like in Python)
to String/StringBuilder/StringBuffer.
Here is the corresp
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:
http://static.springsource.org/spring/docs/2.5.x/ap
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 spons
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
Changeset: 5f326176855d
Author:mullan
Date: 2009-10-14 09:36 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5f326176855d
6885667: CertPath/CertPathValidatorTest/bugs/bug6383078 fails on jdk6u18/b02,
jdk7/pit/b73 and passes on b72.
Summary: Wrap all OCSP exceptions in CertPat
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.
http:/
Never mind, just realized that there is no guarantee of what Task
would see it at the correct time. Its easier to set a flag to false
before the sleep and check it after it.
Not thinking concurrently enough.
On Wed, Oct 14, 2009 at 10:11 AM, Paulo Levi wrote:
> Would be really helpful for those
Would be really helpful for those tasks that are "paused" purposefully or not.
Joe,
I am confused over this warning:
> * Warning: When a single object reference is supplied, the returned
> * value does not equal the hash code of that object reference. This
> * value can be computed by calling {...@link #hashCode(Object)}.
I first looked into Arrays#deepHashCode and did not
26 matches
Mail list logo
