You're welcome ... I'm happy to see someone looking at this question from a pragmatic stand-point. The continuity of libraries and frameworks and the "usefulness" of a language are
IMPORTANT but usually these trade-offs are discounted versus "coolness" by those comparing the frameworks. If you're focusing on getting something accomplished, chasing every new and improved library, framework and architectural pattern only does one thing - it keeps you from ever delving deeply enough into one technology stack to truly become an expert. Pragmatism and zealotry don't mix.
I should have also stated in my comment above that I almost gave up on Enterprise Java back in the J2EE 1.4 days (2005-2007 if I recall correctly). When you have to create multiple Java files for every EJB (mostly Entity and Stateless Session beans) and edit XML deployment descriptors (many times one deployment descriptor for each supported application server), Java programming feels as tedious as many people describe.
The contrast with JavaEE 6/7 is amazing - the technologies that are encompassed in each of the specifications tend to follow the same pattern. Write a POJO and add annotations. For instance, if you need a business method that consumes messages from a message queue and processes them, that's one (short) Java file with some annotations. For a more complicated example, if you have a database table and want to expose the records via a RESTful interface, here's what you'd have to write six (small) files as follows:
- One entity bean with fields annotated for the ORM as well as accessors and mutators.
- One stateless session bean with your business methods - in this case providing CRUD operations against the entity bean (using a PersistenceContext from JPA)
- One JAX-RS annotated class to provide the RESTful API's methods (again an annotated POJO).
- One Application class (with very few lines of code - it activates JAX-RS).
- One persistence.xml file to define a datasource.
- One (empty) beans.xml file to activate CDI.
If you stick with the JavaEE annotations and configuration files, there are some real benefits to this structure:
- The ORM's entities and configuration are database agnostic ... the same WAR file could be deployed against your MySQL servers, Oracle (for those who have money to burn) or PostgreSQL.
- The application will run on any JavaEE compliant application server. Deploy the file to Glassfish, Wildfly, JBoss EAP or even WebLogic (for those who have money to burn).
- The ORM will cache entities (and can be configured to use a second-level cache when it's prudent). When you start caching database rows, you have to be careful and there may be tuning involved.
- The Application Server will create pools of each of the objects that will be used so that it's not creating and destroying objects over and over again. This is a huge performance gain for servers with a lot of request-scoped web transactions that use stateless session beans for business logic.
There are also ways to create enterprise Java applications that are a little more light-weight (though today's Application Servers have lost a lot of their girth). If you simply use a servlet container you can still use JSF which has a better templating engine that JSP. You can add CDI by including the library and a little bit of bootstrap code. Application servers like Apache TommEE start with Tomcat and add libraries as needed.
It also occurs to me that the "experimental phase" you're embarking on could be leveraged to be both crowd-sourced and open-source. Since you're starting from scratch with each of these technologies, wouldn't it be interesting to have a complete newbie and an expert produce the same application using each of the surviving frameworks?
If you publish a light-weight specification for your test project and open a Github project with each framework's implementation in a sub-directory, I'd be really curious to see what efficiencies and problems were experienced with each implementation. It would also give you a way of comparing your implementations to others.