Default Interfaces: possible Java extension?

[Tom McGlynn]

That is not a very descriptive summary.

I think it is more accurate to say that almost everybody considered
it a very bad idea and that there were several issues mentioned, which
could not be addressed.

I tried to note the lack of support in what I intended as a wry
comment that we weren't going to be seeing this in the next release in
Java. Perhaps that was too elliptical. I did not see any concerns
raised regarding the <feasibility> of this other than the one I
mentioned. What did I miss?

Regards,
Tom McGlynn

 

[Markus Eberle]

Hi,

Am 12.02.2011 03:20, schrieb Tom McGlynn:

Add a new optional element in the definition of an interface which
defines a class that does the default implementation of the
interface. E.g.,

interface List<T> default ArrayList<T> { ...}

An interface which has a default may be used in a constructor as:

List<String> name = new List<String>();

When this happens, the default class for the interface is substituted
at compilation time. If there is no default, or it is not accessible
then this is a compile time error.

In my opinion the problem with that solution will be, that I cannot
decide what the default implementation of an interface is, but the
original creator.
If I now want to have the default implementation to be a LinkedList,
then I cannot change it, as Oracle/Sun decided once, that it should be
ArrayList.
Okay, you say, then leave it like it is now, and do "new LinkedList()"
everywhere you want a new list.
Fine, but then I have different implementations of my lists, although
there would be a feature to have the same everywhere.

What you need would be a possibility to overwrite the default
implementation, but what happens if someone else (a jar) also wants to
overwrite the default?

Best regards,
Markus

 

[Arne Vajhøj]

I tried to note the lack of support in what I intended as a wry
comment that we weren't going to be seeing this in the next release in
Java. Perhaps that was too elliptical. I did not see any concerns
raised regarding the<feasibility> of this other than the one I
mentioned. What did I miss?

It assume one implementation when the interface is created.

The relationship between interface and default implementation
will always either by circular or type unsafe.

Arne

 

[Tom McGlynn]

It assume one implementation when the interface is created.

Well it defines a default. You may or may not like the idea, but I
don't see how it affects the feasibility of it. Typically if one were
developing a framework using this idea, I'd imagine one would
originally define the base interfaces without a default and then as
the framework matured (but prior to release) defaults would be
chosen. In what way does this make the idea unfeasible?

The relationship between interface and default implementation
will always either by circular or type unsafe.

This issue of circularity of reference was brought up earlier and I
agreed above that it was one technical issue that an implementation of
this idea would need to be careful about. I don't see how type safety
enters into things. I.e., at compile time both the interface and the
default implementation need to be available so that the compiler can
check that the default implements the interface. At run time, as
discussed upthread, it looks perfectly feasible to have an
implementation which only requires loading the default implementing
class only when that class is used (either explicitly or though a
default constructor).

So, if List had a default of ArrayList, and one had a statement
List<X> obj = new TreeList<X>();
then the ArrayList class need not be loaded. Could you clarify where
you see a type safety issue or where a dangerous circular dependency
arises?


Regards,
Tom McGlynn

 

[Tom McGlynn]

Hi,

Am 12.02.2011 03:20, schrieb Tom McGlynn:






In my opinion the problem with that solution will be, that I cannot
decide what the default implementation of an interface is, but the
original creator.
If I now want to have the default implementation to be a LinkedList,
then I cannot change it, as Oracle/Sun decided once, that it should be
ArrayList.
Okay, you say, then leave it like it is now, and do "new LinkedList()"
everywhere you want a new list.
Fine, but then I have different implementations of my lists, although
there would be a feature to have the same everywhere.

What you need would be a possibility to overwrite the default
implementation, but what happens if someone else (a jar) also wants to
overwrite the default?

This misapprehends the motivation for this enhancement. If I want to
be able to easily get lists of some default type that I know about,
it's straightforward to write a factory method that will provide them
to me.

List x = Util.getDefaultList();

I'd be concerned about an implementation that allowed the construct
List<X> = new List<X>()
to mean one thing in one program and something else in another, so I
wouldn't want to allow users to control this -- especially given they
have the alternative above.

What my suggestion would allow is for a user to say that they are not
interested in the implementation at all and they are leaving it up to
the framework designer. E.g., suppose I update some code and realize
that I'd like to use a TreeList in some location. If my current code
is
List x = new ArrayList();
then I need to think about whether I had some reason for choosing an
ArrayList which perhaps trumps my new desire to use a TreeList.
However if the code was
List x = new List();
then I know that code had previously placed no constraint on the
implementation, so I should feel free to use a TreeList now.

The goal of this enhancement is to enable users to state that any
reasonable implementation of this interface will do and they rely upon
the framework designer to produce such an implementation. Certainly
if I have specific requirements I should pick the implementation, but
I don't think it would be unusual for the person who wrote the
implementions to have good insight as to what might be a good general
purpose implementation.

Regards,
Tom McGlynn