The sprints sound like a good way to get actionable items done -- this works for other communities. But what's the goal? To promulgate more APIs under the 'EE' brand?
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).
It's not like Oracle even cares about the "EE" name anymore, so why not? I mean, for crying out loud, Java EE 7 came out over 3 years ago but they still don't offer any certifications for it, but they do for Java SE 8 which is just under a year younger.
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.
4 comments
[ 376 ms ] story [ 356 ms ] threadThe 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).
[1] https://news.ycombinator.com/item?id=12054705#12057590
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.