Bill/Linda/all,
Thanks a lot for the update.
Based on our experience in projects like Agorava, but also other JSRs, most
of them probably more likely towards EE8 like 350 or 351, where we plan to
use CDI, too I can only agree.
Most of these harmonizations and simplifications look good for EE7.
Regarding annotations and especially the likes of Bean Validation,
potentially a couple of other JSRs, there is of course more to come for
EE8. I recently mentioned it in a thread of the JPA EG (since it was
inspired by a quoustion there again) and now given the road map it clearly
fits EE8. As Type Annotation Checkers are likely to come with SE8, the EE
version on top of that shall be able to make use of that where applicable.
The most simple example would be @NotNull or the "nullable" aspects of JPA
which cause constraint violations at runtime.
JSR308 adds the option to have compiler warnings or even errors, obviously
something, that needs sensible consolidation, we probably wouldn't want to
pollute and confuse developers with 2 different annotations doing the same
thing, as we just try to simplify other parts that "grew" sometimes
separately.
JSRs like Bean Validation may require a Java 8 upgrade for cases like that.
JSON-B is a good example of what projects like Agorava or a comnercial one
at a client last year already anticipated. In fact there we enriched JPA 2
entities allowing "multi-binding" against relational DB, JSON and
spreadsheets via Apache POI.
The Spreadsheet option could be a bit exotic, but especially for JSON-B I'm
looking forward to help with experience like that. Also joined JSON-P as
one will use the other.
With JSR 357 we were clearly a bit ahead of time. Agorava was a swift
reaction to the arguments why the proposal was stopped. As Social and
Cloud/PaaS often go hand in hand, I wouldn't outrule some of the CDI
leveraging but common enough aspects we identify there proposed again. As
we know, "true modularity" was postponed to Java 9, waiting wit some of
these till 9 makes little sense, but those parts compatible with Java 7 or
6 will also work for any Mobile or Embedded Java based on these.
Having some of the "older" currently bigger Social services like Facebook
or Twitter trying to shield themselves from one another may seem like an
argument against Social standards, but looking at strong trends and new
players like Tent or App.net propagating "Distributed Social Networking", I
envision, these guys and their ideas have potential to become to Social
Media, what Git or Mercurial are to Version Control. Leaving Facebook or
Twitter as CVS, SVN or even earlier products like VSS or PVCS:-D
Thus especially those who proclaim Open APIs and Protocols, I'd say there
is potential in the Java Platform on top of CDI or upcoming JSRs like
JSON-B, Identity API or others.
Cheers,
Werner
Am 30.08.2012 22:58 schrieb "Bill Shannon" <bill.shannon_at_oracle.com>:
> From many of our recent discussions, it seems clear that CDI is
> becoming more central to the Java EE programming model. For example:
>
> - The expanded use of @Stereotype in my previous message.
>
> - The use of CDI interceptors to provide container managed
> transaction support beyond EJB.
>
> - The potential future use of CDI interceptors to provide container
> managed security support beyond EJB.
>
> - The use of CDI interceptors to support Bean Validation method
> level validation.
>
> - The discussion of "implicit producers" to allow use of @Inject
> instead of @Resource to inject Java EE resources.
>
> - The discussion around alignment of CDI managed beans and the
> separate @ManagedBean spec.
>
> - The introduction of a transaction scope and its use in the JMS
> spec to simplify the programming model.
>
> - The change being considered by the CDI expert group to enable
> CDI by default, making it more attractive to use it for all
> the items above.
>
>
> At the same time we're finding that some specs, e.g., JAX-RS, are
> hesitant to introduce a hard, or even soft, dependency on CDI,
> instead insisting that all their new features must work in an
> environment where there is no CDI.
>
> In many ways this parallels what we saw with annotations. In
> the beginning we found many people who didn't want to use annotations
> and wanted us to make sure everything worked without use of
> annotations. Now we're seeing many things that *only* work with
> annotations, and annotations are well accepted by Java EE developers.
> I suppose there's a natural lifecycle to acceptance of new
> technologies, and I wonder where we are in that lifecycle with CDI?
> Has CDI become a mature and accepted technology that we should use
> widely?
>
>
> I'd like to get a sense from this group as to what direction we
> should provide to all the Java EE specs in regards to their use
> of CDI. Here's a few obvious options:
>
> A. Technologies that see a significant standalone (non-Java EE) use
> should be fully functional without CDI. If necessary, any
> required features that are similar to CDI features should be
> defined and implemented in a way that doesn't depend on CDI.
>
> B. Technologies should provide all major features in a way that
> works without CDI. Some features may also be provided in a
> different way that works well with CDI. Some less essential
> features may only work with CDI. The implementation should
> only have a soft dependency on CDI at most.
>
> C. Technologies should provide features that work well with CDI
> without duplicating any functionality in CDI. Use CDI wherever
> it fits. The implementation may have a hard dependency on CDI
> and may require CDI even when used in a standalone environment.
>
> I'm sure you can think of other options as well.
>
> What advice do you think we should give to other Java EE specs?
>