Use Advanced Search to search the entire archive.
[jsr363-experts] Re: ApacheCon F2F
- From: Werner Keil <
>
- To: "
" <
>
- Cc: Anatole Tresch <
>
- Subject: [jsr363-experts] Re: ApacheCon F2F
- Date: Mon, 5 Oct 2015 10:09:05 +0200
Martin/all,
There is no Bootstrap implementation. It is a one-stop facade for different
implementations of ServiceProvider. The default ServiceProvider is the only
part that gets called via ServiceLoader by default.
https://github.com/unitsofmeasurement/unit-api/blob/master/src/test/java/javax/measure/spi/BootstrapTest.java
shows, how it's replaced by a ServiceProvider implementation that has
nothing to do with Java ServiceLoader.
The only risk of colliding implementations is when you try to mix e.g. the
RI and SE port, but the same happens if you e.g. look at trying to mix
different JSF implementations (seen that and had to solve it for a client
where an IBM product used the Apache implementation and JBoss has its own
version;-)
CDI has a very similar lookup mechanism, now totally bound to Java SE 8
btw:
https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/CDI.java.
It has its own registry of providers and does not directly refer to
ServiceLoader while JSR 107 has a similar fallback in its Caching
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Caching.java
class as JSR 354 does or our Bootstrap class.
Every JSR that's active or just went final has a similar mechanism (also as
a coincidence, most of them compete with 363 e.g. for most Significant JCP
Award;-) so IMHO the abstraction layer is essential to allow different
extensions like SI, ISO, UCUM, and whatever to play together well. If
module A used Java ServiceLoader to implement ServiceProvider while module
B did with OSGi, that should be possible. Guess we can demonstrate that
maybe in the demo section. It is not key part of the JSR but probably a
good thing to show (probably once Eclipse accepted our solution proposal
for different views on the license;-)
Werner
On Sun, Oct 4, 2015 at 10:51 PM, Martin Desruisseaux <
>
wrote:
>
Hello all
>
>
When we talk about the javax.measure.spi.Bootstrap class as an
>
abstraction of the mechanism used for getting the service
>
(java.util.ServiceLoader or OSGi), do we mean that we expect various
>
applications to bundle their own JSR-363 API with their own Bootstrap
>
implementation? (because the current implementation uses ServiceLoader
>
under the hood).
>
>
If the answer to the above is "yes", don't we have a risk of collision
>
if two libraries provide their own, different, set of javax.measure
>
classes? OSGi would not help if the users want to exchange
>
javax.measure.Unit instances between those two libraries.
>
>
Martin
>
>
>
>
Le 02/10/15 20:27, Werner Keil a écrit :
>
> The other issue he raised about the Bootstrap class is something, I
>
> also discussed with Anatole, (Star) Spec Lead of JSR 354 where a
>
> combination of Bootstrap and ServiceProvider interface is used to
>
> abstract the sometimes inappropriate JDK ServiceLoader or in other
>
> implementations of ServiceProvider use something else, including OSGi.
>
>
>
> EC Member IBM did honor this mechanism. Given their large stake in
>
> OSGi or Eclipse, I guess they understand what it's meant for. The name
>
> is not so much an issue, other JSRs have different names, e.g. CDI
>
> simply called an abstract SPI level class with general accessors just
>
> "CDI", but almost every JSR does have at least one such public
>
> accessor class or facade.
>
> Some have more than one.
>
>
>
> The SPI in our case is optional, so nobody is forced to use it, but
>
> unlike just using ServiceLoader which works but has shortcomings
>
> (especially if multiple class-loaders are involved) this abstracts the
>
> various loading mechanisms.
>
>
>
https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/CDI.html
>
> is a good example and via CDIProvider or BeanManager has 2 very
>
> similar interfaces it provides access to or (via setCDIProvider)
>
> allows changing of.
>
>
>
> What do you think? If we dropped it (optional anyway) it could make
>
> interoperability harder. Even standalone SE facing JSRs like 107
>
> (though like 330 it should be bundled with EE 8 after it missed the
>
> EE 7 train) all have a similar "registry" or static accessor. In their
>
> case it's called "Caching", again the name is not written in stone,
>
> let's figure out if we want it in the SPI and what it's good for.
>
>