On 21 September 2015 at 20:03, Phil Steitz <phil.ste...@gmail.com> wrote: > On 9/21/15 10:59 AM, sebb wrote: >> On 21 September 2015 at 18:36, Jörg Schaible <joerg.schai...@gmx.de> wrote: >>> Gary Gregory wrote: >>> >>>> Alternative to keep 100% BC >>>> >>>> - Remove the new method, release 2.5, and add it back for SNAPSHOT >>>> - Add the new method in a new sub-interface >>> or catch and ignore this special RTE when calling the new method form our >>> code. Old clients never asked for it, new/updated clients can use it. >>> Listener interface is a special case here. >> This is what the JLS says about binary compatibity of a method >> addition to an interface: >> >> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100 >> >> If the code were to use reflection it would notice the difference, but >> otherwise the change is BC according to the JLS. >> >> I don't think we need to do anything here, beyond pointing out that >> recompilated client code may need to be updated. >> But that is not a binary compatible issue, it is source compatibilty. > > So you are saying that somehow if I have implemented a > TailerListener with the old interface and I drop in the new release, > I won't get RTE at EOF? If that is the case, that is a nasty > surprise, regardless of what the JLS says about binary compat.
OK, I see now. If users have extended TailerListenerAdapter then they should be OK. But it does look as though any code that implements the TailerListener interface will have problems, as the new IO code won't find the method. This suggests another possible approach: add the method to the Adapter only and only call the method if the adapter is an instance of the Adapter. We should perhaps deprecate the interface in favour of the Adapter. And the code definitely needs some @since markers before it is ready for release. > Phil >> >>> - Jörg >>> >>> >>> --------------------------------------------------------------------- >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
