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.go...@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 > >
