Skip to main content

[jsr363-experts] Re: ApacheCon F2F

  • From: Werner Keil < >
  • To: " " < >
  • Cc: Anatole Tresch < >
  • Subject: [jsr363-experts] Re: ApacheCon F2F
  • Date: Mon, 5 Oct 2015 12:15:31 +0200

As for Java ME LIBlets, I trust, Leo could probably share anything worth
considering for the API or RI, but from the very scarse documentation you
find on that at all like
http://docs.oracle.com/javame/config/cldc/opt-pkgs/api/meep/api/doc-files/packaging.html
it sounds quite clear it also uses java.util.ServiceLoader, so no ME
specific different mechanism here either.

Every single JSR that builds its lookup on either calling
java.util.ServiceLoader directly or via a workaround (like CDI does)
scanning  "META-INF/services/" relies on such feature to be available in
Java 9 or above, too.
If Jigsaw broke anything we'd be the least affected and could probably
still alter it in the bootstrap mechanism (again, the name of the class is
still open, but its existence plus a "*Provider" is a pattern every single
JSR except maybe 331 used over the last years) while the likes of 107 or
354 would require a MR of their public API (in fact 365/CDI2 probably won't
finish before Java SE 9, so they will adapt just like we can do;-)

Werner

On Mon, Oct 5, 2015 at 12:04 PM, Werner Keil 
< >
 wrote:

> Libraries will not provide their own Bootstrap implementation or
> extension. Just as CDI implementations won't redefine or replace
> https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/CDI.java,
> they can merely extend it in that case (while the Bootstrap or equivalent
> classes of JSR 354, 107 or 363 are final)
>
> We are in the same situation as all the Final JSRs where ServiceLoader is
> at least a fallback. Also in CDI, btw. the findAllProviders method
> accessess "META-INF/services/" directly, it may bypass the actual
> ServiceLoader class, but uses the same mechanism, hence if there is no
> entry in "META-INF/services/" it would not find anything either.
>
> This is what JSR 107 does if more than one CachingProvider was found;-)
> if (iterator.hasNext()) { CachingProvider provider = iterator.next(); if
> (iterator.hasNext()) { throw new CacheException("Multiple
> CachingProviders have been configured when only a single CachingProvider is
> expected"); } else { return provider; } } else { throw new CacheException(
> "No CachingProviders have been configured"); }
>
>
> CDI while using a more "fancy" Java 8 Lambda way now (something we won't
> do in the API for now;-) simply picks the first just like we do
> configuredProvider = discoveredProviders.stream() .filter(Objects::
> nonNull).findFirst() .orElseThrow(() -> new IllegalStateException("Unable
> to locate CDIProvider"));
>
>
> Except for JSR 107 neither of them has an explicit override mechanism and
> neither of them throws an exception, unless none was found (that's where
> JSR 354 or 363 offer a DefaultProvider while CDI will fail with an
> exception)
>
> Werner
>
> On Mon, Oct 5, 2015 at 11:44 AM, Martin Desruisseaux <
>  >
>  wrote:
>
>> Le 05/10/15 10:09, Werner Keil a écrit :
>> > 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.
>>
>> javax.measure.spi.Boostrap is a concrete class using
>> java.util.ServiceLoader for fetching an instance of
>> javax.measure.spi.ServiceProvider. So if libraries or applications do
>> not provide their own Bootstrap implementation, this assume that anyone
>> would use at least the
>> META-INF/services/javax.measure.spi.ServiceProvider mechanism, even if
>> they may use an other mechanism after that point. Are we okay with that?
>>
>> Also, what should Bootstrap do if more than one ServiceProvider is found?
>>
>>     Martin
>>
>>
>>
>


[jsr363-experts] ApacheCon F2F

Werner Keil 10/02/2015

[jsr363-experts] Re: ApacheCon F2F

Martin Desruisseaux 10/04/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Martin Desruisseaux 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Martin Desruisseaux 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Martin Desruisseaux 10/05/2015

[jsr363-experts] Re: ApacheCon F2F

Werner Keil 10/05/2015
 
 
Close
loading
Please Confirm
Close