Is this valid java ?

Eclipse 3.5 says yes
Eclipse 3.6 says no
Intellij 9 says yes
sun javac 1.6.0_20 says yes
gcj 4.4.3 says yes
gwt compiler says yes
People at http://stackoverflow.com/questions/3105177/why-is-one-class-valid-while-the-other-is-not say no

If you make the overloaded functions return void, it stops working everywhere.

class TestValid {

    public static String f(List<String> list) {
        System.out.println("strings");
        return null;
    }

    public static Integer f(List<Integer> list) {
        System.out.println("numbers");
        return null;
    }


    public static void main(String[] args) {
        f(Arrays.asList("asdf"));
        f(Arrays.asList(123));
    }

}

7 comments
Comment actions Permalink

On 6/24/2010 1:24 AM, lacroix1547 wrote:

Eclipse 3.5 says yes
Eclipse 3.6 says no
Intellij 9 says yes
sun javac 1.6.0_20 says yes
gwt compiler says yes
People at http://stackoverflow.com/questions/3105177/why-is-one-class-valid-while-the-other-is-not say no
Theory says no
And I just dont known!!!

Java 1.5.0_11 also says it is valid, so I would say it is valid.


0
Comment actions Permalink

valid. the type info is not available at runtime, but the return type is different, so both methods can be distinguished from each other at runtime. if the return type is void, there is no difference. a similar problem is
void a(String x)
void a(Integer x)

call: a(null) -> compiler has no idea which method is supposed to be called
call: a((String)null) -> works

just at compiler level

0
Comment actions Permalink

No, the return type is not a factor in determining a method's signature.
Read the JLS, section 8.4.2 (http://java.sun.com/docs/books/jls/third_edition/html/classes.html#38649).

Also note that the type info IS available at runtime.

I think the example is valid, it's Eclipse 3.6 that's wrong. I say that because,
in the link I gave above, the following statement appears:

The signature of a method m1 is a subsignature of the signature of a method
m2 if either
   

  • m2 has the same signature as m1, or

   

  • the signature of m1 is the same as the erasure of the signature of m2.


Note that they're only talking about the erasure of ONE of the methods (because
this allows generics to coexist with pre-generics code). The code would only
be invalid if they'd said "the erasure of the signature of m1 is the same
as the erasure of the signature of m2".

Well, that's my take on it anyway...

Chris

valid. the type info is not available at runtime, but the return type
is different, so both methods can be distinguished from each other at
runtime. if the return type is void, there is no difference. a similar
problem is

void a(String x)

void a(Integer x)

call: a(null) -> compiler has no idea which method is supposed to be
called call: a((String)null) -> works

just at compiler level



0
Comment actions Permalink
Also note that the type info IS available at runtime


i meant the generic type

0
Comment actions Permalink

So did I. Try the code below. However, I now see the dilemma and it's not
clear to me whether that code is spec compliant or not :/

import java.lang.reflect.Method;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
import java.util.List;
import java.util.Map;

public class GenericsTest
{
  public static void main(String[] args) throws Exception
  {
    for (Method method : GenericsTest.class.getMethods()) {
      if (method.getDeclaringClass() != GenericsTest.class) {
        continue;
      }
      StringBuilder buf = new StringBuilder(100);
      buf.append("Found method: ");
      buf.append(getName(method.getGenericReturnType())).append(' ');
      buf.append(method.getName());
      buf.append('(');
      Type[] types = method.getGenericParameterTypes();
      for (int i = 0; i ');
      return buf.toString();
    }
    return type.toString();
  }
}

Also note that the type
> info IS available at runtime
>

i meant the generic type
---
Original message URL:
http://devnet.jetbrains.net/message/5266339#5266339



0
Comment actions Permalink

Take a look at these two bugs for more info,

http://bugs.sun.com/view_bug.do?bug_id=6182950
http://bugs.sun.com/view_bug.do?bug_id=6730568

But, based on my experience, it really dpends on the version of the JDK, like 1.5.16 would compile this, but 1.5.17 wouldn't. It even appears to flip-flop with 1.6.x too.

0

Please sign in to leave a comment.