RFR(m): 8140281 deprecate Optional.get()

[Stephen Colebourne]

Better suppress warnings would be nice, and the problem statement
below is reasonable, what concerns me more is the impact on clients of
the Strata API. Strata uses Optional heavily - we have "done the right
thing" and do not return null from any public methods. As such, a
*lot* of methods return Optional. If this change happens, then
everyone who adopts Strata today and codes against our API
(legitimately using isPresent() followed by get() ) will suffer when
Java 9 is released. I don't see how a better SuppressWarnings helps
those clients.

FWIW, I will have to consider migrating to Guava Optional if I can't
rely on a core API like JDK Optional remaining stable.

<sarcasm>
I propose that we deprecate List.get(int).
To compensate, we should add a new method getButPleaseCheckListSizeFirst(int)

The rationale is that lots of developers call get(int) without
correctly checking the list size. I estimate that 69.3724% of all
developers misuse the method.
</sarcasm>

If I thought the method needed renaming, I'd go along with this. I'm
am accepting the demise of Class.newInstance() for example, although I
think even that is a very marginal deprecation. If it seems to Kevin
that get() is the right name, and others like me agree, perhaps its
worth considering whether the change is actually appropriate?

FWIW, the best example in JSR-310 of a design mistake is
TemporalAmount.get(TemporalUnit):
http://stackoverflow.com/questions/24491243/why-cant-i-get-a-duration-in-minutes-or-hours-in-java-time/24500045#24500045
Renaming that method to unitValue(TemporalUnit) or similar would
actually be a useful change (as it is a framework method and almost
all uses of that method in application code are wrong).

Stephen


On 27 April 2016 at 15:48, Brian Goetz <brian.goetz at oracle.com> wrote:
> So far, this thread has been mostly "I DON'T LIKE THIS CHANGE." But let's
> talk about a real underlying issue instead, mkay?
>
> While no one has actually said this (I guess everyone was too busy slinging
> rhetoric and raising strawman objections) there is at least one real issue
> here, which is:
>
>  - I have a library
>  - I want it to be free of deprecation warnings
>  - I want it to compile cleanly on platform versions N...N+k, where
> something is deprecated with an alternative in M>N, and the alternative does
> not exist in N.
>
> That leaves the hypothetical library provider above (which I assume is
> Stephen's situation, though it was left unsaid) with some bad choices:
>  - @SuppressWarnings the use everywhere
>  - Compile without deprecation warnings
>  - Have multiple sourcebases
>
> I think the real issue is that @SuppressWarnings is too blunt a tool to be
> useful in this situation, so deprecation causes collateral pain for library
> developers.  If we can make the deprecation more painless for this class of
> developers (the ones disproportionately affeted), then I think much of the
> noise goes away.
>
>
> On 4/27/2016 1:42 AM, Stuart Marks wrote:
>>
>> On 4/26/16 3:43 AM, Stephen Colebourne wrote:
>>>
>>> In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this
>>> would be painful and add no value.
>>
>>
>> Hi Stephen,
>>
>> I just sent a reply [1] to Kevin B, wherein I clarified "rename."
>>
>> Briefly, it strictly isn't a rename. The old method would be deprecated
>> not-for-removal, and would be left in place indefinitely.
>>
>> Does this still create pain? If so, is there some way the proposal can be
>> modified to reduce it?
>>
>> s'marks
>
>