headers
Eijiro Sumii | 1 Oct 2006 03:18
Picon

Java generics unsoundness?

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

Dear all,

Hiromasa Kido, an undergraduate student in the University of Tokyo,
has found the problem below in the implementation of generics in Java.
 Another student, Kouta Mizushima, in Tsukuba University, reported
that it also reproduces in Eclipse (which has its own compiler).

----------------------------------------------------------------------
C:\WINDOWS\Temp>c:\progra~1\java\jdk1.6.0\bin\java -version
java version "1.6.0-rc"
Java(TM) SE Runtime Environment (build 1.6.0-rc-b100)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b100, mixed mode, sharing)

C:\WINDOWS\Temp>type B.java
class A{
       public int compareTo(Object o){
               return 0;
       }
}

class B extends A implements Comparable<B>{
       public int compareTo(B b){
               return 0;
       }

       public static void main(String[] argv){
               System.out.println(new B().compareTo(new Object()));
       }
(Continue reading)

Permalink | Reply | 6 comments |
headers
Eijiro Sumii | 1 Oct 2006 08:12
Picon

Re: Java generics unsoundness?

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

P.S.

On 10/1/06, Eijiro Sumii <eijiro.sumii@...> wrote:
> (unless we modify the present JVM).  In my understading, such
> overriding as above is not forbidden in the current language
  ^^^^^^^^^^
I meant "overloading."  Sorry.

> specification (page 227 and page 478 perhaps).
Permalink | Reply | 0 comments |
headers
Erik Ernst | 1 Oct 2006 23:08
Picon
Picon
Favicon

Re: Java generics unsoundness?

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

Dear Eijiro Sumii and all others,

not pretending to be the world authority on this issue, the following 
does seem to apply:

  - JLS mentions type erasure (4.6) so this would be part of the 
language, but it is not an inherent property of type erasure that 
these method name clashes arise.

  - JLS does not mention bridge methods as far as I know, so 
presumably it should be possible to implement them in a different way 
without violating the language def.  To avoid the method clash we 
could use name mangling, i.e., including the types of the type-erased 
arguments in the name of the method (as well as $ or similar, to 
avoid clashes with user-defined names).  Call sites would be compiled 
in a context where the argument types are known, so they could easily 
use the correct (mangled) name.

All in all, this seems to be a bug in the implementation.

Of course it is not that easy in practice, e.g., because 
existing .class files would then break en masse...

On Sunday 01 October 2006 03:18, Eijiro Sumii wrote:
> [..]
> 
> Dear all,
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pete Kirkham | 2 Oct 2006 21:39
Picon
Gravatar

Re: Java generics unsoundness?

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

The section on override-equivalent signatures,
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.2>,
indicates the effect is intentional - the erasure of B#compareTo(B)
overrides A#compareTo(Object) as well as Comparable<T>#compareTo(T)
since B#compareTo(B)  is override equivalent to A#compareTo(Object) by
erasure.

Since B's method does override A's method, but takes a takes a B, the
object undergoes assignment conversion
<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.2
>, and being incompatible, a ClassCastException is thrown. This is
achieved via the bridging method.

So I don't believe it's a bug in the compilers, but rather one of
several design features of a Java generics that are intended to help
backwards compatibility. In this case the non-generic version of B
would have been:

class B extends A implements Comparable {
      public int compareTo(Object o){
              B b = (B)o;
              // it's part of the contract of Comparable to throw CCE
if presented
              // with the wrong type
              return 0;
      }
}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Ernst | 3 Oct 2006 00:13
Picon
Picon
Favicon

Re: Java generics unsoundness?

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

On Monday 02 October 2006 21:39, Pete Kirkham wrote:
> [..]
> The section on override-equivalent signatures,
><http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.2>,
> indicates the effect is intentional - the erasure of B#compareTo(B)
> overrides A#compareTo(Object) as well as Comparable<T>#compareTo(T)
> since B#compareTo(B)  is override equivalent to A#compareTo(Object) 
> by 
> erasure.

True, it is intentional that a generified version of a method should 
be able to be overriden by an erased version, such that people can 
continue to use old code with new, generified libraries.  So dispatch 
does at times select the most specific method implementation from a 
set of methods with different (though override-equivalent) 
signatures:  In 8.4.2 the set is '<T> toList(Collection<T>)' in 
CollectionConverter and 'toList(Collection)' in Overrider, and the 
latter overrides the former.

But 'compareTo(Object)' in A and 'compareTo(B)' in B are not 
override-equivalent (B is a class, not a type variable), so 
override-equivalence does not allow these methods to override each 
other, only overloading may occur.

So far it looks like a bug in the implementation that they end up 
overriding each other, caused by the use of bridge methods.

Now the interesting point is that the crucial bridge method is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eijiro Sumii | 3 Oct 2006 14:03
Picon

Re: Java generics unsoundness?

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

Dear all,

Thank you for all the replies!  Let me try to address one source of
confusion: as far as I understand according to

