Am 3. April 2017 11:47:11 MESZ schrieb Antonio Gomes Rodrigues <ra0...@gmail.com>: >Hi, > >I don't think it's too controle more but to allow to deprecate them >before >remove them.
I don't understand, of you are pro marking public api explicitly, or for deprecating public api that was never meant to be public and removing them later on. I would go with the second option. Using the public keyword as it was meant by java. If we want to remove a public api, we should deprecate it and removed it in a later version - if it is disable at all. Felix >It will allow to warn users that manipulate JMeter code through custom >code >(Groovy / Javascript >/Beanshell) and for plugin developers. > >Antonio > >2017-04-03 9:15 GMT+02:00 Andrey Pokhilko <a...@ya.ru>: > >> Hi, >> >> I don't support this, because it will limit extenders to much smaller >> API than they have now. Just because we hit couple of methods that >> caused issues with extensions, does not mean we should _control more_ >> what is used. Why limit the freedom? IMO benefits here much less than >> loss of extension potential. >> >> Andrey Pokhilko >> >> On 03.04.2017 08:44, Philippe Mouawad wrote: >> > Hello, >> > I think it would be interesting to identify in code public API for >users >> > that would manipulate JMeter code through custom code (Groovy / >> Javascript >> > /Beanshell) and for plugin developers. >> > >> > This is to avoid breaking backWard compatibility and to allow us to >make >> > cleanups and evolution in a fast and safe way. >> > >> > >> > I didn't find any existing tag to do that, maybe we could create a >> javadoc >> > or annotation to do that. >> > >> > We could then have it in javadocs and run backward cmpat checker. >> > >> > Thoughts ? >> > >> > Regards >> > Philippe >> > >> > >> >>
