users@javaee-spec.java.net

[javaee-spec users] Re: [jsr342-experts] report on EG meeting at JavaOne

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Thu, 3 Oct 2013 14:32:26 +0200

Hi,

Thanks for the report. Some comments:


On slide 17, just to make it clear for everyone, "standardize
authentication" is really about simplifying the process. Authentication in
Java EE is theoretically standardized already (via JASPIC).



On slide 19, "JAX-RS MVC"

I agree with the central question "Do we really need another standard web
framework?", and would like to specifically add the question "*Why* would
we want a second web framework?"

Is it because JSF is not popular enough, or are there specific use cases
JSF can't address?

As many of you may know, the web framework space is highly fragmented and
fans of the many different frameworks can be very vocal. A few years ago
Wicket saw a surge in popularity, but barely half a year later it was all
about GWT, and then it was about Spring MVC, then Play! and then about
"HTML5" and a slew of JavaScript based frameworks.

Meanwhile there are proponents of both the component-oriented and
action-oriented model. JSF being a prime representative of the
component-oriented model got a lot of bad press in the beginning, which may
have led to the idea that component-oriented frameworks were not ideal. But
ever since JSF 2.0 there has been a massive reduction of complaints against
JSF. Currently I often see JSF (and PrimeFaces) being recommended by users
as reply on questions about which framework to use.

Just a random example:

User 1: "What are some good frameworks to get started with?"

User 2: "I would go with JSF and PrimeFaces. This is a modern web
development framework. There is still a lot of Spring MVC out there but a
lot of it has become redundant to the standard JEE."

(see
http://www.reddit.com/r/java/comments/1nhf3f/how_to_begin_working_with_frameworks
)

So if a "JAX-RS MVC" is just to make Java EE more popular for web
applications with the general public then that might not be entirely
necessary any more.

As for the technical merits of an action-oriented web framework we've seen
that JSF has adopted some aspects of it lately. JSF 2.0 introduced view
parameters and the preRenderView event, which allow users to implement some
action-oriented like behaviour. JSF 2.2 further went into this direction
with the introduction of view actions and the beginning of a stateless mode.

I think it might not be too far removed from the current direction that JSF
is going in to introduce a user supplied front controller that can be
mapped to URL patterns via annotations just like JAX-RS. Such "delegate
front controller" (i.e. called from the JSF supplied controller) could do
pre-processing and select a view to be rendered. Today we can more or less
do something like this via a combination of PrettyFaces, perhaps my
experimental JavaVDL project, the new @Inject @Param of OmniFaces and the
view actions in JSF 2.2. This can be really useful for handling an initial
GET (non-faces) request and is currently the primary use case for which
view parameters and view actions are used.

Together with more elaborate support for stateless views in JSF 2.3, I
wonder what specifics a new action-oriented framework could bring to the
table that can't be easily realized in JSF.

Personally I think that introducing a second competing web framework in
Java EE would be really confusing to users. Microsoft does something like
this (competing with its own APIs), e.g. mfc vs winforms vs wpf vs
silverlight and I'm not really sure it makes things easier for developers.
There's already a lot of different web frameworks to choose from in Java
and Java EE itself offering yet another option will IMHO only fragment
things even more.



On slide 31 and 32 "ReST APIs to deploy and manage applications" and "ReST
APIs to monitor applications"

It's perhaps interesting to remember that Java EE had an API/SPI here with
JSR 88 and JSR 77, but they were pruned for Java EE 7 (see e.g.
https://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2011-11/message/4
).



About the support, I'm surprised about a few things.

There is much support for "More CDI", but little support for "Security
Interceptors" and "Generalized Timer Support". Yet, both of these are
specifically for the "More CDI' story.

I also wonder how there can be no support for Multi-point MDBs. Wasn't that
David Blevins' idea? Didn't he vote for his own idea? Maybe it would also
have been interesting to see what the votes would have been with Oracle
attendees included.

As for the "Improved Security Framework", it's sad to see it got no support
at this particular meet-up. Indeed, there are still lots of complaints
about it. I think very few people would argue Java EE security is extremely
good and even less would argue that security itself is not important, so it
seems like a no-brainer.

Anyway, thanks again for the report and great to see the Java EE 8
preparations starting.

Kind regards,
Arjan Tijms





On Thursday, October 3, 2013, Bill Shannon wrote:

> As previously announced, we held an expert group meeting at JavaOne.
> Slides summarizing the meeting are posted here:
>
> https://java.net/projects/javaee-spec/downloads/download/JavaEE-EG-meeting-results.pdf
>
> The purpose of the meeting was to talk about potential items for Java EE 8.
> I presented a list of items that I collected (see the slides), which we
> discussed just enough to make sure everyone understood the item. We then
> added items suggested by attendees.
>
> Finally, to prioritize the items, attendees voted for the items they
> thought
> were most important. (Oracle attendees did not vote.) Each attendee was
> given 10 dollars/votes and allowed to spend them however they wanted on the
> listed items. The slides summarize the results of that vote.
>
> Note that the results of that vote should only be considered a "straw poll"
> and not necessarily indicative of what might be in Java EE 8.
>
> Our intent is to use the results of this discussion to prepare a poll,
> probably including fewer items than were considered in this meeting, and
> collect feedback from the entire community, similarly to what we did for
> some Java EE 7 issues.
>
> I'd be happy to have any attendees fill in more details on the discussions,
> and/or provide corrections to any of the slides.
>
> Thanks.
>