For comparison, our framework(s):

• wwwrig GitLab Repository
• ecmakit GitLab Repository

Moving application development from highly-structured programming languages into configuration solutions has many significant drawbacks for the programming process:

• Compile time errors are moved to runtime errors (this is the cause of many other problems)
• Type-safety is thrown out the window
• Refactoring is significantly more complex AND tedious
• Modern IDEs are very adept at editing code, but such tools are usually not available for editing configuration files
• Understanding config files requires learning a one-off DSL (Domain-Specific Language) - a waste of time
• Understanding config files requires following a tedious 'trail of breadcrumbs' of string identifiers
• Config files are parse-fragile - typos are easy to make, but hard to find (a bad combination)
• Config files are often not particularly legible or concise
• When working with revision control, monolithic config files that refer to multiple features will often be a source of contention between programmers working on different tasks

• Java is resource-intensive
• Java is SLOW
• Java is overkill for light-weight utility programming
• The J2EE ecosystem is polluted with overly-complicated techniques and dependencies

An interesting read, this guy echoes my own experiences working with Spring in the past: http://www.samatkinson.com/why-i-hate-spring

• The unzipped distribution is over 150 Meg.
• Note: Spring has a FRAMEWORK (Spring Boot) to assist in using Spring as a framework …
• Spring is not a single framework. Rather, it's more of a collection of independent tools, with its Dependency Injection framework as the core item, Spring MVC as its web framework, and many other tools besides.
• Spring is very fond of describing itself as lightweight. However, not many (sane) programmers would characterize a tool having more than 2400 classes, 82 dependencies on external jars, and a distribution size of 150 Meg as “lightweight”. This stretches the usual meaning of the term beyond its comfortable limits.

• Spring is complex
• Spring has no clear focus - its “everything and the kitchen sink”
• Spring's javadoc has over 2400 classes
• “Dependency Hell” - Spring's lib directory contains 49 other tools, totaling 82 jars
• It takes significant time to learn about all of Spring's parts
• Joshua Bloch's dictum of “when in doubt, leave it out” has NOT been applied with Spring at all

• XML complicates the programming process (see general concepts)
• Spring confuses coding with configuration
• “XML Abuse” - XML was intended as a tool for transfering data between systems, but Spring uses XML in a way that wasn't intended by its creators

• Spring IoC makes “Dependency Injection” an unavoidable complication
• Spring AOP and AspectJ have a lot of overlap between them
• Aspect-oriented Programming in general introduces various kinds of complexity issues (more trouble than its worth, Event-Driven models are superior)
• Spring Security is remarkably similar to existing Servlet API security (redundant)

Another interesting read, these guys also echo alot of my sensibilities, and they create what I would call a “LEAN” DAO solution (though not as lean as the DAO layer in wwwrig): https://empire-db.apache.org/empiredb/hibernate.htm

• Prevents diverse programming technologies

• ORM in general is meant to deal with full entities separately, instead of leveraging true relational power
• Using an ORM tends to “pollute” data model's relational integrity by encouraging entity conveniences
• There's more than just one “layer” of abstraction engaged in Hibernate's ORM facade - what SQL Hibernate actually ends up executing is not at all transparent or accessible for modification

• Hibernate imposes an ORM facade instead of modeling how an RDBMS actually works
• Hibernate tries to bridge the ORM gap with internal features, but in order to utilize these features properly many complex decisions must be made (XML or annotations, HQL or criteria API, lazy or eager fetching, and more)
• HQL and criteria API in particular abstract direct SQL support away
• HQL breaks down with conditional/dynamic constraints and joins
• Hibernate generates code, which confounds retaining customizations to such code
• Criteria API is very limited, and result beans are complex and error-prone
• Generated code proliferates both existence and use of unnecessary get'ers and set'ers
• “XML Hell” - XML mapping is tedious and complicated
• “Annotation Hell” - Annotations shouldn't be used in application logic, but Hibernate forces it when not using XML
• Everything Hibernate provides can be done much leaner and with less complexity using true interfaces and classes

• Hibernate tends to map its ORM constructs to either many singular round-trip queries or full-table-join results
• Hibernate precludes using non-entity views created by precise joins and constraints
• Hibernate causes significant short-lived object creation

• JBoss is RedHat-native
• JBoss has a better design and track-record

• RBAC is still changing

• Here's a comparison of the typical meaning given to the word 'configuration', versus the meaning implied by Spring documentation:

  Item                       Normal Config        Spring "Config"
  Number of files            1                    N
  Total number of lines      small                large
  When settings made         deploy time          development time
  File format                simple text          highly structured XML
  Items interdependent       usually not          common
  Small tweaks to behavior   yes                  no
  Specify class names        rare                 common
  Specify method names       almost never         common