Not wishing to confuse the debate, but perhaps the correct place for
this is a static Strings class, that parallels Objects.
We all know that there are lots of possible methods for such a class,
but even if JDK7 had just a few, that would be a good start.
Joe, would you be prepared to sponsor a
This isn't one I've seen much use for.
It would also be possible to write it as a decorating wrapper for a
map, rather than as a static utility method.
Stephen
2009/10/25 assembling signals assembling.sign...@yandex.ru:
Hello!
I am thinking about a new method getSafe(...) for the
Am 26.10.2009 14:01, Stephen Colebourne schrieb:
Not wishing to confuse the debate, but perhaps the correct place for
this is a static Strings class, that parallels Objects.
-1
Doing this consequently we could have for each normal class
'ClassName' it's static helper class 'ClassNames',
Le 26/10/2009 15:56, Paul Benedict a écrit :
Since we're talking Map, I think a more utility would be gained by
including putIfAbsent (see java.util.concurrent) because I see many
lines of code that do that idiom all the time.
This idiom is especially prevalent when the value is itself a nested
I actually don't need closures to accomplish this. Now this solution I
wouldn't recommend for the JDK, but a subclass of Map could
automatically do the management of the inner collections for me.
Paul
Hi Paul,
Paul Benedict wrote:
Since we're talking Map, I think a more utility would be gained by
including putIfAbsent (see java.util.concurrent) because I see many
lines of code that do that idiom all the time.
This idiom is especially prevalent when the value is itself a nested collection.
Stephen Colebourne wrote:
Not wishing to confuse the debate, but perhaps the correct place for
this is a static Strings class, that parallels Objects.
We all know that there are lots of possible methods for such a class,
but even if JDK7 had just a few, that would be a good start.
Joe, would
Joseph D. Darcy wrote:
Stephen Colebourne wrote:
Joe, would you be prepared to sponsor a Strings class, and see join on
there instead of String?
No.
+1.
It was necessary to introduce Arrays and Collections for utility methods
because there was no place else to locate the static
Am 09.09.2009 22:40, Joe Darcy schrieb:
Hello.
For JDK 7, I think it is high-time the platform included a class like
java.util.Objects to hold commonly-written utility methods. For
example, a two-argument static equals method that returned true if
both arguments are null, returns false is
You can hardly add any methods to Object, event static methods, without
breaking compatibility, because they get added to every the overload set if
the name is used for methods in existing code.
On Mon, Oct 26, 2009 at 9:29 AM, David Holmes david.hol...@sun.com wrote:
Joseph D. Darcy wrote:
Joseph D. Darcy wrote:
Neal Gafter wrote:
You can hardly add any methods to Object, event static methods,
without breaking compatibility, because they get added to every the
overload set if the name is used for methods in existing code.
Indeed, which is why these methods were added in a new
Fixed 6895456: Eliminate dependency on java.io.ObjectStreamClass during boot
Webrev at:
http://cr.openjdk.java.net/~mchung/6895456/webrev.00/
java.io.ObjectStreamClass is not needed if not doing serialization.
Move getSignatureClass static method to java.io.ObjectStreamField
class.
12 matches
Mail list logo
