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

Re: Some general decisions before we can start

matthieu
Hi,

I agree that minimizing dependencies for a framework is a good thing, but on the other hand "polluting" users classpath & code with duplicated APIs & annotation is something that should be avoided... where it make sense.
In my opinion using annotations from JSR-250 & JSR-330 or the like is really a must.
For CDI, I would tend not to jump into it right now. CDI was targeting jee first, it's context (scope) management rely heavily on thread context which make it difficult to use client side (need to handle context switching on the UI thread, not easy nor very efficient).

Matthieu Brouillard


On Wed, Mar 4, 2015 at 8:43 AM, aalmiray [via jsr377-api] <[hidden email]> wrote:
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.


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-tp58p125.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
In reply to this post by aalmiray
Thanks for the summary Andres,
Things are clearer now,@ Inject @PostConstruct and @PreDestroy are easily understandable and well known by developers, but we should check that the Javadoc of such new 'external' annotations give to developers an understandable information according to their Application context otherwise they will be lost.

2015-03-04 8:43 GMT+01:00 aalmiray [via jsr377-api] <[hidden email]>:
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.


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-tp58p125.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 Tom Schindl
On Tue, 2015-03-03 at 12:29 -0700, Tom Schindl [via jsr377-api] wrote:

> 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.

This is why I don't like annotations really for this sort of things.

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
It's exactly this dual life of javax.annotation that makes me cry. Suppose someone wants to also use the other annotations defined in JSR-250 e.g. security, sql? He/she will ship another javax.annotation jar so now you have 2 versions of e.g. @PostConstruct - in a plain classpath scenario this is of no problem but e.g. in an OSGi-Env this might cause you a whole lot of trouble because different bundles/modules could bind to different instances of @PostConstruct
12
Loading...