34 ms·

Being a Java/JVM expert, I wanted to add a couple of thoughts to your process. I'm not insinuating that you should change anything you've done! - Dropping JBo

by smoyer 12y ago

Being a Java/JVM expert, I wanted to add a couple of thoughts to your process. I'm not insinuating that you should change anything you've done! - Dropping JBoss Seam as a framework was a good choice because the important parts of Seam have been added to the JavaEE system, which provides an end-to-end set of technology specifications. If you choose to run a Java Application Server (such as JBoss EAP, Glassfish or Wildfly), then the server will support the full set of specifications, but you don't have to use them. Since JavaServer Faces (JSF) is one of those specification, I'm not really surprised you hadn't heard of it ... it's essentially JSP with lifecycle control and data-binding. - GWT is indeed a Java technology, but it produces client-side code. For big projects, I generally use GWT with Bootstrap to generate the client. It compiles into Javascript producing several versions optimized for different browser groups. Using Martin Fowler's Passive View pattern, it's easy to write fast tests for your client-side business logic, and since it's typesafe, you get compiler errors before the compilation to Javascript instead of the run-time errors you often see when writing in Javascript (or Coffeescript). Since I generally write the back-end for a generic JavaEE server, I also tend to use REST calls from GWT to an Application Server for client-server communication. - If you're looking for an ORM, none of the Java frameworks will include one directly, but it should be pluggable. When people talk about Java web frameworks, they're often constrained to just the "View" tier. Spring provides a much more full-featured stack (with DI and JPA) and is more analogous to JavaEE as a whole. I think you should consider those two as the full-stack contenders in Java. You can add GWT onto either if you need a client-side Java technology (I'm sure you'd NEVER use Java Applets for the client side right?). - I happen to like Scala and appreciate how purely it seems to add a syntax to Lambda calculus. Martin Odersky's "Principles of Functional Programming in Scala" on Coursera was a great class, but I'm hoping the Scala IDE advances quickly. I'll admit I've never written production software in Scala (or using WAVE) but I also admire one project that's using it successfully (https://github.com/takezoe/gitbucket https://github.com/takezoe/gitbucket).

jacquesm 12y ago
Super comment, thanks a ton, I will update the post at some point after this thread has cooled down a bit and I will definitely use your input.
- smoyer 12y ago
  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.

by smoyer 12y ago

jacquesm 12y ago

Super comment, thanks a ton, I will update the post at some point after this thread has cooled down a bit and I will definitely use your input.

smoyer 12y ago
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.