> 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.
People keep saying this without presenting any data to back it up. I don't
know that answer but I am not making any claim here.
>
> bnd already has a similar default regarding its imports, where
> clients should specify provide:=true when the client is a provider of
the API.
This is for a different purpose. We have been discussing the import range
for a bundle importing the package. If a bundle imports the package and is
seen (via bytecode inspection) to be implementing a type that is not
marked @ConsumerType or @ProviderType, then the assumption is that the
type is a @ConsumerType and the import range is fixed major with variable
minor. However if the bundle is seen to be implementing a @ProviderType
(because it is so marked), then we declare the bundle a provider and the
import range is fixed major and fixed minor.
provide:=true (a bnd directive) applies when the bundle is exporting the
package. This informs bnd the generated import (for package
substitutability) must have a range for providers of fixed major and fixed
minor.
>
> 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).
Be careful not to conflate a provider bundle exporting the package vs just
importing the package.
>
> 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.
Naming is always fun :-) I personally prefer the current names. They are
type annotations.
> 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.
>
I am not sure what you are asking for here. @ProviderType and
@ConsumerType are advice from the programmer to tools about the role of
the annotated type in the package. There is nothing to prevent tools from
supporting any other annotations they want for this purpose or any other.
If you want your tool to understand that @MyCustomAnnotation also implies
@ProviderType, then that is something you need to work out with the tool
supplier.
Or are you suggesting that OSGi define a meta-annotation so that your
definition of @MyCustomAnnotation is marked with @ProviderType?
--
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
