users@jersey.java.net

[Jersey] Re: Jersey MVC future?

From: Eran Medan <ehrann.mehdan_at_gmail.com>
Date: Thu, 22 May 2014 14:14:35 -0400

Thanks Gili, good point
My worry is that the opposite will happen to Jersey MVC, without an
"official" support, it will lack adoption, Oracle will not promote it on
conferences, webinars, tutorials, and people will avoid trying it because
it might be "removed" and is not "official".

Perhaps we need a new standalone "Java Web" as an extraction of the web
profile from "Java EE" which will "start from scratch" and try to become
more aligned toward modern web development (Grails, Play, Rails, and even
latest versions of Spring MVC)

Or perhaps it's not Java's job to try to catch up, and let other frameworks
do the work. I just think that if you already start with a big lib
signature for a stripped down vanilla Java EE package. Adding Spring or
Jersey MVC is the same impact as getting Jersey MVC bundled.

Or perhaps a more modular Java EE is what we need. so that you can plug out
JSF if you don't need it and plug in Jersey MVC instead of you prefer.

It's less what you get out of the box and more what is officially
considered "Java EE" standard, because it will drive adoption, official
tutorials, testing, stability, etc.

or so I think...


On Thu, May 22, 2014 at 2:03 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:

> On 22/05/2014 1:12 PM, Eran Medan wrote:
>
>> Are there any plans to include Jersey MVC into Java EE 8 / 9 at some
>> point? Is it on the roadmap?
>>
>> The only reason I'm using Spring and not full Java EE is that I can't put
>> the JAX-RS path on the root without loosing "default" handling of html,
>> servlets etc.
>> E.g. my REST root has to be /something (e.g. /rest or /services) and if I
>> put it at / then I "lose" the ability to simply return a JSP, or even a
>> static HTML without leg work
>>
>> I think Jersey MVC is more "modern" than JSF and will have much larger
>> adoption
>>
>
> I have nothing against Jersey MVC but I disagree with your proposal.
> Instead of bundling the kitchen sink into Java EE, I'd much rather see
> people plugging Jersey MVC and other features into an existing container.
>
> In other words: improve ease of pluggability instead of bundling. Why?
> Because historically, Sun/Oracle never removes anything it bundled in the
> past (which is insane in my book) and as a result we're left with a fat pig
> of a container that benefits no one.
>
> Alternatively, get Sun/Oracle to set an expiration date on backwards
> compatibility and remove features once they expire.
>
> Gili
>