Final defenders

[Talden]

On Wed, Aug 8, 2012 at 10:55 PM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> On 8 August 2012 11:37, Talden <talden at gmail.com> wrote:
>> On Wed, Aug 8, 2012 at 9:49 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
>>> Where there is no doubt in my mind is that I will use traits (in
>>> whatever form they are provided) for far, far more than interface
>>> evolution when JDK8 is released.
>>
>> This paragraph stood out to me.  The wording is important.
>
> Let me reword then.
>
> A new feature is being added to JDK8 - default method implementations
> in interfaces.
> Some are trying to state that this should only be used for interface evolution.
> I am stating that I will use it for multiple-inheritance/trait-like
> behaviour, far, far more than interface evolution.
>
> More broadly, I'm saying that interface evolution is only occasionaly
> an issue I face. And yes, this new feature will be useful for
> interface evolution, but that won't be its prime use for me.
>
> Having established the above, it is clear to me that it would be far
> better to have a properly designed fuller implementation, than suffer
> from the hamstrung API designs we will see (like the "do" method
> prefix) without the fuller trait-like feature.

Thank-you, that is much clearer.  It clarifies both the intent to
misuse the feature as presented to us so far (all that means is that
you intend to use it in a way known to have unpleasant limitations or
side-effects - it's always your choice to do so) and it states your
expectation that the primary purpose of the feature is not expected to
be of substantial value to you (beyond obviously it opening the door
to better JavaSE evolution which we'll all benefit from).

I certainly sit in the other camp - I do have real cases where the
interface evolution would make it much easier to release often with
enhancements to our product public API and expect to maintain an easy
migration for our customers (who can have substantial code investments
built on the API).

>> It seemed that what you were really saying was "...that I will use
>> interface default methods to implement traits far, far more...". I say
>> that because you cannot say that you will 'use traits' when they're
>> not on offer - you can only state an intent to use the offered
>> features in an unintended way.
>
> I'm advocating that the "unintended way"/"misuse" argument will be
> ignored, and this feature will get used far beyond the original
> intent. There is nothing I can see that Oracle can do to prevent that.

Oh Oracle can't prevent it, but then I've seen many cases where
developers have completely misused the intent of a language feature
(often to their own detriment).  Oracle can also not be expected, in a
single iteration (or any number of iterations), to produce the silver
bullet of features for all developers that is completely fool-proof
(have you seen the rate at which we're breeding better fools).

At some point developers take responsibility for understanding the
limitations intended by the design.  It's the flip-side of ignoring
advice that doing X is bad, your bad experience can also be ignored
(fto an extent at least - if enough experiences are bad, ignoring them
is how you encourage your user-base to migrate to another platform).

A reality of the scarcity of resources and the need to release to see
evolution in a useful time-frame is that there will be designed in
limitations - they're either "we couldn't do it in time" or "we don't
want to close the door a better solution in a later iteration".

The trick for Oracle will be to juggle our feedback and find the
middle-ground. An unenviable, if probably enjoyably challenging,
position to be in.

--
Aaron Scott-Boddendijk