On 4 December 2016 at 14:13, Felix Schumacher <[email protected]> wrote: > Am 27.11.2016 um 23:05 schrieb sebb: >> >> On 27 November 2016 at 21:18, Philippe Mouawad >> <[email protected]> wrote: >>> >>> Hello, >>> Looking for Deprecated code in JMeter to make some cleanup, I noticed >>> that >>> we have a lot of classes with default Constructors marked as Deprecated >>> for >>> Unit Test only. >>> >>> Couldn't we find a better way to do that and avoid using deprecated for >>> that ? >> >> What's wrong with using deprecated? >> >> The advantage is that it's immediately obvious in main code. >> Test code often needs to continue to test deprecated methods, so it's >> OK to suppress deprecated warnings. >> Whereas it's (almost) never right to suppress a deprecation warning in >> main code. > > I think one of the unit tests uses reflection to find default constructors > or constructors with object as an argument. It searches for those > constructors on all Serializable classes it finds (at least it looked like > that), which seems a bit strange to me. This test emits a warning, when it > can't find one of those classes (as is the case with > o.a.j.protocol.http.parser.CSSParseExceptionCallback which I refused to give > a default constructor, as it would not be able to set a valid baseUrl). > I think we should limit the classes to test to something meaningful, or at > least give a list of exceptions, where the missing constructors are no > problem.
That's a slightly separate issue. If we don't need the ctor for testing, then obviously the deprecated tag is not needed. However if the ctor is needed for testing, then I think the @deprecated approach is a good way to try and prevent its use in normal code. > Regards, > Felix > >> >>> -- >>> Regards. >>> Philippe > > >
