Use Advanced Search to search the entire archive.
[jsr363-experts] Re: ApacheCon F2F
- From: Martin Desruisseaux <
>
- To:
,
- Subject: [jsr363-experts] Re: ApacheCon F2F
- Date: Sun, 4 Oct 2015 22:51:47 +0200
- Organization: Geomatys
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.