The author's recommendations are:<p>> 1. Drop the profiles. They are useless and pointless waste of time.<p>This is true, but profiles exist mostly for the benefit of vendors, not developers. Developers only care about modularity, see #2.<p>> 2. Make Java EE a conglomeration of technologies that are known to work together (i.e. JPA, JTA, JMS), but don't force their full installation. Let the use pick and choose what they want. Just be sure that they work together in pieces or in totality.<p>You can do this today, if you use good implementations for those APIs (JMS, JPA)<p>> 3. Make it modular. Start with zero and let people add what they want to use.<p>Same as #2, plus Jigsaw.<p>> 4. Get rid of the tree class loader. You need it matrix based. OSGi is fine. Jigsaw is fine. But it needs to have classes that can be loaded and unloaded without an impact on the container.
> 5. The container itself should be a thin shell with remote capabilities (again OSGi/Karaf looks really good here)<p>The OSGi spec gets a bad rep for complexity, but it actually solves a hard problem. Karaf's default UI, on the other hand, is terrible.<p>> 6. Make it cloud friendly. Microservices needs to be core functionality, lightweight, and run in the cloud.<p>Uhh, it's pretty cloud friendly now. Not sure what the author wants here.<p>Ultimately the author says, if you're invested in the Java EE ecosystem, you can't rely on Oracle to move it forward, but you shouldn't let their inaction lead to your inaction.
However, due to IP reasons and a perceived past overengineering, the community has nearly given up on Java EE and focuses on Java SE instead. This means that they've adopted points #1, #2, #3 and #6, and are actually moving the ecosystem forward, just piecewise and no longer under the 'Java EE' name.