Use Advanced Search to search the entire archive.
[jsr363-experts] Re: ApacheCon F2F
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: ApacheCon F2F
- Date: Mon, 5 Oct 2015 18:06:58 +0200
CDI picks the first one, the difference with its CDI class is,
implementations could extend and override that behavior as they like, the
class is abstract.
JSR 107 throws an exception, see
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Caching.java
(note while 107 has no notion of optionality, it also states
While defined as part of the specification, its use is not required. *
Applications and/or containers may instead choose to directly instantiate a
* {@link CachingProvider} implementation based on implementation specific *
instructions.
By keeping the accessor in the SPI package (like CDI does, too) we make
this a bit clearer. Based on above statement even if the "SPI" profile was
tested by the TCK we may handle the Bootstrap class in a similar way as 107
does.
At least WeakHashMap or PrivilegedAction are both not available in CLDC 8,
so what the Bootstrap class does should be platform neutral.
This Oracle slide on ME 8
http://www.oracle.com/technetwork/cn/community/developer-day/3-javame8-introduced-1902116-zhs.pdf
explicitely mentions ServiceLoader, too, so unless there is a special
permission to call it in ME, the code in Bootstrap should be fine both in
ME and SE.
Whether we follow 107's pattern or not depends on what we think is best in
this context. Note, the only place where it throws an exception is actually
calling getCachingProvider with a particular ClassLoader:
public CachingProvider getCachingProvider(ClassLoader classLoader) {
While JSR 107 is about "caching" it does no caching of the current
provider;-D The method above looks like it's actually a public method of
the private inner helper class CachingProviderRegistry not exposed by
Caching itself.
The publicly visible method states
/** * Obtains the default {@link CachingProvider} available via the *
{@link #getDefaultClassLoader()}. * * @return the {@link CachingProvider} *
@throws CacheException should zero, or more than one * {@link
CachingProvider} be available on the * classpath, or it could not be loaded
* @throws SecurityException when the operation could not be performed * due
to the current security settings */ public static CachingProvider
getCachingProvider() {
While e.g. CDI or the JSR 354 style Bootstrap classes just return a
previously configured provider, no checking or exceptions there.
Not sure, if dealing with multiple classloaders is as important on the
Embedded/Desktop side as it may be in most EE situations? Even CDI uses a
pretty simple approach, but allows its central (and only) accessor class to
be extended. Something we could also consider if it looks beneficial.
Werner