Some general decisions before we can start

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Some general decisions before we can start

Hendrik Ebbers
I think there are some general points next to the architecture and API features that must be discussed before we can start:

- The Java level: Will will start the JSR with JavaSE 8 as dependency? I think we want to use CDI for the JSR therefore we will have a dependency to the CDI spec / modules. CDI 2.0 will provide support for JavaSE (https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?pli=1) that will be a great benefit for this JSR. CDI 2.0 will be build on top of Java 8 but at the moment RoboVM and JavaFXPorts (Android) don''t support Java 8. Maybe we can decouple the CDI stuff and provide this as a second module. By doing so we will depend on Java 7 and javax.inject (JSR 330) in the core module and a second module adds CDI support that is based on Java 8 and CDI 2.

- The core package name: We need a basic package name for the JSR. I would use javax.application.*
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Sven Reimers
Hi all,

having read the discussion about @PostConstruct I would like to add another question to Hendriks list:

What is our baseline: Definitely use what exists or figure out first what we would like to express and then look at the existing standards if they support what we need?

I think starting without limitations may not be a bad idea..

Regarding usage of Java8: Is the decision Java8 vs Java7 for the API or the reference implementation?

-Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Sébastien Bordes
I think that we can reuse CDI annotations only we can describe precisely each concept, the wording is really important because if we start re-using annotations that could be understood in different way we will introduce some entropy that will limit adoptance.

So I'm agree with Sven to start with a new fresh blank paper.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Hendrik Ebbers
Starting with a blank paper sounds great but I think that we will find some points that we want to provide that are already part of another JSR like injection or lifecycles. I think that it's important to reuse well know Java standards (like annotations) in this case. Most developers know @Inject or @PostConstruct and how they can be used and understand. Using this standards will create a lower barrier for developers to understand and use the JSR. This means that I don't want to define the dependency to JSR-XXX before we start. But once we find a point where we can reuse any general interfaces, annotations or specifications we should do so.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

saschaklein
In reply to this post by Hendrik Ebbers
Hi all,

I would strictly try to focus on a mindsplit between the API and the reference implementation.

The API should be as independent and slim as possible, but with a focus on usability and understandability for the developer.
As the developer is used to use @PostConstruct and so on we should use it to prevent confusion. This also includes common CDI 2.0 annotations.
As JSR 377 will be part of the Standard-Java-Familiy we should 'blend in' where possible without pain - and stand out where we have a reason for.

But as I know many companies will not switch to Java 8 soon, I would add some kind of compatibility layer or module for the reference implementation.
Not to forget Android as you mentioned.
The ref impl should be as open and developer-friendly as possible.

For the package, I like javax.application.* very much.

Just my two cent,
Sascha



Am 17.02.2015 um 09:01 schrieb Hendrik Ebbers [via jsr377-api]:
I think there are some general points next to the architecture and API features that must be discussed before we can start:

- The Java level: Will will start the JSR with JavaSE 8 as dependency? I think we want to use CDI for the JSR therefore we will have a dependency to the CDI spec / modules. CDI 2.0 will provide support for JavaSE (https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?pli=1) that will be a great benefit for this JSR. CDI 2.0 will be build on top of Java 8 but at the moment RoboVM and JavaFXPorts (Android) don''t support Java 8. Maybe we can decouple the CDI stuff and provide this as a second module. By doing so we will depend on Java 7 and javax.inject (JSR 330) in the core module and a second module adds CDI support that is based on Java 8 and CDI 2.

- The core package name: We need a basic package name for the JSR. I would use javax.application.*



If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Some-general-decisions-before-we-can-start-tp58.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

aalmiray
Administrator
In reply to this post by Hendrik Ebbers
I think I bit of clarification regarding the annotations is in order :-)

@PostConstruct and @PreDestroy are part of JDK7 so we can use them as is. Their contract inside a (dependency injection) container is well known

   http://docs.oracle.com/javaee/7/api/javax/annotation/PreDestroy.html
   http://docs.oracle.com/javaee/7/api/javax/annotation/PostConstruct.html

