There are a number of issues with this opinion:
1) The whiteboard pattern in general requires a consumer type. So it is
absolutely NOT the normal case to be a Provider Type, look at the OSGi
compendium. I do not think there is any package without a Consumer Type.
2) The frequency of Consumer type/Provider type is irrelevant since they're
aggregated in the package. Assuming everything is a Provider Type will break
any client when one of the Consumer type changes, regardless of their ratio.
3) The package level provide: directive was a hack to make some of this stuff
work when there are no Consumer/Provider Type annotations. In the future bnd
should detect this information from the annotations because that is less error
prone. And though it might be useful on imports, its primary intention is on
the export.
4) It is another example, pervasive in enterprise software, of being 'nice' by
trying to hide reality (Damping anyone?) because it is 'easier'. You first make
it right, then make it easier. The other way around usually ends up in trading
development time for lots of debug time. In general it is good to be lazy as a
developer but it should never cause solutions that are not correct all the
time. In the embedded world, these kind of suggestions would be considered,
well, eh, flabbergasting :-)
About the indirection of annotated annotations, this seems like things become a
lot harder to read. I also expect that it will result in the proposed effect of
'well most of the time this existing annotation is ...', having the same
problems as sketched before. I would suggest to keep it highly cohesive and
simple.
Kind regards,
Peter Kriens
On 14 apr. 2013, at 21:26, Henning Andersen wrote:
> 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
> [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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
