addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-crosscrosseditemptyheartfacebookfolderfullheartglobegmailgoogleimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartrashtriangle-downtriangle-uptwitteruseryahoo

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
memory:

  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.)

Tom

*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, 8-10th June 16

  • SkillsMatter

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

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • 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.

  • Craft Rebellion

    Your choice of fresh craft beer, delivered. For 10% off use ‘LJC'

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