I suggest we follow it to the letter for this JSR (Eclipse4 differs in this regard, and that's their choice).

CDI is a JavaEE related specification. The latest version is 1.2. Version 2.0 promises a modular approach and thus we may reuse their Event Bus specification, however this version is scheduled for release sometime in 2016, which is too late for this JSR as we plan to release by the end of 2015.

Also, CDI != DI. JSR-330 defines a small set of annotations that specify how injection should happen but left out how DI containers should behave and be built. JSR-330 is much leaner and slick than JSR-299/346/365 (CDI). So, given time constraints and memory footprint I'd say we go with plain JSR-330. Additionally 330 defines a single scope annotation (@Singleton) but lets you define additional scopes (such as the one Hendrik mentioned in DataFX's flow behavior)

    http://docs.oracle.com/javaee/7/api/javax/inject/package-summary.html

So we could create our own scopes if needed, without having to rely on full CDI.

Targeting JDK7 as the lowest supported level allows implementations of this JSR to be run on mobile devices using RoboVM and Android. I'd love if the industry as a whole upgraded to JDK8 asap, but that won't happen, compatibility with JDK7 is a reality we must face. If we stick with JDK7 we can reach more potential users. So what do we loose if the source level is not JDK8?

 - specialized functional interfaces such as Producer and Consumer.
 - default methods on interfaces.

We can still define functional interfaces in JDK7 (albeit without the @FunctionalInterface annotation). We used to define APIs without extension methods. So there's no that much to loose.

However if these  or any other JDK8 features prove to be the killer in terms of API design (not implementation!) then I guess we'll switch to JDK8.

Next, the package name. I do like javax.application too but decided to leave it out of the JSR proposal because I felt it could have been an obstacle during the Review Ballot. The package name is 2too generic", that is, it could very well be applied to Web applications, right?

What if we further define the following:

  javax.application.base.*
  javax.application.desktop.*
  javax.application.embedded.*
  javax.application.enterprise.*

The first package will define common behavior to all platforms; the others take care of a particular target.

What do you guys think?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

johanvos
On mobile (iOS and Android), Java 8 would be a problem for now indeed.
However, annotations and DI (JSR 330) are supported, so I think we can leverage those. And indeed, DI != CDI.

- Johan

2015-02-17 10:32 GMT+01:00 aalmiray [via jsr377-api] <[hidden email]>:
I think I bit of clarification regarding the annotations is in order :-)

@PostConstruct and @PreDestroy are part of JDK7 so we can use them as is. Their contract inside a (dependency injection) container is well known

   http://docs.oracle.com/javaee/7/api/javax/annotation/PreDestroy.html
   http://docs.oracle.com/javaee/7/api/javax/annotation/PostConstruct.html

I suggest we follow it to the letter for this JSR (Eclipse4 differs in this regard, and that's their choice).

CDI is a JavaEE related specification. The latest version is 1.2. Version 2.0 promises a modular approach and thus we may reuse their Event Bus specification, however this version is scheduled for release sometime in 2016, which is too late for this JSR as we plan to release by the end of 2015.

Also, CDI != DI. JSR-330 defines a small set of annotations that specify how injection should happen but left out how DI containers should behave and be built. JSR-330 is much leaner and slick than JSR-299/346/365 (CDI). So, given time constraints and memory footprint I'd say we go with plain JSR-330. Additionally 330 defines a single scope annotation (@Singleton) but lets you define additional scopes (such as the one Hendrik mentioned in DataFX's flow behavior)

    http://docs.oracle.com/javaee/7/api/javax/inject/package-summary.html

So we could create our own scopes if needed, without having to rely on full CDI.

Targeting JDK7 as the lowest supported level allows implementations of this JSR to be run on mobile devices using RoboVM and Android. I'd love if the industry as a whole upgraded to JDK8 asap, but that won't happen, compatibility with JDK7 is a reality we must face. If we stick with JDK7 we can reach more potential users. So what do we loose if the source level is not JDK8?

 - specialized functional interfaces such as Producer and Consumer.
 - default methods on interfaces.

We can still define functional interfaces in JDK7 (albeit without the @FunctionalInterface annotation). We used to define APIs without extension methods. So there's no that much to loose.

However if these  or any other JDK8 features prove to be the killer in terms of API design (not implementation!) then I guess we'll switch to JDK8.

Next, the package name. I do like javax.application too but decided to leave it out of the JSR proposal because I felt it could have been an obstacle during the Review Ballot. The package name is 2too generic", that is, it could very well be applied to Web applications, right?

What if we further define the following:

  javax.application.base.*
  javax.application.desktop.*
  javax.application.embedded.*
  javax.application.enterprise.*

The first package will define common behavior to all platforms; the others take care of a particular target.

