Specifications proposed to being dropped from #JavaEE8: - JMS 2.1 - MVC 1.0 - Management 2.0 #JavaOne // Feedback?

@Java_EE No, evolve JMS to support cloud messaging!

@Java_EE There should still be room for #MVC in Java EE 8 to serve those not able to go all in with JavaScript on the client

@Java_EE Don't drop MVC! It's relevant. If apps not deployed to the cloud were irrelevant, you could as well drop JSF. Doesn"t make sense.

@Java_EE not all apps are cloudy. Think big banks, big government institutions, etc. JMS still has a place.

@Java_EE Why drop MVC even before it started? Project Ozark actually looks pretty good to me.

@Java_EE drop JSF, add MVC.

@Java_EE @JavaOneConf JMS is everywhere in big financial projects. Dropping it will scare your best clients (banks)

REST only interface is not enough for @Java_EE. Application is more than data and thus need complete solution.

@Java_EE ...so we have two profiles now (And the non JCP microprofile effort) Consider using the profile concept again? Cloud, serverless

@Java_EE How about refining #JMS by keeping the API mostly compatible but add #AMQP as the default messaging protocol with auto fallback.

@Java_EE @JavaOneConf JMS 2.0 is still mandatory in #JavaEE 8 then... right?? Keep it - introduce AMQP support etc - cloud ready it instead!

@Java_EE so...what happened mvc? Although there are bigger concerns to look at (cloud readiness etc). But wasn't it "complete"(ish)?

@Java_EE also messaging could also be specialised and optional. A Completion Order warehouse micro service might need JMS #in

@Java_EE well for a microservices you don't need UI necessarily look at DropWizard. However MVC could be made optional JSRs imho. Que JCP

@Java_EE @JavaOneConf mvc should be there, is something that will bring new developers in an easy path..

@Java_EE Does this just mean no more #JMS for new #JavaEE or nor more JMS ever, even as an independent standard. I would be against the 2nd