> On Thu, May 4, 2017 at 5:19 PM, BJ Hargrave wrote:
>
>> Again, see https://docs.oracle.com/javase/specs/jls/se7/html/jls-
>> 13.html#jls-13.4.15.
>>
>> If an API is released and then you change the API such that the return
>> type is different, e.g. List to Collection, that
On Thu, May 4, 2017 at 5:19 PM, BJ Hargrave wrote:
> Again, see https://docs.oracle.com/javase/specs/jls/se7/html/jls-
> 13.html#jls-13.4.15.
>
> If an API is released and then you change the API such that the return
> type is different, e.g. List to Collection, that is a
<njbartl...@gmail.com>Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?Date: Thu, May 4, 2017 4:51 PM
BJ, is that still the case
org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osgi-dev] Different conceptual version numbers for different
> forms of backwards compatibility?
> Date: Thu, May 4, 2017 5:40 AM
>
> Hi Simon,
>
> On Wed, May 3, 2017 at 10:46 P
On Wed, May 3, 2017 at 10:46 PM, Simon Spero wrote:
> Where this becomes interesting is if an OSGI framework is extended to be
> able to rewrite calls from older bundles to use the newer method signature
> (quasi-recompiling). That would allow the newer package to satisfy
e // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Robert Munteanu <robert.munte...@gmail.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osg
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> <(386)%20848-3788>
>> hargr...@us.ibm.com
>>
>>
>>
>> - Original message -
>> From: Robert Munteanu <robert.munte...@gmail.com>
>> Sent by: osgi-dev-boun
On May 4, 2017 5:40 AM, "Robert Munteanu" wrote:
Hi Simon,
Not to detract from your main point, but method return types are not
part of the method's signature in Java.
https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2
Robert
"You are
i.org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osgi-dev] Different conceptual version numbers for different
> forms of backwards compatibility?
> Date: Thu, May 4, 2017 5:40 AM
>
> Hi Simon,
>
> On Wed, May 3, 2017 at 10:46 PM, S
.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: Re: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?Date: Thu, May 4, 2017 5:40 AM
Hi Simon,On Wed, May 3, 2017 at 10:46 PM, Simon Spero <sesunc...@gmail.com> wrote:>
gi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?Date: Wed, May 3, 2017 6:45 PM I'm trying to clarify some thoughts in my own mind about how different kinds
Hi Simon,
On Wed, May 3, 2017 at 10:46 PM, Simon Spero wrote:
> I'm trying to clarify some thoughts in my own mind about how different kinds
> of backwards compatibility interact with different kinds of version
> numbering.
>
> There are at least two dimensions of backwards
I'm trying to clarify some thoughts in my own mind about how different
kinds of backwards compatibility interact with different kinds of version
numbering.
There are at least two dimensions of backwards compatibility of relevance:
binary v. source, and provider v. consumer. Not all combinations
13 matches
Mail list logo