Defender methods and compatibility

[Brian Goetz]

> While I do
> believe that Oracle would have less schedule risk in the absence of the
> discussions on this list, I also believe that these discussions have the
> potential to improve the language design

These discussions certainly do have the *potential* to improve the language 
design (which is why we're doing this at all -- its certainly not the most 
resource-efficient approach!).  And in many cases, they have, and we 
appreciate that.

But they also have the potential for evil as well as good.  In some cases, 
they have simply been a huge distraction and a waste of time for no benefit, 
such as last week's discussion over mutable local variables, when the issue 
had already been extensively explored, considered, and rejected for the 
current round, and the discussion amounted to "I would like it better if."  I 
would say the entire community was a loser for that; it distracted us for 
nearly a week.  That's a week closer to not delivering anything into Java 8. 
Our runway is far from infinite and there's a lot of work to do.

> Of course these risks do need to be balanced against each other, as spending
> infinite resources on design ensures that users never see any language
> change.  Oracle does not have a well established history of collaborative
> engineering in this kind of forum, where such risks can be balanced by the
> participants, but we can hope that this forum provides an opportunity for change.

This collaborative approach is an experiment on our part towards greater 
community engagement.  If the community cannot meet us halfway by showing some 
restraint (for example, by recognizing when it has ratholed and backing off), 
it will be a failed experiment, for which we will all be losers.