Proposing an Incremental Java EE Roadmap
johnclingan.com
johnclingan.com
The JCP is doing just fine; in my opinion some proposals have re-shaped the language more than the designers originally intended -- but given broad community acceptance, this is usually a good thing.
I've made this point before [1]: Further additions to the 'EE' suite just enforces a separation from SE with regard to the features an implementation can expect to be available -- it's just another profile. EE primarily benefits vendors of EE application servers, and consultancies who can promote EE as a distinct from SE, even though there are no technical hurdles preventing one to run EE APIs' concrete implementations in an SE setting, as has been commonly done since EE stagnated. In other words, everything is fine, we just don't call it EE anymore (and we don't need to, because we're not the ones who benefit from the separate branding).
And you're right, most people doing greenfield at this point are probably using "EE" components in "SE" projects. I use Spring (Boot), but also use Narayana (JTA), Hibernate (JPA), ActiveMQ (JMS), and if Spring didn't handle DI itself I'd pull in Weld (CDI) as well. Hell, if you don't want to use Spring you can just use Wildfly Swarm.
Java EE is dead, even if Oracle finally finalizes Java EE 8 I see most work migrating from wars/ears deployed to containers to running embedded containers like Spring Boot (+pick your container) or Wildfly Swarm.
I was surprised how they blocked all attempts at modularity. Even though it was evident that they couldn't agree on a set of JSR to include (some people didn't want some things that are included, some people wanted things that aren't included) they were still blocking any attempt to configure which JSRs you want.