  http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.6

the erasure of "int compareTo(B)" is itself, not "int
compareTo(Object)", because B is a class, not a type variable - is
this correct?  (Sorry if my terminology is not accurate - I have never
read the Java Language Specification before this.)

Thanks again,

        Eijiro
Permalink | Reply | 0 comments |
headers
Eugene Vigdorchik | 3 Oct 2006 17:01
Favicon

Re: Java generics unsoundness?

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

 Hello, Ejiro,

As far as I can tell (I'm working on IntelliJ IDEA, and we have our own type system implementation) the
compiler is wrong here.
Though bridge methods are not mentioned explicitly in JLS, certain restrictions are imposed by language
specification due to their
existance. The code you provide should be rejected because of JLS section 8.4.8.3 stating it is an error to
have two inherited
methods (A.compareTo and Comparable.compareTo)  with same erasure that do not override each other.

Hope this helps,
Eugene.

> -----Original Message-----
> From: types-list-bounces@... 
> [mailto:types-list-bounces@...] On Behalf Of 
> Eijiro Sumii
> Sent: Sunday, October 01, 2006 5:19 AM
> To: types@...
> Cc: Eijiro Sumii
> Subject: [TYPES] Java generics unsoundness?
> 
> [ The Types Forum, 
> http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
> 
> Dear all,
> 
> Hiromasa Kido, an undergraduate student in the University of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Atsushi Igarashi | 3 Oct 2006 17:11
Picon
Picon
Favicon

Re: Java generics unsoundness?

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

Dear all,

I'm not 100% sure but, as far as I understand, compilers should reject
this program according to JLS.

Here is my understanding:

On p.227, there is a description saying:

  It is a compile time error if a type declaration T has a member
  method m1 and there exists a method m2 declared in T or a supertype
  of T such that all of the following conditions hold:

  - m1 and m2 have the same name.
  - m2 is accessible from T.
  - The signature of m1 is not a subsignature (ยง8.4.2) of the
    signature of m2.
  - m1 or some method m1 overrides (directly or indirectly) has the
    same erasure as m2 or some method m2 overrides (directly or
    indirectly).

In this case, T is B,
 m1 is public int compareTo(B b) {...} (declared in B), and
 m2 is public int compareTo(Object o) {...} (declared in A).

Then,

1. a type declaration T (=B) has a member method m1.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Hutton | 9 Oct 2006 11:40
Picon

ICFP 2007 Call for Workshop Proposals

[ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]

----------------------------------------------------------------------

		     CALL FOR WORKSHOP PROPOSALS

	    ICFP 2007, the 12th ACM SIGPLAN International
		 Conference on Functional Programming

		 1-3 October 2007, Freiburg, Germany

The   12th  ACM   SIGPLAN  International   Conference   on  Functional
Programming (ICFP 2007) will be  held in Freiburg, Germany from 1st to
3rd  October  2007.   ICFP   provides  a  forum  for  researchers  and
developers   to  hear   about   the  latest   work   on  the   design,
implementations, principles, and uses of functional programming.

Proposals are  invited for workshops  to be affiliated with  ICFP 2007
and sponsored by SIGPLAN.  These workshops should be more informal and
focused  than ICFP  itself, include  sessions that  enable interaction
among the workshop attendees, and  be fairly low cost.  The preference
is for one-day workshops, but  other schedules can also be considered.
The workshops themselves will be  held on 30th September, 4th October,
and 5th October 2007.

SUBMISSION DETAILS

   Deadline for submission:     17th November 2006 
   Notification of acceptance:  15th December 2006
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nguyen Manh Tho | 9 Oct 2006 19:00
Picon

[TYPES/announce] ARES 2007: Paper Submission System is ready - Submission Deadline 19-11-2006

[ The Types Forum (announcements only), 
     http://lists.seas.upenn.edu/mailman/listinfo/types-announce ]

Apologies for multiple copies due to cross postings. Please send to interested colleagues and students.

                          Call for Papers
+-------------------------------------------------------------------+
| The Second International Conference on Availability, Reliability and Security (AReS)
| ARES 2007 - "The International Security and Dependability Conference"

                    April 10th – April 13th,2007          
             Vienna University of Technology, Austria

                      http://www.ares-conf.org
                    http://www.ares-conference.eu
+-------------------------------------------------------------------+


Conference
-----------
The 1st International Conference on Availability, Reliability and Security conference (ARES 2006)
has been successfully organized in Vienna, AUSTRIA from April 20 to April 22, 2006 by the Technical
University of Vienna in cooperation with the European Network and Security Agency (ENISA). We have
attracted 250 participants for this conference with its 3 keynotes speakers and its 9 workshops held
in conjunction with.

In continuation of the successful 1st ARES conference, The Second (Continue reading)

Permalink | Reply | 0 comments |

Gmane