Best place to put new (shared) libraries ?

Submitted by Fabien D on Wed, 03/31/2004 - 08:39.

JNode-FS

I would like to add the commons-collection (from jakarta) but I am not sure where to put it.

For now, I will use it for JNode-FS, but I think this library may be used by other subprojects.

In a new subdirectory called lib of JNode-FS as it's done in JNode-Net ?
or in JNode-Core\lib (as log4j) ?

I guess I must do as explained in the doc for plugins. But, should I also add something to system-plugin-list.xml ?

Need more info

Submitted by admin on Wed, 03/31/2004 - 19:45.

Fabien, what do you need the library for?

I think that if there are good reasons to use a library and it is a good library it should be possible to use it.
I do agree that you should not add just any library at any place.

So please answer the "needed for" question first, then we can decide to use it or not, and only after that the question where to put it becomes important. (This also really depends on what you need it for).

Ewout

I need it for FSEntry.getEntry(String name)

Submitted by Fabien D on Wed, 03/31/2004 - 21:12.

For the implementation of getEntry, I thought of a map (entryName -> FSEntry) for better performance in comparison with a simple list.

And, because I have the need, in some cases, to compare the name without case sensitivity, I wanted to use this library.

But I also realized that the order of entries msut be kept (and map implementation doesn't keep it).

So, I decided to use a simple list (and forget the use of this library) because performance could be considered later when the abstraction will work well.

And I added an abstract method to compare a String and a FSEntry. Each FS have to implement it as necessary.

External libraries ?

Submitted by lsantha on Wed, 03/31/2004 - 10:07.

In my opinion it might be reasonable to use as little external libraries as possible in JNode. While code reuse is generally known to be a good thing, it may not be so in every situation.

There are several reasons for the core of the OS to be self contained.

The external library might follow a separte path in the future unsuitable for our needs or the requirements of the OS.
Future applications running on JNode might need an other version of the library, if a class is available in the parent classloader the child classloader will not load it. This may result in very undesirable behavior.
Often it happens that a small fraction of the library is used while it brings in a lot of classes. This can lead to an oversized OS core and increased download time. It also can increase the memory usage and classloading time. If a library is loaded with an application it also can be unloaded with the application, but if the libarary (or casses from it) is loaded with the core it stays in the memory all the time.

The Jakarta commons are know to be very numerous with many dependencies and change often. Therefore it is very likely that version clashes can occure more easily in the future. If you look at the JDK you can see how stable the core libraries are and it never happens with the JDK that some application could load a conflicting jar or class with any class that are part of the distribution.

External libraries also bring additional maintetnace overhead and risk.

So I suggest to think twice before making the basic services of JNode dependent on a new external library until it is not clear how the above concerns will be addressed.

Levente

We need advice from Ewout

Submitted by Fabien D on Wed, 03/31/2004 - 12:58.

Ewout, what's your opinion ?

However, my initial question (how to add an external shared library ?) remains because one day or another someone may have to add a new library.

Think twice again?

Submitted by markhale on Wed, 03/31/2004 - 12:50.

You should also think twice again before not using an external library. The maintenance costs of maintaining version compatibility may (or may not) be insignificant compared to future hidden costs of writing your own code (e.g. time spent debugging, etc).

> Future applications running on JNode might need an other version of
> the library, if a class is available in the parent classloader the
> child classloader will not load it. This may result in very undesirable behavior.

This definitely could be very problematic. I assume it would be a good idea for JNode to use a separate classloader for applications which only exposes the Java API classes. This is probably inevitable given one would want to appy security restrictions to apps anyway.

> External libraries also bring additional maintetnace overhead and risk.

Sorry, I don't understand the risk part here. Surely, code developed by a group of people over time is less risky than code developed by an individual quickly? Am I missing something?