John, how about multi-language java.lang.Class or java.lang.reflect.Field?
S.
On Fri, Oct 9, 2009 at 19:12, John Rose wrote:
> Thanks, Ben; well said. Putting a multi-language JVM feature under
> java.lang would be the wrong signal. OTOH, if we ever do a type
> "Dynamic" in the Java language
On Oct 9, 2009, at 7:36 PM, Stepan Koltsov wrote:
John, how about multi-language java.lang.Class or
java.lang.reflect.Field?
How about it? I don't know how to answer this. -- John
Thank you, Bob. I stand corrected.
On Fri, Oct 9, 2009 at 9:07 PM, Bob Lee wrote:
> On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict wrote:
>>
>> Understood, but the keyword (pun) here is "effectively". Why let a
>> developer wait until runtime to find out his code will fail? At least
>> by marking
On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict wrote:
> Understood, but the keyword (pun) here is "effectively". Why let a
> developer wait until runtime to find out his code will fail? At least
> by marking the class as final, anybody who wishes to subclass it will
> receive a compiler error. Rai
Joe,
> Classes with only private constructors, like j.u.Objects, are effectively
> final. Adding final is harmless but unnecessary in these cases.
Understood, but the keyword (pun) here is "effectively". Why let a
developer wait until runtime to find out his code will fail? At least
by marking t
Paul Benedict wrote:
Joe,
I think java.util.Objects could benefit from the "final" modifier.
Since its constructor always fails, there is no reason to subclass it
(i.e., super constructor always fails). I believe Josh's "Effective
Java" book makes such a point about static utility classes.
Paul
Joe,
I think java.util.Objects could benefit from the "final" modifier.
Since its constructor always fails, there is no reason to subclass it
(i.e., super constructor always fails). I believe Josh's "Effective
Java" book makes such a point about static utility classes.
Paul
Generally speaking, lower levels in the system shouldn't refer to higher
levels. In this case it's just a comment, but it isn't clear that every
profile that includes Enum will include the collections framework. I'm
thinking, for example, about ME profiles.
-Neal
On Fri, Oct 9, 2009 at 4:13 PM,
Changeset: 3b45b809d8ff
Author:darcy
Date: 2009-10-09 16:11 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b45b809d8ff
6797535: Add shared two argument static equals method to the platform
Reviewed-by: sherman
! make/java/java/FILES_java.gmk
+ src/share/classes/java/util/Ob
Neal Gafter wrote:
Do EnumSet and EnumMap exist on all platform profiles?
They exist on JDK 7 where this change is intended.
-Joe
On Fri, Oct 9, 2009 at 11:43 AM, Joseph D. Darcy wrote:
Please review this tiny doc fix to make EnumSet and EnumMap just a bit
easier to find; patch below
-Joe
I don't think method really pays for itself. If it belongs anywhere, it
belongs in java.util.Arrays.
Josh
I would name it javax.dyn.
-Ulf
Am 04.10.2009 06:43, Paul Benedict schrieb:
I've always found it a bit perplexing that java.lang was never chosen
for the parent package of the Dynamic API. Why is that? Dynamic types
are now "part of the language" as proven by spec itself and exotic
identifiers
Joe, much thank for your explanation. :-)
-Ulf
Am 09.10.2009 20:46, Joseph D. Darcy schrieb:
Ulf Zibis wrote:
Am 08.10.2009 20:34, Joseph D. Darcy schrieb:
Hello.
In the discussion about java.util.Objects, a few existing JDK
methods were mentioned for possible var-argification:
java.util
Eamonn McManus wrote:
David Holmes - Sun Microsystems wrote:
> So to me: String toString(Object o, String useIfNull) is the only
method
> that provides true utility in this case.
I agree with that, and would just suggest to the person specifying the
method
to add a @see String#valueOf(Object)
Do EnumSet and EnumMap exist on all platform profiles?
On Fri, Oct 9, 2009 at 11:43 AM, Joseph D. Darcy wrote:
> Please review this tiny doc fix to make EnumSet and EnumMap just a bit
> easier to find; patch below
>
> -Joe
>
> --- old/src/share/classes/java/lang/Enum.java 2009-10-09
> 11:41:23
Please review this tiny doc fix to make EnumSet and EnumMap just a bit
easier to find; patch below
-Joe
--- old/src/share/classes/java/lang/Enum.java2009-10-09
11:41:23.0 -0700
+++ new/src/share/classes/java/lang/Enum.java2009-10-09
11:41:23.0 -0700
@@ -44,6 +44,8 @@
Hello.
Please review this simple specification clarification (with accompanying
test) for
6648344: (reflect spec) State default of isAccessible for reflective objects
-Joe
--- old/src/share/classes/java/lang/reflect/AccessibleObject.java
2009-10-09 14:48:35.0 -0700
+++ new/src/sha
Eamonn McManus wrote:
Joseph D. Darcy wrote:
> What are scenarios where this method would be used?
I use a similar method fairly often in unit tests. JUnit's
assertEquals doesn't
do the right thing if its arguments happen to be arrays, so I use the
following
simple if inefficient implementat
Ulf Zibis wrote:
Am 08.10.2009 20:34, Joseph D. Darcy schrieb:
Hello.
In the discussion about java.util.Objects, a few existing JDK methods
were mentioned for possible var-argification:
java.util.Arrays.hashCode(Object[] a)
java.util.Arrays.deepHashCode(Object[] a)
java.util.Arrays.toString(
Joe,
I'm not sure I like this idea. My one experience with forcing an array
method to do double duty as varargs method was a disaster. The method was
Arrays.asList, and the result was Puzzler # 7 from "The Continuing
Adventures of Java™Puzzlers: Tiger Traps." Here it is:
*7. “Fib O’Nacci”*
pu
Joe wrote:
> Another piece of functionality requested in the j.u.Objects
> thread was a
> deepEquals(Object a, Object b.) method that "did the right
> thing" if the
> arguments happened to dynamically be arrays.
>
> I've been thinking a bit how this might be implemented.
>
> The array-ness of
For the background on my reasoning, the popular shift towards dynamic
languages makes me wonder how far off a C#-like dynamic feature is for
Java too. I hedge my bet that it will eventually happen -- years upon
years away -- when more serious use cases are found. Thus, to prevent
the case of split
Thanks, Ben; well said. Putting a multi-language JVM feature under
java.lang would be the wrong signal. OTOH, if we ever do a type
"Dynamic" in the Java language (a la C#) that would belong in
java.lang. But we are not, at present. (Despite an earlier blog
proposal of mine!) JVM change
Hi,
Some suggestions:
1) Any equals*(a, b) methods should support a==null && b==null returning
true, only a==null returning -1, and only b==null returning +1. This is very
useful for much the same reasons that it's useful in SQL (although the exact
ordering of null/non-null is debatable - SQL def
2009/10/9 Eamonn McManus :
>> The spec, you mention, refers to the instance method equals(), but here
>> we are talking about static helpers.
>
> The difference between Marek's suggestion and Joe's is what happens when
> the equals(Object) method of a or b returns true for a null argument, and
> th
> Don't you know about assertArrayEquals() in JUnit ? It's in version 4.5.
I can use that if I know the values are arrays. The sort of case I'm thinking
of is a data-driven test where I have a big array with a lot of inputs and
the corresponding expected outputs, some but not all of which might
Am 09.10.2009 11:36, Eamonn McManus schrieb:
> The spec, you mention, refers to the instance method equals(), but here
> we are talking about static helpers.
The difference between Marek's suggestion and Joe's is what happens when
the equals(Object) method of a or b returns true for a null argum
> The spec, you mention, refers to the instance method equals(), but here
> we are talking about static helpers.
The difference between Marek's suggestion and Joe's is what happens when
the equals(Object) method of a or b returns true for a null argument, and
that is what I was saying violates th
Am 09.10.2009 11:30, Eamonn McManus schrieb:
Joseph D. Darcy wrote:
> What are scenarios where this method would be used?
I use a similar method fairly often in unit tests. JUnit's
assertEquals doesn't
do the right thing if its arguments happen to be arrays, so I use the
following
simple if
Am 09.10.2009 10:56, Eamonn McManus schrieb:
Hi,
Marek Kozieł wrote:
>> +public static boolean equals(Object a, Object b) {
>> +return (a == b) || (a != null && a.equals(b));
>> +}
>
> Hello,
> I would suggest other implementation of equals method:
>
> public static boolean e
Joseph D. Darcy wrote:
> What are scenarios where this method would be used?
I use a similar method fairly often in unit tests. JUnit's assertEquals doesn't
do the right thing if its arguments happen to be arrays, so I use the following
simple if inefficient implementation:
static void deepEqua
David Holmes - Sun Microsystems wrote:
> So to me: String toString(Object o, String useIfNull) is the only method
> that provides true utility in this case.
I agree with that, and would just suggest to the person specifying the method
to add a @see String#valueOf(Object). I find that the behavio
Hi,
Marek Kozieł wrote:
>> +public static boolean equals(Object a, Object b) {
>> +return (a == b) || (a != null && a.equals(b));
>> +}
>
> Hello,
> I would suggest other implementation of equals method:
>
>public static boolean equals(Object a, Object b) {
>if (a
Am 08.10.2009 21:12, Joseph D. Darcy schrieb:
I think I could be convinced that a reflection-based toDebugString was
useful enough to include in the platform. However, someone would have
to contribute the specification and a robust implementation.
I more tend to prefer a separate class, cal
Am 08.10.2009 20:34, Joseph D. Darcy schrieb:
Hello.
In the discussion about java.util.Objects, a few existing JDK methods
were mentioned for possible var-argification:
java.util.Arrays.hashCode(Object[] a)
java.util.Arrays.deepHashCode(Object[] a)
java.util.Arrays.toString(Object[] a)
Also
Am 09.10.2009 01:53, David Holmes - Sun Microsystems schrieb:
So to me: String toString(Object o, String useIfNull) is the only
method that provides true utility in this case.
I can follow this argumentation.
+1
-Ulf
2009/10/8 Joseph D. Darcy :
> Hello.
>
> Please code review the first-round of java.util.Objects; the patch is below:
> http://cr.openjdk.java.net/~darcy/6797535.0/
>
> -Joe
>
> --- old/make/java/java/FILES_java.gmk 2009-10-08 11:04:03.0 -0700
> +++ new/make/java/java/FILES_java.gmk 200
37 matches
Mail list logo
