Re: [ljc] Defender Methods

From: Tom H.
Sent on: Wednesday, August 8, 2012 6:07 PM
On 08/08/2012, Russel Winder <[address removed]> wrote:

> Duly answered. One question though: Why have them at all? Java has
> abstract classes which can be used as types. Interfaces with default
> methods appears to implement the same idea.  Introducing a second way of
> achieving a goal sounds very Perlesque.

Java `interface` has become a popular feature because they express
they idea of a type with guaranteed no implementation (beyond jlo).

The unfortunate part comes because it is inevitable that you'll want
to add methods to some successful interfaces. Switching to an abstract
class causes almost complete binary incompatibility issues and some
minor source issues (and naming issues if you use *that* convention).
JDBC adds methods to interfaces but has been called "special", and
other less kind things.

The particular issue comes with ("new") Java collections. This is
despite claims that complete upfront design is great for APIs.  From

  1.2 - introduced (does have Collections static utils)
  1.3 - no problem
  1.4 - necessary to introduce separate concurrent interfaces
  1.5 - SimpleIterator has to be scraped; posh for loops require a
mutable interface
  1.6 - NavigableMap introduced to enhance SortedMap (and Sets)
  1.7 - no problems that I can remember at the moment
  1.8 /1.9 - want to add support for use under the Fork-Join framework

You probably aren't going to use FJ on, say, some random List returned
by some random library, so it's not strictly speaking necessary
introduce these 1.8 methods directly into the collection interfaces.
If you replaced, say, `private final List...` with `private final
ArrayList...` that would be sufficient. Perhaps introduce a new
tersely-named, (initially pure) abstract class to correct the library
flaw, `private final Ls...`. Instead it has been decided "co-evolve"*
language & library by adding implementation to Java `interface`.

(Brian has asked for positioning of default not to be openly discussed
whilst the vote is live. I think it would have been wise to discuss it
beforehand, because I've changed my mind.)


*Not evolution as in natural selection.

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference, in collaboration with the LJC 12/13 Jun 14

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Packt Publishing

    A publishing company specializing on specific technologies and solutions

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy