Over a million developers have joined DZone.

The "Frameworks" Trap: Common Challenges

DZone's Guide to

The "Frameworks" Trap: Common Challenges

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

I would like to talk to you about Java frameworks. Do you think frameworks are good or bad… or something else? Please notice that I specifically said JAVA frameworks. This is because Java, more than any other language, has a wide variety of frameworks readily available. In fact, the large number of frameworks for Java is one of the problems I want to talk about.

Here are a few areas where problems can occur with frameworks:

  • Picking the right tool for the job
  • Understanding the inner workings
  • Too much variety to choose from


Picking the right tool for the job

I think this may be the biggest and the most fundamental problem most developers have with frameworks. Prior to choosing a particular framework, you need a clear understanding of why you might choose it and whether or not it really fits your needs. I very often encounter projects where poor choices have been made in framework selection, and all kinds of problems result.

Take Hibernate, for example, a great framework that is NOT always the right tool for the job! I often find Hibernate used for programs that may require as few as 10 different SQL queries. Instead of a simple JDBC solution, these projects become bloated with an additional dependence on Hibernate and a large amount of unnecessary code. I've also seen problems with Hibernate in situations where an application must be built to use an existing database that has a very complex and inflexible schema. Although Hibernate generally simplifies object-relational data persistence, in these cases it can be surprisingly difficult to get the best out of both Hibernate and the existing database..

A similar situation sometimes occurs with Application Servers. Although they aren't frameworks, they still provide a wonderful opportunity to choose the wrong tool for the job. Very often I have seen expensive, full-featured application servers deployed just to power a simple WEB application, when in reality a simple Servlet Container would suffice. It's quite like using an ORM framework when a few SQL calls will do the trick.

The framework (and app server) you choose should correspond appropriately to your goals and requirements. Otherwise, you may end up with more disadvantages than advantages.

Understanding the inner workings

Misunderstanding the inner workings of a framework can result in unpredictable results. Often, this translates into terrible performance. Let's take Hibernate again (although I honestly don't mean to pick on Hibernate!) If you don't understand how it works, then it is easy to write code that creates an enormous amount of SQL queries. You end up scratching your head and wondering why your application is so slow.

The moral is: if you decide to use a framework, then you need to have at least a basic understanding of how it works.

Too much variety to choose from

Ironically, because there are now so many frameworks, it can be really hard to choose exactly which one to use. There may be several reasonable options available to solve your problem. For example, how many dependency injection frameworks are there now? Should you choose Spring, Guice, something else? It's really not that easy to know which one will work best, and you can spin wheels for a long time trying to decide. The bountiful range of options actually becomes a problem (although it is certainly better than having no options.)

Be wary when you read the feature list of a framework. It may seem like it is a solution to your problem, but you could be disappointed once you roll your sleeves up and try to work with it. Some framework authors have been known to suggest that their frameworks can do nearly everything, while the reality is often more limited. There are also sometimes novice developers who don't even want to understand how to solve a specific problem. They just want to take framework and hope it will do everything for them. The results, of course, are exactly what you would expect.


Before choosing a framework, take the time to study it. Try to understand how it works and whether it is really suitable for your tasks. The wrong framework can complicate your task and put your whole project at risk. For some very specific tasks, you may not need a framework at all. Just write the basic code you need by yourself. Keep in mind that once you start making use of frameworks, it may become difficult to give them up because of dependencies you introduce into your code.

P.S. I really don't mean to say anything negative about Hibernate. I like Hibernate and mention it only as an example.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}