New draft of Defender Methods

I've posted a new draft of the interface evolution document here
Comments:

Boo, PDF. ;)

Posted by Justin Lee on August 16, 2010 at 07:04 AM PDT #

Is there any reason that default implementation can't be defined right on the interface? I know it moves us in the direction of traits, but I don't necessarily think that's a bad idea either.

Posted by Justin Lee on August 16, 2010 at 07:44 AM PDT #

It would be grate if you could add a method to an interface that you don't own the source code for.

E.g. The Set interface is owned by one organization, and another organization wants to add the reduce method to the Set interface (for one of their projects)

Posted by Kaj Bjurman on August 16, 2010 at 04:56 PM PDT #

Currently:
public interface I1 { void m(); }
public interface I2 { void m(); }
public class C implements I1,I2 {
public void m() { ... }
}

No problem.

With the proposal:
public interface I1 { void m() default Collections.m; }
public interface I2 { void m() default Arrays.m; }
public class C implements I1,I2 { ... }

Now what?

Posted by Peter Koves on August 18, 2010 at 03:08 AM PDT #

OK, so I didn't properly read 3.1, sorry. However I think a compile time error would be preferable. In fact I think the default used should be "fixed" at the time of compilation of the interface implementor class. This is more in line with the idea that implementation is a class concern---the default provided by the interface is a shortcut alternative to actually providing that implementation.

Further question. What if I1 provides a default for m() but I2 does not? In principle there could be two interpretations:
(a) C must implement m() because this is required by the traditional view of I2
(b) The default for m() is taken from I1.

Posted by Peter Koves on August 18, 2010 at 03:31 AM PDT #

Defender Methods is a great idea. Would there be a way to add an interface to an existing class? One thing I have always wanted is the ability to add methods to the String class. Since it is final, it isn't even practical to subclass. But if it were possible to add defender methods to the existing class, then Apache Commons StringUtils could be integrated.

If nothing else, perhaps it could be allowed to subclass a final class as long as it is just to add defender methods.

Posted by Bob Thule on August 20, 2010 at 12:37 AM PDT #

Interesting.

What about distributed computing?

Lets say a local jvm is communicating with a remote jvm using RMI, they have different versions of a jar, containing the needed classes loaded in each jvm.

Let's say the local jvm contains the interface with the additional method, the remote jvm doesn't.

If the object serial form is compatible, an object that implements an earlier version of the interface will lack the additional method, but it would seem the default method provided for objects that don't implement it, can't modify their private state, so the objects themselves remain compatible across jvm's.

Now what about when the remote jvm has to download a jar file, containing class that implement the new method, but the remote jvm contains the earlier interface, this means that the method binary signature will be present in the downloaded code, but is not an interface method in the remote jvm.

What happens when the downloaded code uses the new method call on object instances implementing the interface, that have the binary signature but the interface itself technically doesn't and not class cast has been performed?

Assume the local and remote jvm's are the same Java platform version.

Posted by Peter on November 20, 2010 at 12:29 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Brian Goetz is Java Language Architect at Oracle Corporation.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today