CODEWITHSUNDEEP
javaperformancejakarta-eejvm
Teddy
Teddy

Reputation: 4243

What is the cost of adding a class to a JavaEE application

Enterprise applications can easily run into thousands of classes. For example, if there are 200 tables being used, then just the DTOs and DAOs would make 400 classes. Add about 500 jsps and 500 form beans and 1000 actions and were easily approaching 3000 classes.

  1. What is the cost of adding a class to a project?
  2. Should I think of ways to limit number of classes?
  3. Would it make no difference if number of classes approach 20000?

Upvotes: 2

Views: 147

Answers (1)

Will Hartung
Will Hartung

Reputation: 118744

The most significant impact of adding a class to any Java app (JavaEE or not) is cost of loading the class. Each class has a minor amount of overhead, but must inevitably be loaded from the disk and in to the Java Heap. Loading class from the disk can slow server start up, or response to certain actions that need to dynamically load code for the first time. But once the classes are loaded, they pretty much just stay around.

The other impact is many classes will eventually end up in the PermGen section of the Java Heap. Java app servers are notorious for "running out of PermGen" due to applications be reloaded several times during development, but due bugs in the JDK, the App Server, and the program itself, remain behind when the application is reloaded.

The PermGen is also an item that should be specifically configured as a Java option on the start up command.

But other than that, and the 65K class limit that Jan mentioned, adding classes has no really measurable impact on running Java EE app.

Addenda:

In many cases with modern JavaEE, the Entities replace DTO, and the EntityManager, perhaps with a lightweight wrapper, becomes a generic DAO. This is not a universal truth. We've gone back and forth ourselves, too the point that we have reintroduced Models mostly as an external view of the data, while the Entities represent the internal view of the data. We still have the light wrapper around the EntityManager as a generic DAO, however.

Model has a bit of baggage with it as a term, DTO perhaps is a better term, as they're certainly not the richest of domain objects.

You could also create a layer that maps from, say, a JSON Object or XML DOM straight in to you entities (again, using these constructs as Models above), but most folks like tooling to do that, so they may make their Model classes JSON/XML friendly and let the toolkits marshal to Models, and your layer marshal from Models -> Entities.

I still don't really consider the Models DTOs though, at least not in the classic sense. In days of yore, we used DTOs just to get the data out of the persistence tier, so we could work on it at all. Now, we use Entities for that directly. These Models act as our representation to the outside world. It's an arguably moot point, since many applications drift towards being service providers (via SOAP or HTTP web services), in some ways making the app server the "persistent tier". But, that's how we view them internally. More a matter of which side of the fence you're on.

As for a class for something like an Account (rather than a String), operationally, that's just a bit far. There are exceptions of course, but most of those are such a thin veneer on top of a generic String (or other primitive) that it rarely seems worth the bother to build up the surrounding infrastructure and convince the tooling to marshal them back and forth (i.e. Account <-> String). It makes sense for multiple column keys, of course, but we even stray from that -- we never use those in a modern DB.

At some level it seems to make sense, but when you're down doing the work, seems more work than value in my experience.

Upvotes: 2

Related Questions