Fw: [jsr-335-eg] Default method survey results

[Brian Goetz]

While we're clear that "the syntax for default methods should be 
different", there is still clearly some diversity of opinion on the 
finer details.  And this isn't surprising; syntax issue are highly 
subjective and therefore often fail to converge.  They are the hardest 
issues to decide because people often feel strongly and our feelings are 
usually as much emotional as logical on such issues.

The last poll had equal components "strongly for" and (less strongly) 
"against".  The community has come down with a clear "strongly for", in 
a large enough survey (> 4000 votes) from a broad enough demographic to 
be taken seriously, and that should count with some weight in our 
deliberation.  I don't want to get into a "hanging chad" debate about 
the polling methodology (i.e., should "strongly X" count equally against 
"weakly not X", "late votes don't count", "ties are broken by 
arm-wrestling", etc.)  This isn't how we've worked so far and we won't 
start now.

I think we have to be careful about leaning too hard on the "precedent" 
arguments; it's just too easy to get lost in your own perspective. 
Realistically, there is consistency and inconsistency with precedent to 
be found in both options, and this is almost always the case with syntax 
issues.  Modifier-position-supporters will cite abstract as a precedent, 
and annotation-position-supporters will cite annotations as a precedent, 
and neither are wrong.  The reality is which consistencies or 
inconsistencies we personally find more compelling are often more 
visceral than logical, and we should be up-front about that.  Java is 
full enough of inconsistencies that its almost always possible to claim 
consistency with *something*.

One confounding detail is that the positional preference and the choice 
of keyword do not seem to be as independent as we'd like them to be. 
Based on what you've said, I don't think you have a deep objection to 
the positioning per se, as much as the combination of modifier position 
+ specific "default" keyword which will dispose some users to interpret 
"default" as "default accessibility."

If there's a different keyword that would work here, I'd be OK with 
that.  We chose "default" initially because it was already a keyword and 
a "pretty good" intuitive fit, but if there's something better, let's 
have it.

One data point that may be significant here is: I've been writing Java 8 
library code nearly every day for the last four months, and I still 
haven't gotten used to the "dangling" default syntax.  We've frequently 
discussed how people's initial reactions and their long term reactions 
to syntax are often quite different.  Usually the first impression is 
excessively negative ("bleah, different is scary!") but the long-term 
impression less negative once people "get use to it" (this was certainly 
the case for many with the lambda syntax); here's one that went the 
other way.  This is a red flag for me.

The current positioning is an irritant.  The modifier positioning seems 
less of an irritant, while still sufficiently maintaining the goal of 
being different.  (Also, the current positioning suffers when you 
consider the addition of final/static methods to interfaces.)

I think the "default as modifier" is the best we've come up with *so 
far*.  I think we should keep looking, but we shouldn't let that stop us 
from taking that step in the meantime.



On 9/20/2012 12:01 PM, Daniel Heidinga wrote:
> (Apologies for the delay in responding to this issue - I'm experiencing
> email issues with new list)
>
> If we count Kevin's late vote, the survey ends in a tie. My inclination
> would be to then fall back to the result of the vote at JVM Languages
> Summit EG meeting - the 'default' keyword should be placed between the
> signature and the body.
>
> I don't want to drag this topic out too much further, but I think there
> are two pretty compelling reasons to avoid 'default' as a method modifier:
>
> 1) Users believe package access is 'default access' regardless of what
> the spec says and will be surprised that default means something else.
> Because we're introducing a lot of new concepts in this JSR, we should
> be careful to avoid perturbing user's mental models when we can. This is
> clearly a case where we can avoid the mismatch between what the user
> expects and what the new concept means.
>
> 2) Precedent matters - the annotation example is a clear precedent for
> placing 'default' between the signature and body. We've strived to
> respect precedent so far (when appropriate, of course) and the
> annotation example is a clear match to what we're trying to do.
>
> Let's run one more EG poll on this issue - a straight choice between:
> A) void foo() default { ... }
> B) default void foo() { ... }
> and let that decide the issue.
>
> --Dan
>