sebb wrote: > 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.
+0 In the light of a future release based on Java 8, I am not sure if it the best action to deprecate the interface now, because then we could use default implementations. Just for consideration. Cheers, Jörg > >> 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
