0

I collecting up many of my older projects and random code fragments and organizing them in a codebase. I'm trying to figure out if smaller libraries would be more efficient than a large one.

The codebase will be used in Browser Applets, Desktop applications and Server applications. Many thanks.

th3barri3
  • 31
  • 6

2 Answers2

3

As far as I know the Class Loader and Security Manager hit performance at LEAST once, the first time you load a certain class.
The JVM loads ALL related classes (JARs, in the end) to memory at launch, if they're "linked" in an import.
This is how "loading on demand" happens, if using reflection etc.

But the bottom line I wanted to tell you is that if I were you, I'd break the code to as many pieces as possible.
This will give much better maintainability in the long run and that particular point is extremely important in every software life cycle.

Good luck!

Poni
  • 11,061
  • 25
  • 80
  • 121
  • in general i agree, but in terms of applets, less libraries is better. For each library the browser has to open a brand new http connection to fetch it. The less connections, the faster your project will load. Perhaps you could develop in different modules and produce an uber-jar for your applet code. – Matt Oct 25 '12 at 03:46
  • @Matt yea, this is the same consideration when delivering JS files etc'. In the end, you can combine them, but being unable to maintain the code is simply unacceptable. – Poni Oct 25 '12 at 17:10
1

Personally, I try and organize my code libraries in groups of functionality.

If I'm doing a simple console or web project, I don't really want to drag all my UI library code with it. Equally, I have several UI libraries, split into things like utilities, components and animation/advance or specialty libraries.

This, for me, tends to create lots of small, very specific libraries (some which are reliant on others - many of my libraries are reliant a the same core/utility library for instance), but provides a great deal of flexibility as I can pick those libraries which are best going to support the current project without the need to drag a lot of, otherwise, useless baggage.

It does make management a little more complicated (as you need to remember where things are, but if you're careful about how you name and group them it should be okay) and may make the build process longer (depending on what build system you use).

From an execution point of view, I don't think it's going to make a massive difference (other then if you're doing things like network deployment, then size matters ;))

IMHO

It does help keep the projects to a small size, as they carry far less dead weight then if you had a small number of monolithic libraries...(this is a situation where in at work and it's a complete pain).

MadProgrammer
  • 343,457
  • 22
  • 230
  • 366