You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael Sokolov <ms...@gmail.com> on 2019/07/04 12:56:35 UTC
deprecations
I'm curious what the process for dealing with deprecations (and their
annoying compiler warnings) has been in the past? I see we have a
large number of these stemming from @Deprecation of RAMOutputStream,
RAMInputStream, RAMDirectory, etc, as well as various legacy DocValues
classes, and probably others. Do people usually wait until the
deprecated classes are actually removed in order to clean up their
usage (ie next major release)? It would make sense to me to try to get
ahead of that and clean up the usages earlier, probably in a commit
per deprecated class (or set of related classes). Do we have issues
for this work? It might be something we could inspire aspiring
committers to take on as it can be clearly defined, but is also large
in scope.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: deprecations
Posted by Michael Sokolov <ms...@gmail.com>.
That makes sense. Your idea about commenting the deprecation version,
especially. I guess I was imagining we might have a convention like
always deprecating on the current release branch + master - then it
would always be safe to remove on master, but that might not be
workable in every case, and an explicit comment would really help.
On Thu, Jul 4, 2019 at 11:56 AM Erick Erickson <er...@gmail.com> wrote:
>
> I was thinking about this, also precommit warnings, but never got ‘round to it.
>
> I think deprecations hang around until they annoy someone enough to remove them. I agree it makes sense to remove usages when you deprecate a method, but it’s hit-or-miss, and often varies on how many files that touches. Some of the constructors used in Solr test cases are all over the test code for instance.
>
> I _would_ like people to be much more careful when deprecating methods about noting what release it was deprecated in. For back-compat we try to keep deprecated methods around for a while, and if I have some time to try remove usages
> @Deprecated
> is not nearly as useful as
> @Deprecated // TODO remove for 8.0
>
> ‘cause I have to go figure out what version the first one was deprecated in before I dare remove it.
>
> As far as the JDK is concerned, when we stop developing branch_8x we can only remove deprecations from master…. Which I predict will lead to a shorter cycle between 8.0 and 9.0 than is usual for a major release ;)
>
> FWIW
>
> > On Jul 4, 2019, at 7:59 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> >
> > Hi,
> >
> > By default, we disable deprecation warnings in our build configurations, as those are always confusing for library maintainers, as deprecated stuff often has to be called from your own library code (depends on the way how you preserve backwards compatibility). Or just because you need to test old stuff).
> >
> > To prevent deprecated code from the JDK to be called, we use forbiddenapis ("jdk-deprecated" signature).
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >> -----Original Message-----
> >> From: Michael Sokolov <ms...@gmail.com>
> >> Sent: Thursday, July 4, 2019 3:15 PM
> >> To: dev@lucene.apache.org
> >> Subject: Re: deprecations
> >>
> >> Ah yes, I am looking at branch_8x, duh. OK, the RAM-related
> >> deprecation warnings I was seeing do not show up on master. I guess
> >> the general question still stands though; for example when we
> >> deprecated RAMDirectory, did we at the same time remove all usages?
> >> That seems like "best practice," but e.g. we have not done that with
> >> these LegacyDocValues usages. Is it that it was just too burdensome
> >> there? It seems that at some point we will have to replace those
> >> usages with the newer DocValues APIs.
> >>
> >> On Thu, Jul 4, 2019 at 9:02 AM Dawid Weiss <da...@gmail.com>
> >> wrote:
> >>>
> >>>
> >>> I think ram directory has been removed already on master?
> >>>
> >>> On Thu, Jul 4, 2019, 14:56 Michael Sokolov <ms...@gmail.com> wrote:
> >>>>
> >>>> I'm curious what the process for dealing with deprecations (and their
> >>>> annoying compiler warnings) has been in the past? I see we have a
> >>>> large number of these stemming from @Deprecation of
> >> RAMOutputStream,
> >>>> RAMInputStream, RAMDirectory, etc, as well as various legacy DocValues
> >>>> classes, and probably others. Do people usually wait until the
> >>>> deprecated classes are actually removed in order to clean up their
> >>>> usage (ie next major release)? It would make sense to me to try to get
> >>>> ahead of that and clean up the usages earlier, probably in a commit
> >>>> per deprecated class (or set of related classes). Do we have issues
> >>>> for this work? It might be something we could inspire aspiring
> >>>> committers to take on as it can be clearly defined, but is also large
> >>>> in scope.
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: deprecations
Posted by Erick Erickson <er...@gmail.com>.
I was thinking about this, also precommit warnings, but never got ‘round to it.
I think deprecations hang around until they annoy someone enough to remove them. I agree it makes sense to remove usages when you deprecate a method, but it’s hit-or-miss, and often varies on how many files that touches. Some of the constructors used in Solr test cases are all over the test code for instance.
I _would_ like people to be much more careful when deprecating methods about noting what release it was deprecated in. For back-compat we try to keep deprecated methods around for a while, and if I have some time to try remove usages
@Deprecated
is not nearly as useful as
@Deprecated // TODO remove for 8.0
‘cause I have to go figure out what version the first one was deprecated in before I dare remove it.
As far as the JDK is concerned, when we stop developing branch_8x we can only remove deprecations from master…. Which I predict will lead to a shorter cycle between 8.0 and 9.0 than is usual for a major release ;)
FWIW
> On Jul 4, 2019, at 7:59 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> Hi,
>
> By default, we disable deprecation warnings in our build configurations, as those are always confusing for library maintainers, as deprecated stuff often has to be called from your own library code (depends on the way how you preserve backwards compatibility). Or just because you need to test old stuff).
>
> To prevent deprecated code from the JDK to be called, we use forbiddenapis ("jdk-deprecated" signature).
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: Michael Sokolov <ms...@gmail.com>
>> Sent: Thursday, July 4, 2019 3:15 PM
>> To: dev@lucene.apache.org
>> Subject: Re: deprecations
>>
>> Ah yes, I am looking at branch_8x, duh. OK, the RAM-related
>> deprecation warnings I was seeing do not show up on master. I guess
>> the general question still stands though; for example when we
>> deprecated RAMDirectory, did we at the same time remove all usages?
>> That seems like "best practice," but e.g. we have not done that with
>> these LegacyDocValues usages. Is it that it was just too burdensome
>> there? It seems that at some point we will have to replace those
>> usages with the newer DocValues APIs.
>>
>> On Thu, Jul 4, 2019 at 9:02 AM Dawid Weiss <da...@gmail.com>
>> wrote:
>>>
>>>
>>> I think ram directory has been removed already on master?
>>>
>>> On Thu, Jul 4, 2019, 14:56 Michael Sokolov <ms...@gmail.com> wrote:
>>>>
>>>> I'm curious what the process for dealing with deprecations (and their
>>>> annoying compiler warnings) has been in the past? I see we have a
>>>> large number of these stemming from @Deprecation of
>> RAMOutputStream,
>>>> RAMInputStream, RAMDirectory, etc, as well as various legacy DocValues
>>>> classes, and probably others. Do people usually wait until the
>>>> deprecated classes are actually removed in order to clean up their
>>>> usage (ie next major release)? It would make sense to me to try to get
>>>> ahead of that and clean up the usages earlier, probably in a commit
>>>> per deprecated class (or set of related classes). Do we have issues
>>>> for this work? It might be something we could inspire aspiring
>>>> committers to take on as it can be clearly defined, but is also large
>>>> in scope.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: deprecations
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
By default, we disable deprecation warnings in our build configurations, as those are always confusing for library maintainers, as deprecated stuff often has to be called from your own library code (depends on the way how you preserve backwards compatibility). Or just because you need to test old stuff).
To prevent deprecated code from the JDK to be called, we use forbiddenapis ("jdk-deprecated" signature).
Uwe
-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael Sokolov <ms...@gmail.com>
> Sent: Thursday, July 4, 2019 3:15 PM
> To: dev@lucene.apache.org
> Subject: Re: deprecations
>
> Ah yes, I am looking at branch_8x, duh. OK, the RAM-related
> deprecation warnings I was seeing do not show up on master. I guess
> the general question still stands though; for example when we
> deprecated RAMDirectory, did we at the same time remove all usages?
> That seems like "best practice," but e.g. we have not done that with
> these LegacyDocValues usages. Is it that it was just too burdensome
> there? It seems that at some point we will have to replace those
> usages with the newer DocValues APIs.
>
> On Thu, Jul 4, 2019 at 9:02 AM Dawid Weiss <da...@gmail.com>
> wrote:
> >
> >
> > I think ram directory has been removed already on master?
> >
> > On Thu, Jul 4, 2019, 14:56 Michael Sokolov <ms...@gmail.com> wrote:
> >>
> >> I'm curious what the process for dealing with deprecations (and their
> >> annoying compiler warnings) has been in the past? I see we have a
> >> large number of these stemming from @Deprecation of
> RAMOutputStream,
> >> RAMInputStream, RAMDirectory, etc, as well as various legacy DocValues
> >> classes, and probably others. Do people usually wait until the
> >> deprecated classes are actually removed in order to clean up their
> >> usage (ie next major release)? It would make sense to me to try to get
> >> ahead of that and clean up the usages earlier, probably in a commit
> >> per deprecated class (or set of related classes). Do we have issues
> >> for this work? It might be something we could inspire aspiring
> >> committers to take on as it can be clearly defined, but is also large
> >> in scope.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: deprecations
Posted by Michael Sokolov <ms...@gmail.com>.
Ah yes, I am looking at branch_8x, duh. OK, the RAM-related
deprecation warnings I was seeing do not show up on master. I guess
the general question still stands though; for example when we
deprecated RAMDirectory, did we at the same time remove all usages?
That seems like "best practice," but e.g. we have not done that with
these LegacyDocValues usages. Is it that it was just too burdensome
there? It seems that at some point we will have to replace those
usages with the newer DocValues APIs.
On Thu, Jul 4, 2019 at 9:02 AM Dawid Weiss <da...@gmail.com> wrote:
>
>
> I think ram directory has been removed already on master?
>
> On Thu, Jul 4, 2019, 14:56 Michael Sokolov <ms...@gmail.com> wrote:
>>
>> I'm curious what the process for dealing with deprecations (and their
>> annoying compiler warnings) has been in the past? I see we have a
>> large number of these stemming from @Deprecation of RAMOutputStream,
>> RAMInputStream, RAMDirectory, etc, as well as various legacy DocValues
>> classes, and probably others. Do people usually wait until the
>> deprecated classes are actually removed in order to clean up their
>> usage (ie next major release)? It would make sense to me to try to get
>> ahead of that and clean up the usages earlier, probably in a commit
>> per deprecated class (or set of related classes). Do we have issues
>> for this work? It might be something we could inspire aspiring
>> committers to take on as it can be clearly defined, but is also large
>> in scope.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: deprecations
Posted by Dawid Weiss <da...@gmail.com>.
I think ram directory has been removed already on master?
On Thu, Jul 4, 2019, 14:56 Michael Sokolov <ms...@gmail.com> wrote:
> I'm curious what the process for dealing with deprecations (and their
> annoying compiler warnings) has been in the past? I see we have a
> large number of these stemming from @Deprecation of RAMOutputStream,
> RAMInputStream, RAMDirectory, etc, as well as various legacy DocValues
> classes, and probably others. Do people usually wait until the
> deprecated classes are actually removed in order to clean up their
> usage (ie next major release)? It would make sense to me to try to get
> ahead of that and clean up the usages earlier, probably in a commit
> per deprecated class (or set of related classes). Do we have issues
> for this work? It might be something we could inspire aspiring
> committers to take on as it can be clearly defined, but is also large
> in scope.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>