What do you guys think?


If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Some-general-decisions-before-we-can-start-tp58p64.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

neugens
In reply to this post by aalmiray
On Tue, 2015-02-17 at 02:32 -0700, aalmiray [via jsr377-api] wrote:
> I think I bit of clarification regarding the annotations is in
> order :-)

I'm sorry, it seems I took the wrong example, although it generated a
really interesting discussion :)

My main point was not about those annotations, but the fact that, even
if they are specified formally, there's not way to check their proper
use.

I see those annotations controlling the lifecycle, as opposed to @Inject
style ones that basically deal with resources and data. I believe that
lifecycle is better handled by means of interfaces/abstract classes, to
the likes of Android and iOS for example, and countless other frameworks
before that.

Once we have a coherent lifecycle model (that is, every step of the
lifecycle is well defined and every actor is in the proper state for
that lifecycle), resource and data binding (including binding between
views and controllers) can be handled via annotations.

Btw, I'm not completely on the "we should have actual methods rather
than annotations" line of thought, I myself have contrasting feelings on
that really. But I would like somebody to point me all the benefit of
relaxing on the compile time safety to win on slightly smaller code and
(the big plus for me) highly decoupled components.

> @PostConstruct and @PreDestroy are part of JDK7 so we can use them as
> is. Their contract inside a (dependency injection) container is well
> known
>
>
>  http://docs.oracle.com/javaee/7/api/javax/annotation/PreDestroy.html
>
>  http://docs.oracle.com/javaee/7/api/javax/annotation/PostConstruct.html
>
> I suggest we follow it to the letter for this JSR (Eclipse4 differs in
> this regard, and that's their choice).

Indeed, if we go with annotations, I think we should follow the JSR to
the letter. However, this may be a problem when a relationship will be
needed between Eclipse and the JSR377 framework, or at the very least it
will cause confusion.

> CDI is a JavaEE related specification. The latest version is 1.2.
> Version 2.0 promises a modular approach and thus we may reuse their
> Event Bus specification, however this version is scheduled for release
> sometime in 2016, which is too late for this JSR as we plan to release
> by the end of 2015.

We can follow a similar path though, getting to something similar. Even
better, we could try to make their specification compatible with our
one.

> Also, CDI != DI. JSR-330 defines a small set of annotations that
> specify how injection should happen but left out how DI containers
> should behave and be built. JSR-330 is much leaner and slick than
> JSR-299/346/365 (CDI). So, given time constraints and memory footprint
> I'd say we go with plain JSR-330. Additionally 330 defines a single
> scope annotation (@Singleton) but lets you define additional scopes
> (such as the one Hendrik mentioned in DataFX's flow behavior)
>
>
> http://docs.oracle.com/javaee/7/api/javax/inject/package-summary.html
>
> So we could create our own scopes if needed, without having to rely on
> full CDI.
>
> Targeting JDK7 as the lowest supported level allows implementations of
> this JSR to be run on mobile devices using RoboVM and Android. I'd
> love if the industry as a whole upgraded to JDK8 asap, but that won't
> happen, compatibility with JDK7 is a reality we must face. If we stick
> with JDK7 we can reach more potential users. So what do we loose if
> the source level is not JDK8?
>
>  - specialized functional interfaces such as Producer and Consumer.
>  - default methods on interfaces.
>
> We can still define functional interfaces in JDK7 (albeit without the
> @FunctionalInterface annotation). We used to define APIs without
> extension methods. So there's no that much to loose.
>
> However if these  or any other JDK8 features prove to be the killer in
> terms of API design (not implementation!) then I guess we'll switch to
> JDK8.

+1

I'm in the process of doing a major rewrite for Thermostat, I don't know
if the timeline will match that of this JSR, but for me reusing as much
of the specification as possible would be great, but we are stuck on 7.
I can see other people with similar requirements.

> Next, the package name. I do like javax.application too but decided to
> leave it out of the JSR proposal because I felt it could have been an
> obstacle during the Review Ballot. The package name is 2too generic",
> that is, it could very well be applied to Web applications, right?
>
> What if we further define the following:
>
>   javax.application.base.*
>   javax.application.desktop.*
>   javax.application.embedded.*
>   javax.application.enterprise.*
>
> The first package will define common behavior to all platforms; the
> others take care of a particular target.

I makes sense, however I would defer this to a later stage when we have
more content for those packages?

Cheers,
Mario


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Bjarne
In reply to this post by johanvos
Hi all,

I would like to point out that Java 8 has http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html , which is great for building complex Async/Sync call chains. Might not be something that relevant to this JSR, but nevertheless I wanted to point this out. I too would like that everybody started to use Java 8 since in my opinion it is superior to 7. Any change this JSR might motivate more support/moving to Java 8 if the source is at 8?

- Bjarne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

neugens
On Wed, 2015-02-18 at 01:04 -0700, Bjarne [via jsr377-api] wrote:
> Hi all,
>
> I would like to point out that Java 8 has
> http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html , which is great for building complex Async/Sync call chains. Might not be something that relevant to this JSR, but nevertheless I wanted to point this out. I too would like that everybody started to use Java 8 since in my opinion it is superior to 7. Any change this JSR might motivate more support/moving to Java 8 if the source is at 8?
>
> - Bjarne

Indeed, but Java 8 is too new for most players, (most enterpises are
even still stuck on 6 - not counting mobile development issues!).

There are some handy APIs in 8 that would make the code more elegant,
but we should try to be nice with the rest of the world.

Cheers,
Mario


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Tom Schindl
In reply to this post by aalmiray
I have no big problem with following the spec of the annotation (=no parameters) but wanted to point out that I find the way we use them in e4 to be very convenient (=we allow any number of parameters the DI container is able to provide)

The real question I'd like to bring up us does it really buy you enough to only use those 2 annotations of the whole set? Would it be better to create your own ones if you don't plan to support all of them? The documentation e.g. talks about an InvocationContext, interceptors, ... .

The problem I see with reusing stuff that is not designed with your use case in mind is a good thing to reuse. What do you do once those guys think they need to update the spec and allow you to inject web-specific stuff in any case?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

aalmiray
Administrator
Indeed. Reusing annotations from others bears the risk of them changing the behavior at some point. The same applies to JSR-330 (and 305 if it were released *shakes fist*). But then again, that would mean compatibility breakage which would affect a lot of JavaEE applications until migration is done. It's mote likely that new annotations are put into place than updating their behavior.

An argument in favor of using existing annotations is that server side developers understand their behavior. If we stick to the same behavior (barring InvocationContext and interceptors because they are EJB specific) then it would be easier for them to understand how to use them with JSR377.

But I also recognize the value of defining behavior in a standalone, JSR377 specific way.

Perhaps we can begin by using @PostConstruct and @PreDestroy as is. We can change to our own annotations if these prove to be inadequate or harmful to our goals.

What do you think?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

johanvos
JSR 250 is one of the few dependencies I think we can leverage. So I agree with @PostConstruct and @PreDeploy.

- Johan

2015-03-03 10:54 GMT+01:00 aalmiray [via jsr377-api] <[hidden email]>:
Indeed. Reusing annotations from others bears the risk of them changing the behavior at some point. The same applies to JSR-330 (and 305 if it were released *shakes fist*). But then again, that would mean compatibility breakage which would affect a lot of JavaEE applications until migration is done. It's mote likely that new annotations are put into place than updating their behavior.

An argument in favor of using existing annotations is that server side developers understand their behavior. If we stick to the same behavior (barring InvocationContext and interceptors because they are EJB specific) then it would be easier for them to understand how to use them with JSR377.

But I also recognize the value of defining behavior in a standalone, JSR377 specific way.

Perhaps we can begin by using @PostConstruct and @PreDestroy as is. We can change to our own annotations if these prove to be inadequate or harmful to our goals.

What do you think?


If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Some-general-decisions-before-we-can-start-tp58p114.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Sébastien Bordes
Personnaly I would prefer using a new fresh set of annotation with name that make sense for an Application framework instead of reusing pieces of others API/JSR.

The problem is also to explain why all annotations are ot used, what about @ManagedBean into a 'Desktop|Embedded' Application, using subset can lead to increase complexity for newcomers.

But for sure you can begin reusing existing one to gain some time by keeping in mind that having its own set is far better.

2015-03-03 10:59 GMT+01:00 johanvos [via jsr377-api] <[hidden email]>:
JSR 250 is one of the few dependencies I think we can leverage. So I agree with @PostConstruct and @PreDeploy.

- Johan

2015-03-03 10:54 GMT+01:00 aalmiray [via jsr377-api] <[hidden email]>:
Indeed. Reusing annotations from others bears the risk of them changing the behavior at some point. The same applies to JSR-330 (and 305 if it were released *shakes fist*). But then again, that would mean compatibility breakage which would affect a lot of JavaEE applications until migration is done. It's mote likely that new annotations are put into place than updating their behavior.

An argument in favor of using existing annotations is that server side developers understand their behavior. If we stick to the same behavior (barring InvocationContext and interceptors because they are EJB specific) then it would be easier for them to understand how to use them with JSR377.

But I also recognize the value of defining behavior in a standalone, JSR377 specific way.

Perhaps we can begin by using @PostConstruct and @PreDestroy as is. We can change to our own annotations if these prove to be inadequate or harmful to our goals.

What do you think?


If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Some-general-decisions-before-we-can-start-tp58p114.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML




If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Some-general-decisions-before-we-can-start-tp58p115.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

aalmiray
Administrator
FWIW @PostConstruct and @PreDestroy come bundled in the JDK since Java7. The javax.annotation package (http://docs.oracle.com/javase/7/docs/api/javax/annotation/package-frame.html) defines 1 enum and 5 annotations.

JavaEE 7 extends this package and adds two more annotations (http://docs.oracle.com/javaee/7/api/javax/annotation/package-frame.html).

Because our target is JavaSE I don't see how those two annotations (or any other EJB/JavaEE related concern) should affect us.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Sébastien Bordes
Andres, I was talking about the risk to cherry pick annotations from different API/JSR (ManagedBean was defined into JSR 250 and implemented by JavaEE7).

So I'm totally agree with using annotation shipped with JDK, but JSR 377 shouldn't depend on many others JSR/API.

2015-03-03 11:22 GMT+01:00 aalmiray [via jsr377-api] <[hidden email]>:
FWIW @PostConstruct and @PreDestroy come bundled in the JDK since Java7. The javax.annotation package (http://docs.oracle.com/javase/7/docs/api/javax/annotation/package-frame.html) defines 1 enum and 5 annotations.

JavaEE 7 extends this package and adds two more annotations (http://docs.oracle.com/javaee/7/api/javax/annotation/package-frame.html).

Because our target is JavaSE I don't see how those two annotations (or any other EJB/JavaEE related concern) should affect us.


If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Some-general-decisions-before-we-can-start-tp58p120.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Tom Schindl
It's exactly this dual life that is causing a lot of headache in OSGi/e4 - when we started our minimum supported level was java5 so we had to repackage the javax.annotation and ship them now when you run on java7/8 you have 2 @PostConstruct, @PreDestroy classfiles! and if you are not careful you'll never get your @PostConstruct called because your component is bound to the wrong annotation.

I admit this is an edge case with OSGi but I for my part regret that we used those 2 annotations instead of simply defining our 2 custom ones @PostSetup @PreDispose. My take is if I'm unable to fullfill the complete contract of something it should not be used.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Sébastien Bordes
When I started to design JRebirth, I have made the choice to limit all external dependencies to avoid relying on a jar for only one class.
This is exactly the same principle for annotation, JRebirth has its own annotation (with obviously its own processors) under its own namespace with names that exactly fit with their usages.

So IMHO the JSR 377 API shall be self-sufficient, even it could be tempting to re-use existing annotations available into the JDK.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

Tom Schindl
The only exception is @inject jsr (i tend to forget the number) i think nobody really wants to write another DI container
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some general decisions before we can start

aalmiray
Administrator
Yes, minimizing external dependencies is a Good Thing(tm).

JSR-250 has been absorbed by the JDK (or at least a big part). This means @PostConstruct and @PreDestroy are fair game. No external dependencies here.
JSR-330 delivers dependency injection annotations. These are a must, so chalk one to our external dependencies.
JSR-305 (annotations for software defect detection) is now in a dormant state. Binaries are available but there's a conflict between the licenses (GPL and ASL2). Having no final release is troublesome. As muchs as I'd like to use @Nonnull, @Nullable, @ThreadSafe, @Immutable and friends, we can't actually, so it's crossed from the list.
JSR-365 (CDI 2.0) will define an Event Bus, which I'd very much like to reuse. Unfortunately they'll make a release in late 2016 so it's out of our time scope. What we can do though is mirror their API so that we can switch later with them. What worries me here is how to handle duplication and perhaps, even deprecation. Staying in touch with the CDI team would be key.

Summarizing, our only external dependency so far is JSR-330.
12
Loading...