[cdi-dev] Today's meeting will be shorter and about SE

Jozef Hartinger jharting at redhat.com
Thu Dec 18 02:37:43 EST 2014


On 12/18/2014 04:33 AM, John D. Ament wrote:
> I thought today's meeting was pretty good.  Based on one of the 
> discussion points, I wanted to try putting together an interface that 
> described the boot paradigm.  Unfortunately even in Java 8 it doesn't 
> work too well, I cannot assign a static variable in an interface the 
> way I can in an abstract class.  More importantly, it doesn't give us 
> the private level expectation I would look for in this case.  I best I 
> could come up with using an interface is:
>
> public interface CDIBooter {
>     default BeanManager initialize() {
>         return initialize(new HashMap<>());
>     }
>
>     BeanManager initialize(Map<?,?> properties);
Why BeanManager? I think it would be better to return CDI or its 
subclass rather than this low-level SPI. With the CDI class we get more 
user-friendly Instance<T> for free. We could also expose Event<T> similarly.
>
>     void shutdown();
>
>     class BootHolder {
>
>         static CDIBooter instance = null;
>
>     }
>
>     static CDIBooter instance() {
>         if(BootHolder.instance == null) {
>             ServiceLoader<CDIBooter> serviceLoader = 
> ServiceLoader.load(CDIBooter.class);
>             for(CDIBooter booter : serviceLoader) {
>                 BootHolder.instance = booter;
>                 break;
>             }
>         }
>         return BootHolder.instance;
>     }
> }
>
> where as the abstract class is a bit briefer, while also being private.
>
> public abstract class CDIBooter {
>     public BeanManager initialize() {
>         return initialize(new HashMap<>());
>     }
>
>     public abstract BeanManager initialize(Map<?,?> properties);
>
>     public abstract void shutdown();
>
>     private static CDIBooter instance = null;
>     public static CDIBooter instance() {
>         if(instance == null) {
>             ServiceLoader<CDIBooter> serviceLoader = 
> ServiceLoader.load(CDIBooter.class);
>             for(CDIBooter booter : serviceLoader) {
>                 instance = booter;
>                 break;
>             }
>         }
>         return instance;
>     }
> }
>
> Obviously ignore concurrency issues, etc.  It does look to be safer to 
> do an abstract class, rather than a factory-interface.
>
> John
>
>
> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand 
> <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
>
>     Hi all,
>
>
>     I have business matter and will have to shorten the meeting
>     tonight (half an hour instead of 1h).
>
>     I updated the SE doc and Antonio added useful annexes :
>     https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing
>
>     I propose we focus on this in these 30 mn
>
>     regards,
>
>     Antoine
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>     Note that for all code provided on this list, the provider
>     licenses the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/84ca0629/attachment.html 


More information about the cdi-dev mailing list