You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Kristian Rosenvold <kr...@apache.org> on 2015/09/19 12:32:51 UTC

Version number for next commons-io

The next release is binary compatible except for *1* method that has
been added to a (fairly infrequently used) interface. Does that still
mean I should burn 2.5 and go for 3.0. And would that be 3.0 or 3.0.0
?

Kristian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Peter Ansell <an...@gmail.com>.
On 19 September 2015 at 20:32, Kristian Rosenvold <kr...@apache.org> wrote:
> The next release is binary compatible except for *1* method that has
> been added to a (fairly infrequently used) interface. Does that still
> mean I should burn 2.5 and go for 3.0. And would that be 3.0 or 3.0.0
> ?

If you are thinking about a new major version, you could think about
Java-8. Then, if you need to add methods to interfaces and they can
have default implementations, you can keep both binary and source
compatibility.

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Phil Steitz <ph...@gmail.com>.
On 9/21/15 10:36 AM, Jörg Schaible 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.

+1

Phil
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> .
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:

> On 21 September 2015 at 20:03, Phil Steitz <ph...@gmail.com> wrote:
>> On 9/21/15 10:59 AM, sebb wrote:
>>> On 21 September 2015 at 18:36, Jörg Schaible <jo...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by sebb <se...@gmail.com>.
On 21 September 2015 at 20:03, Phil Steitz <ph...@gmail.com> wrote:
> On 9/21/15 10:59 AM, sebb wrote:
>> On 21 September 2015 at 18:36, Jörg Schaible <jo...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Phil Steitz <ph...@gmail.com>.
On 9/21/15 10:59 AM, sebb wrote:
> On 21 September 2015 at 18:36, Jörg Schaible <jo...@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.

Phil
>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by sebb <se...@gmail.com>.
On 21 September 2015 at 18:36, Jörg Schaible <jo...@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.

> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Jörg Schaible <jo...@gmx.de>.
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.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Gary Gregory <ga...@gmail.com>.
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

Gary

On Mon, Sep 21, 2015 at 10:23 AM, Phil Steitz <ph...@gmail.com> wrote:

> On 9/19/15 9:55 AM, sebb wrote:
> > On 19 September 2015 at 17:26, Kristian Rosenvold <kr...@apache.org>
> wrote:
> >> 2015-09-19 13:58 GMT+02:00 Kristian Rosenvold <kr...@apache.org>:
> >>> Just to be clear on this, the breach is adding an interface to
> >> Oops. The breach is adding a /method/.
> > That's what I assumed - adding a method to an interface does not
> > affect binary compat.
>
> I am +1 for avoiding the repackaging if this is in fact very low
> incidence, but calling it binary compatible is a bit of a stretch
> (unless I am missing something), since it seems to me that this will
> result in RTE if dropped in if a user supplies a listener that does
> not implement the new method, which pretty much all "old" listeners
> would not.  So anyone who uses the listener *must* add the
> implementation and recompile.  Am I missing something here?
> Definitely want to cover this in release notes, since for those who
> use TailerListeners, unless they add the new method, they will get
> unexpected RTE at EOF.
>
> Phil
> >
> >>> org.apache.commons.io.input.TailerListener#endOfFileReached
> >>> and will probably only affect a few users. I'm documenting this in
> >>> release notes.
> >> Kristian
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Version number for next commons-io

Posted by Phil Steitz <ph...@gmail.com>.
On 9/19/15 9:55 AM, sebb wrote:
> On 19 September 2015 at 17:26, Kristian Rosenvold <kr...@apache.org> wrote:
>> 2015-09-19 13:58 GMT+02:00 Kristian Rosenvold <kr...@apache.org>:
>>> Just to be clear on this, the breach is adding an interface to
>> Oops. The breach is adding a /method/.
> That's what I assumed - adding a method to an interface does not
> affect binary compat.

I am +1 for avoiding the repackaging if this is in fact very low
incidence, but calling it binary compatible is a bit of a stretch
(unless I am missing something), since it seems to me that this will
result in RTE if dropped in if a user supplies a listener that does
not implement the new method, which pretty much all "old" listeners
would not.  So anyone who uses the listener *must* add the
implementation and recompile.  Am I missing something here? 
Definitely want to cover this in release notes, since for those who
use TailerListeners, unless they add the new method, they will get
unexpected RTE at EOF.

