Well, I'm not a big fan of final myself, but I see no reason to change the behavior of those methods so I made them final. They were private before, but that made it impossible to reuse them from a subclass. In the case of this class, a user can copy-paste the entire class and circumvent the final methods, so there's no absolute necessity for them to be final. It does however indicate to the user which methods are meant to be overridden, and which are not.
If you feel that removing the final modifier is the easiest fix for the bug in clirr, feel free to change the class (don't forget wicket 8). Best regards, Emond On dinsdag 27 september 2016 15:24:01 CEST Martin Grigorov wrote: > We can argue whole day... > There is no perfect software... > > Is there a good reason to use "protected final" ? > Google "Wicket final modifier" and you will see a lot of complains by users. > I know that methods and classes should be final sometimes. Please convince > us this is one of those cases. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Tue, Sep 27, 2016 at 3:18 PM, Emond Papegaaij <[email protected] > > wrote: > > > > No, adding new methods is also allowed (public or protected). If adding a > > new > > final method is considered an API break, adding a new non-final method > > must be > > considred an API break as well. Suppose you have the following method in a > > subclass: > > > > protected String myMethod() {} > > > > And I add the following non-final method to a superclass: > > > > public Integer myMethod() {} > > > > This breaks twice. > > > > Best regards, > > Emond > > > > On dinsdag 27 september 2016 14:59:40 CEST Martin Grigorov wrote: > > > Hi Emond, > > > > > > It is considered as API break because a sub-class may already have this > > > method and 'final' would break it. > > > Is it OK to remove the 'final's ? > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Tue, Sep 27, 2016 at 2:51 PM, Emond Papegaaij < > > > > [email protected] > > > > > > wrote: > > > > > > > > On dinsdag 27 september 2016 14:17:37 CEST Martin Grigorov wrote: > > > > > Fixed! > > > > > > > > > > It seems the backport from 8.x (master) broke it. > > > > > The generics are fine with JDK 8. > > > > > > > > > > But now there is broken Clirr because of Csrf request cycle listener > > > > > > > > This is a bug in Clirr, which I think I fixed. A private methode has > > > > become > > > > protected final, this is NOT an API change. I tried adding it to the > > > > whitelist. I do not have the time to look at this at the moment, > > > > perhaps > > > > > > someone else can have a look? > > > > > > > > Best regards, > > > > Emond > > > > > > > > > Martin Grigorov > > > > > Wicket Training and Consulting > > > > > https://twitter.com/mtgrigorov > > > > > > > > > > On Tue, Sep 27, 2016 at 2:07 PM, Martijn Dashorst < > > > > > > > > > > [email protected]> wrote: > > > > > > In ApplicationSettings this fails. Both in Eclipse and maven. > > > > > > > > > > > > Martijn > > > > > > > > > > > > -- > > > > > > > > Become a Wicket expert, learn from the best: > > http://wicketinaction.com
