So I'm forced to add pass through methods to MethodGen? That seems a waste of effort and still requires testing. I repeat - you can already manipulate Attrbiutes - you should be able to manipulate Annotations in exactly the same fashion. It is a missing capability that is needed - at least by me and as we move forward into Java 9 and beyond I'm sure others are going to run the problem.
-----Original Message----- From: sebb [mailto:seb...@gmail.com] Sent: Thursday, October 17, 2019 3:55 PM To: Commons Developers List <dev@commons.apache.org> Subject: Re: strange change to src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java On Thu, 17 Oct 2019 at 23:16, Mark Roberts <mar...@cs.washington.edu> wrote: > > When the BCEL package was renamed back to org.apache.bcel in: > > commit d522432b79044740831a132d8b92e7dab5477444 > Author: Benedikt Ritter <brit...@apache.org> > Date: Tue Jun 7 17:28:43 2016 +0000 > > The methods to add and delete annotations were changed from public to > protected with a confusing comment: > < public void addAnnotationEntry(AnnotationEntryGen ag) > --- > > protected void addAnnotationEntry(final AnnotationEntryGen ag) // TODO > > could this be package protected? The comment makes sense to me. The method was changed from public to protected, reducing the visibility. The TODO asks if it could be made package protected, i.e. further reducing the visibility. > I think this might have been a cut and paste error as the same comment was > added to other methods, but they were left public (so the comment makes > sense). It seems to me that the other methods were also probably intended to be reduced in visibility to protected, but this was not done. > In any case, the current situation is you can add and delete Attributes but > not Annotations. And, surprise, that is exactly what I need to do. > > Any reason not to change these back to public? Increasing visibility increases the difficulty of testing and increases the likelihood of subtle bugs. > Thanks, > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