Phil
>
>>> org.apache.commons.io.input.TailerListener#endOfFileReached
>>> and will probably only affect a few users. I'm documenting this in
>>> release notes.
>> Kristian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by sebb <se...@gmail.com>.
On 19 September 2015 at 17:26, Kristian Rosenvold <kr...@apache.org> wrote:
> 2015-09-19 13:58 GMT+02:00 Kristian Rosenvold <kr...@apache.org>:
>> Just to be clear on this, the breach is adding an interface to
> Oops. The breach is adding a /method/.

That's what I assumed - adding a method to an interface does not
affect binary compat.

>>
>> org.apache.commons.io.input.TailerListener#endOfFileReached
>> and will probably only affect a few users. I'm documenting this in
>> release notes.
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Kristian Rosenvold <kr...@apache.org>.
2015-09-19 13:58 GMT+02:00 Kristian Rosenvold <kr...@apache.org>:
> Just to be clear on this, the breach is adding an interface to
Oops. The breach is adding a /method/.

>
> org.apache.commons.io.input.TailerListener#endOfFileReached
> and will probably only affect a few users. I'm documenting this in
> release notes.

Kristian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by sebb <se...@gmail.com>.
On 19 September 2015 at 13:33, sebb <se...@gmail.com> wrote:
> On 19 September 2015 at 12:58, Kristian Rosenvold <kr...@apache.org> wrote:
>> Just to be clear on this, the breach is adding an interface to
>>
>> org.apache.commons.io.input.TailerListener#endOfFileReached
>> and will probably only affect a few users. I'm documenting this in
>> release notes.
>
> This is binary compatible; it will only affect users who have written
> classes implementing the interface.

... who will have to update their source and recompile.

>
>> Personally I'd say this is 2.5 simply due to its very limited impact,
>
> +1
>
>> but version numbers are cheap :)
>>
>> Kristian
>>
>>
>>
>> 2015-09-19 12:32 GMT+02:00 Kristian Rosenvold <kr...@apache.org>:
>>> The next release is binary compatible except for *1* method that has
>>> been added to a (fairly infrequently used) interface. Does that still
>>> mean I should burn 2.5 and go for 3.0. And would that be 3.0 or 3.0.0
>>> ?
>>>
>>> Kristian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by sebb <se...@gmail.com>.
On 19 September 2015 at 12:58, Kristian Rosenvold <kr...@apache.org> wrote:
> Just to be clear on this, the breach is adding an interface to
>
> org.apache.commons.io.input.TailerListener#endOfFileReached
> and will probably only affect a few users. I'm documenting this in
> release notes.

This is binary compatible; it will only affect users who have written
classes implementing the interface.

> Personally I'd say this is 2.5 simply due to its very limited impact,

+1

> but version numbers are cheap :)
>
> Kristian
>
>
>
> 2015-09-19 12:32 GMT+02:00 Kristian Rosenvold <kr...@apache.org>:
>> The next release is binary compatible except for *1* method that has
>> been added to a (fairly infrequently used) interface. Does that still
>> mean I should burn 2.5 and go for 3.0. And would that be 3.0 or 3.0.0
>> ?
>>
>> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Emmanuel Bourg <eb...@apache.org>.
Le 19/09/2015 13:58, Kristian Rosenvold a écrit :
> Just to be clear on this, the breach is adding an interface to
> org.apache.commons.io.input.TailerListener#endOfFileReached
> and will probably only affect a few users.

As a data point, this listener is never used in the 1100 Java packages
in Debian:

https://codesearch.debian.net/results/TailerListener/page_0

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Version number for next commons-io

Posted by Kristian Rosenvold <kr...@apache.org>.
Just to be clear on this, the breach is adding an interface to

org.apache.commons.io.input.TailerListener#endOfFileReached
and will probably only affect a few users. I'm documenting this in
release notes.

Personally I'd say this is 2.5 simply due to its very limited impact,
but version numbers are cheap :)

Kristian



2015-09-19 12:32 GMT+02:00 Kristian Rosenvold <kr...@apache.org>:
> The next release is binary compatible except for *1* method that has
> been added to a (fairly infrequently used) interface. Does that still
> mean I should burn 2.5 and go for 3.0. And would that be 3.0 or 3.0.0
> ?
>
> Kristian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org