users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: JAX-RS (Servlet), EJB and CDI alignment

From: Werner Keil <werner.keil_at_gmail.com>
Date: Sun, 24 Jun 2012 18:16:54 +0200

Antonio,

You make a very good point. In an ideal case, JSR 236 (Concurrent Utils for
J2EE) should handle and help harmonize those asynchronous/concurrent calls,
at least that's where I would see it.

Unfortunately, the JSR has been inactive since 2006, and no clue about CDI,
EJB3 or any other improvements since (writing J2EE above wasn't a mistake
;-/)

Though there have been commits lately, so far the code in java.net shows no
real change over the EE1.4 state of 236 with minor respect to EE5, but
overall around a decade older than what we now got either in EE6+ or other
languages. Even JSR310 is suffering from the heritage as it uses the
TimeUnit from Concurrent in some packages, while others define their own
TimeUnit/PeriodUnit. In addition there are several often too heavy weight
constructs in 310, e.g. PeriodUnit contains a circular back-reference to
Duration (which uses the LocalTimeUnit implementation of PeriodUnit) thus I
doubt, there will ever be a proper usage for concurrency. It's going to
further rely on the old TimeUnit, even if EE 8 or 9 might find 310 as part
of the platform.

Beside languages like Scala or F# where concurrency is better dealt with,
you can see in Fantom's version of Concurrency (Future class) how it
could/should be in Java, too.
There a more lightweight equivalent to 310 in Fantom. A language, Stephen
is very fond of, but some of the old design decisions and mistakes of
earlier Java versions cannot be fixed so easily, even by people like him.
So we're unlikely to see a Fantom style code like: @Suspend(duration=15sec)
any time soon in Java I'm afraid.

Where things are possible in Java, I hope we manage to get them better
alligned, including a more up to date version of JSR 236, otherwise
including it with EE7 instead of starting a fresh, CDI aware approach would
do more harm to Java and EE than help it.

Regards,
Werner Keil
Am 24.06.2012 13:03 schrieb "Antonio Goncalves" <antonio.goncalves_at_gmail.com
>:

> Hi all,
>
> I was reading through JAX-RS 2.0 edr3 specification and had some questions
> about the alignment with other specs. First of all I can see that @Context
> is still used to inject UriInfo, HttpHeaders of even servlet resources.
> When I read the spec (3.2) I see the word *Resource* in the definition :
> "*_at_Context Injects an instance of a supported resource*". So why not use
> the @Resource annotation ? In the case of JAX-RS @Inject looks more
> appropriate (@Resource deals with JNDI names and so on).
>
> For asynchrony (8) they need to inject an ExecutionContext. Again, this
> is done with @Context, which is a real shame as ExecutionContext sounds
> like SessionContext (which is injected with a @Resource or @Inject).
> Asynchrony in JAX-RS is done with the @Suspend annotation, it has a timeout
> and a time unit attributes (@Suspend(timeOut = 15, timeUnit =
> TimeUnit.SECONDS)) while we have @Asynchronous in EJB (without any
> attributes). In the spec there is even a sample mixing both :
>
> @Stateless
> @Path("/")
> class EJBResource {
>
> @GET *_at_Suspend @Asynchronous*
> public void longRunningOp(@Context ExecutionContext ctx) {
> executeLongRunningOp();
> ctx.resume("Hello async world!");
> }
> }
>
> Servlet also has it's own mechanism to deal with asynchronous requests. In
> the EJB group we talked about "standardizing" @Asynchronous and giving it
> to other specifications. Couldn't it be the case with JAX-RS (and Servlet,
> but I think this topic has heavily been debated during Servlet 3.0) ?
>
> And in a more general question, do we really need to push alignment
> between specs when it's possible ?
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal>|
> Blog <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
> JUG <http://www.parisjug.org>
>