Doug,
On Sat, Oct 24, 2009 at 2:43 AM, Doug Lea wrote:
> Although at the end of that mail
> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-July/002168.html)
> I mentioned that there are several less dramatic
> changes to the current implementation that seem worthwhile.
> In case anyon
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. Object
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.
While I believe a "StringUtils" class would have been appropriate early
in the platform's life to host more advanced string manipulation
facil
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 c
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 class to prevent
unwante
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 wrote:
> Joseph D. Darcy wrote:
>
> Stephen Colebourne
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 on
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 methods.
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 yo
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.
M
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
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
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.
Map> map = ...
List collection = m
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',
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 :
> Hello!
>
> I am thinking about a new method getSafe(...) for the "Collections" utility
> class.
>
>
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 S
16 matches
Mail list logo
