JAR files, don't they just bloat and slow Java down?

Question

Okay, the question might seem dumb, but I'm asking it anyways.

After struggling for hours to get a Spring + BlazeDS project up and running, I discovered that I was having problems with my project as a result of not including the right dependencies for Spring etc. There were .jars missing from my WEB-INF/lib folder, yes, silly me.

After a while, I managed to get all the .jar files where they belong, and it comes at a whopping 12.5MB at that, and there's more than 30 of them! Which concerns me, but it probably and hopefully shouldn't be concerned.

How does Java operate in terms of these JAR files, they do take up quite a bit of hard drive space, taking into account that it's compressed and compiled source code. So that can really quickly populate a lot of RAM and in an instant.

My questions are:

Does Java load an entire .jar file into memory when say for instance a class in that .jar is instantiated? What about stuff that's in the .jar that never gets used.

Do .jars get cached somehow, for optimized application performance?

When a single .jar is loaded, I understand that the thing sits in memory and is available across multiple HTTP requests (i.e. for the lifetime of the server instance running), unlike PHP where objects are created on the fly with each request, is this assumption correct?

When using Spring, I'm thinking, I had to include all those fiddly .jars, wouldn't I just be better off just using native Java, with say at least and ORM solution like Hibernate?

So far, Spring just took extra time configuring, extra hard drive space, extra memory, cpu consumption, so I'm concerned that the framework is going to cost too much application performance just to get for example, IoC implemented with my BlazeDS server.

There still has to come ORM, a unit testing framework and bits and pieces here and there. It's just so easy to bloat up a project quickly and irresponsibly easily.

Where do I draw the line?

Answer 1

"Does Java load an entire .jar file into memory when say for instance a class in that .jar is instantiated? What about stuff that's in the .jar that never gets used."

No, the class loader loads each .class file as it is needed.

"Do .jars get cached somehow, for optimized application performance?"

JARs are just like DLLs (except for the details about linking versus class loading): They're just compressed libraries of .class files. They aren't cached: .class files are loaded into perm space as needed.

"When a single .jar is loaded, I understand that the thing sits in memory and is available across multiple HTTP requests (i.e. for the lifetime of the server instance running), unlike PHP where objects are created on the fly with each request, is this assumption correct?"

When your app server loads a .class into perm space, it's available as long as the server is up and running.

"When using Spring, I'm thinking, I had to include all those fiddly .jars, wouldn't I just be better off just using native Java, with say at least and ORM solution like Hibernate?"

Not if you think that using Spring is buying you something. If you don't think the cost/benefit analysis favors you, by all means don't use Spring. But it doesn't sound like you're doing a good analysis if dependencies are deterring you.

"So far, Spring just took extra time configuring, extra hard drive space, extra memory, cpu consumption, so I'm concerned that the framework is going to cost too much application performance just to get for example, IoC implemented with my BlazeDS server."

You have no idea what the performance penalty is for using Spring. Measure it if you think it's a problem. My bet is that your application code or database schema will be the biggest problem.

"There still has to come ORM, a unit testing framework and bits and pieces here and there. It's just so easy to bloat up a project quickly and irresponsibly easily."

Why irresponsibly?

"Where do I draw the line?"

By all means, write your own. Do it all from scratch. You'll have a better idea of what a framework is buying for you and what the real costs are when you're done.

I'll add this: The folks at Spring write some of the best code around. Better than anything that you or I will write. You choose any framework because you believe that you'll get a lift from using code that has been rigorously engineered, has a wider audience, has been tested more thoroughly. and is better by virtually every measure than what you'd write yourself. I would not let the (admittedly) large number of dependencies deter me from using it. When I deploy on an app server and allocate 256 MB of RAM to that JVM, I certainly don't care much if the perm space consumes 10% of that total - until I measure that it's a problem.

I think what's really going on is that you'd rather write PHP instead of Java. It's a fair thought, because a lot of people think that using dynamic languages can offer value over Java. The majority of sites are still written in PHP, so your skepticism is justified.

I'd recommend prototyping a use case or two with and without Spring and using PHP. You'll have a better sense of what works for you after that.

Answer 2

The classloader should only load the classes it needs and they stay memory-resident. Don't worry about 12 MB. RAM is cheap. The objects you create (in a large application) will use far more memory than the classes that get loaded.

So in short, don't worry about it. :)

There is a good article on IBM DeveloperWorks with the title "Demystifying class loading problems, Part 1: An introduction to class loading and debugging tools"

Additional point -- When it comes down to cost, Developer Time costs way more than the hardware does, so if Spring/Hibernate/WhateverTool helps you the developer build the application faster and easier, it is well worth the cost of whatever RAM is being used.