JEP 277: Enhanced Deprecation

[Patrick Reinhart]

On 01.11.2015 09:19, Sebastian Sickelmann wrote:
> On 10/31/2015 01:32 PM, Patrick Reinhart wrote:
>> i,
>>
>> On 30.10.2015 18:35, Sebastian Sickelmann wrote:
>>> thanks for starting work on this topic. Would love to help to implement
>>> some parts of this proposal.
>> I also would like to do some work in that area.
>>
>>> For all thinks there seems always a choice between "find all possible
>>> cases" and "limit  the false positives", which seems to me to be an
>>> important part for the adoption in the community.
>> That is also true for me.
>>
>> In my opinion, we should also look at a implementers side, especially
>> on parts that have to be
>> implemented  outside the JDK. What about interfaces or abstract
>> methods that are marked as
>> deperecated? A implementer should not be forced to implement such a
>> method in order to have
>> the chance to clean up it's code. In that case we would need to
>> provide a default method on a
>> interface or not allow to mark a abstract method as deprecated for the
>> time until this method
>> may would go away completely.
> I am not sure what you exactly suggest:
Sorry for my bad english.
> Is it(1):  "look through deprecated methoddeclarations in interfaces in
> the jdk and decide if a default method can be provided"?
> or is it(2): "a implementer of an interface should not be forced by the
> compiler to implement deprecated methoddeclarations"?
It is a kind of both: In order to make it more easier for a implementer 
of a certain interface it
would be a good practice, that a implementer should not be forced to 
implement a method that
is marked as deprecated. As example when writing a new JDBC driver 
you're forced to
implement a couple of methods marked as deprecated when implementing the
java.sql.PreparedStatement.

So it would be a good idea, to look at the existing code base to see if 
there could be default
methods be provided for deprecated methods. This would help reduce new 
implementations
show up having deprecated stuff in, that is needed to be removed later 
on. Also I think on
possible compiler verifications/errors for deprecated methods, where 
default implementations
exist. (just as a rough idea and maybe more of a non-goal)

> I think the first one is a good idea and i think you mean it that way.
That's you got my idea correctly there :-)
> I count the second one only because I understand it like this, as I
> first read your suggestion.
>  From my point of view such thinks like this second one should be added
> as non-goals to this JEP.

That's fair enough. I just wanted to point out, that it's a bit a pain 
to be forced implementing
deprecated stuff, when creating new implementations...

> I hope you agree.

I do!

-- Patrick