I certainly agree with Emily that having a default of @ProviderType is
sensible, since the normal case for most APIs is to call methods on it, not
to implement interfaces of it.
bnd already has a similar default regarding its imports, where clients
should specify provide:=true when the client is a provider of the API.
I think this makes perfect sense also from a tooling standpoint, in that a
tool could break the build if a client tries to implement a @ProviderType
interface without having declared provide:=true on the corresponding import
statement. That way, there is no unsafety (except naturally purely semantic
changes to implementation).
A sidenote on the RFC 197: I think naming these annotations more explicitly
like "ProviderImplemented" and "ConsumerImplemented" would reduce confusion
on which to use when. Also, it would be really nice if the RFC would allow
specifying other annotations as having the same semantics, for instance by
again annotating those annotations. Allowing us to write:
@MyCustomAnnotation
public interface Xyz {}
and giving provider or consumer role to the interface with the annotation.
We certainly have cases where this would allow us to not add yet another
annotation to all our consumer implemented interface.
Best Regards,
Henning
On Sun, Apr 14, 2013 at 4:17 PM, Neil Bartlett <[email protected]> wrote:
>
> On Sun, Apr 14, 2013 at 2:38 PM, BJ Hargrave <[email protected]> wrote:
>
>> > And even that guess is not really safe. I always use the following
>> > example to explain. If you have an interface A:
>> >
>> > /* version 1.0 */
>> > interface A {
>> > /* returns true in a certain condition */
>> > boolean check();
>> > }
>> >
>> > And in a new version, this interface has been changed like this:
>> >
>> > /* version ??? */
>> > interface A {
>> > /* returns false in a certain condition */
>> > boolean check();
>> > }
>> >
>> > Then, even though the method signature has not changed in any way,
>> > the semantics of this interface have changed in an incompatible way
>> > and a major bump in versioning is required. There is just no way
>> > tools are going to pick up on this as long as they're just based on
>> > Java (byte)code, you actually need to understand the documentation
>> > to understand this. So this is another instance where you might be
>> > in for some unpleasant surprises if you blindly use the output of
>> > such versioning tools.
>>
>> Yes. Tools can only analyze syntactic changes to find semantic
>> differences. Other (non-syntactic) semantic changes need humans to
>> participate in the version change decision.
>>
>
> The conclusion seems to be that tools will differ in their approach to
> interpreting defaults. Tools in the future could even attempt to go further
> and analyze actual method behaviour in addition to signatures. This is fine
> because RFC 197 does not place any constraints on tool developers, it
> merely defines the existence and meaning of the @Consumer/ProviderType
> annotations.
>
>
>
>> --
>>
>> *BJ Hargrave*
>>
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>*
>> **[email protected]* <[email protected]>
>>
>> office: +1 386 848 1781
>> mobile: +1 386 848 3788
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
