Joseph D. Darcy wrote:
Hello.
Please review my changes to address:
5062288 "(reflect) Core reflection uses raw types when it could be
using wildcards"
http://cr.openjdk.java.net/~darcy/5062288.0/
This changeset removes most of the raw types warnings in core
reflection, java.lang.Class and j
Mandy Chung wrote:
Alan, Rémi,
Thanks for the review. The revised webrev is at:
http://cr.openjdk.java.net/~mchung/6612680/jdk-webrev.01/
http://cr.openjdk.java.net/~mchung/6612680/hotspot-webrev.01/
The changes you pushed to jdk7/tl/jdk look fine - thanks for doing the
clean-ups (and for
Please note
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850338
in this context.
-Ulf
Am 06.10.2009 01:43, Joseph D. Darcy schrieb:
Hello.
Please review my changes to address:
5062288 "(reflect) Core reflection uses raw types when it could be
using wildcards"
http://cr.openjdk.jav
Martin points at my page below, which does indeed have a lot of stuff on it,
although I must admit I have not been updating it for the last 3-6 months as
the actual feature list has solidified. At the moment I'm focusing on putting
together the Strange Loop conference (http://thestrangeloop.com
I thought there was the danger of deadlocks if the std.out and std.err
wasn't drained?
In fact my implementation of "fork" is like this, mostly because i
read that otherwise deadlocks happened.:
/**
* This method creates a new process that will run a new jvm
* on the main of the give
Changeset: 572791538be5
Author:darcy
Date: 2009-10-06 13:31 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/572791538be5
5062288: (reflect) Core reflection uses raw types when it could be using
wildcards
Reviewed-by: alanb
! src/share/classes/java/lang/Class.java
! src/share
I.) Internal charset cache will be corrupted in theoretical race conditions:
Startpoint:
cache1 --> Charset1
cache2 --> Charset2
Scenario 1:
- Thread1 asks for Charset2 via Charset.forName("Charset2").
- If Thread1 is interrupted after code line: cache2 = cache1
in method lookup2(String chars
Changeset: 1b81fc851b20
Author:mchung
Date: 2009-10-06 15:14 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1b81fc851b20
602: sun.misc.BootClassLoaderHook.getBootstrapPaths stack overflow
Summary: Fixed sun.misc.BootClassLoaderHook.getBootstrapPaths calls
hook.getAdditio
Joe Darcy wrote:
Joe Darcy wrote:
Joe Darcy wrote:
Stephen Colebourne wrote:
Joe Darcy wrote:
What other utility methods would have broad enough use and
applicability to go into a common java.util class?
Joe,
You've asked for a call for ideas, but not given any indication of
process. Are y
Hi Joe,
I thought the point that Jason Mehrens was making was that this:
+public static String toString(Object o) {
+String.valueOf(o);
+}
is actually pointless. Why introduce such redundancy when people can
just use String.valueOf directly ? This doesn't provide any benefit.
I suppose if the array is small enough, it is better to use simple Quicksort.
And the larger the array, the more sense it makes to use more pivots, because
the calculation cost of comparing against many pivots becomes more affordable
than iterating for a larger subset.
So you think the optimal n
David Holmes - Sun Microsystems wrote:
Hi Joe,
I thought the point that Jason Mehrens was making was that this:
+public static String toString(Object o) {
+String.valueOf(o); hat Jason Mehrens was making was that this:
+public static String toString(Object o) {
+String.
On 10/06/2009 06:43 PM, Joe Darcy wrote:
David Holmes - Sun Microsystems wrote:
Hi Joe,
I thought the point that Jason Mehrens was making was that this:
+ public static String toString(Object o) {
+ String.valueOf(o); hat Jason Mehrens was making was that this:
+ public static String toString
Logger has the utility method severe, warning etc so you can use the
various log levels without using the longer log method...
I'd like some more overloadings, for adding a throwable, besides a
string for those methods.
Logger.getLogger(getClass().getName()).severe(string, throwable);
Joe,
Joe Darcy said the following on 10/07/09 09:43:
David Holmes - Sun Microsystems wrote:
I thought the point that Jason Mehrens was making was that this:
+public static String toString(Object o) {
+String.valueOf(o); hat Jason Mehrens was making was that this:
+public stati
I also vote against Objects.toString().
Foo.valueOf might not be the best name,
(I'll resist the urge to suggest a better one)
but it is an entrenched convention,
and so cannot be considered a wart to be fixed.
Martin
On Tue, Oct 6, 2009 at 20:14, David Holmes - Sun Microsystems
wrote:
> Joe,
>
If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:
http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html
My biggest complaint about String.valueOf(Object) is that it will
actually return "null" for null objects. I c
Paul,
Paul Benedict said the following on 10/07/09 14:44:
If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:
http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html
My biggest complaint about String.valueOf(Object)
Thanks Dave. You are exactly right. That implementation is better.
On Tue, Oct 6, 2009 at 11:56 PM, David Holmes - Sun Microsystems
wrote:
> Paul,
>
> Paul Benedict said the following on 10/07/09 14:44:
>>
>> If you want Objects.toString() to provide value, consider mimicking
>> the functionality
On Tue, Oct 6, 2009 at 09:40, Paulo Levi wrote:
> I thought there was the danger of deadlocks if the std.out and std.err
> wasn't drained?
Well, yes, there is a danger of deadlocks, but this can be avoided by:
- having separate threads read stdout and stderr
- closing the various streams in the p
20 matches
Mail list logo
