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: [email protected]
> -----Original Message-----
> From: Michael Sokolov <[email protected]>
> Sent: Thursday, July 4, 2019 3:15 PM
> To: [email protected]
> 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 <[email protected]>
> wrote:
> >
> >
> > I think ram directory has been removed already on master?
> >
> > On Thu, Jul 4, 2019, 14:56 Michael Sokolov <[email protected]> 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: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
