Dependency Management¶

Dependency Management

Definition¶

The FWD project uses multiple languages, Java and Javascript being the primary ones. These are considered the foundational language support upon which the project is built. This means J2SE (or the JDK) for Java code and the browser's Javascript classes/APIs for Javascript code.

A dependency is created when there is a new requirement to include any software which is not part of FWD itself AND which is not built into the foundational language support being used. Dependencies on external or "3rd party" code can be indirect or direct. An indirect dependency is one that only exists because it is required to be present so that other dependencies will work. A direct dependency is one where FWD code directly references that external software.

The list of Software Dependencies documents the current dependencies of the project. Some dependencies have versions that are customized specifically for FWD. See Patching and Building Customized 3rd Party Libraries for details on how to build (from source code) these custom dependencies.

Direct vs Indirect Dependencies¶

There is a big difference between an indirect dependency and a direct dependency. Adding direct references to anything outside of J2SE/browser's Javascript engine builds a hard constraint/link. Over time, these direct dependencies tend to spread across the project developers reuse techniques/APIs. Once a direct dependency is added, it may "live forever" in the project because the effort to remove it is too much investment.

Indirect dependencies can be eliminated by removing direct references to the direct dependency that "pulled in" the secondary/tertiary project. These should be minimized but they are not in themselves as costly as a direct dependency.

High Costs of Direct Dependencies¶

There is a big difference between built-in language features (e.g. some API in J2SE or a Java language feature of the JVM/JDK) and features in some external software. For example, common features/APIs of J2SE will be known to nearly 100% of Java developers. But for any project outside of J2SE, even for the most popular frameworks, the common features/APIs may only be known by a very small percentage of Java developers. There may not be a single external project which even 10% of Java developers would be familiar with the features/APIs. This difference means that direct dependencies have real costs. Some examples:

Every reader of this code must now learn an additional framework/interfaces to understand what is going on. This adds cognitive load (https://en.wikipedia.org/wiki/Cognitive_load) to the reader. Anything that adds to cognitive load makes maintenance more of a burden. It doesn't matter if the library is popular, most developers won't know it and should not need to know it to be effective in our project.
Every IDE will need extra setup/configuration to ensure that editing and debugging can be done properly with this library.
Removal of the library becomes significantly harder as usage becomes spread throughout the code.
The attack surface for the application is increased. Secondary or tertiary dependencies can be remediated by the upstream project. Direct dependencies must be remediated by us. This means that flaws and security problems are now more likely to be our problems.
etc...

These costs must be incurred across the lifetime of the dependency which is often the lifetime of the project. The lifetime of the project is indefinite, so the costs must be incurred over and over again forever. This means there is a very high cost to adding dependencies. The more generic the dependency, the more likely it is to spread throughout the code instead of being in limited use. This means that generic dependencies have the highest possible costs.

The value of the dependency must be very high to overcome the high costs. Or the dependency must be very special purpose and naturally limited in usage. That cuts down the cost side of the equation.

This means that the time to evaluate the value of these direct references is before they are added. Do not propose code changes which add new direct dependencies to FWD, unless you've been given explicit approval by the FWD technical leads.

Things to consider:

XYZ is a stable technology and a very good quality library.

This is a good but on its own it does not create value. There are many stable and good libraries which we do not want to use.

XYZ has no dependencies.

This cannot be guaranteed in the future so it cannot be relied upon.

FWD has many dependencies on lesser quality libraries.

Sure. That is a good reason to remove those dependencies when possible. It isn't a reason to add a new dependency.

Support Levels¶

There are 2 levels for supported (a.k.a. "allowed to be used directly in FWD") libraries.

Support Level	Description	Details
1	Full Support	The library can be used anywhere in FWD, without restriction.
2	Targeted Support	The library can only be used for a specific list of purposes. Those limitations will be explicitly defined in the documentation below. No use outside of those limitations is allowed.

List of Supported 3rd Party Libraries¶

This is the list of libraries which can be directly referenced in FWD. If the library you intend to use in FWD code is not listed here, then you need to contact the FWD Project Leader to get explicit approval (or to update this table with a previously approved library).

Library	Support Level	Limitations / Only Allowed For
JSoup	2	HTML Browser widget
Keikai	2	Spreadsheet Widget
junixsocket	2	Unix Domain Socket IPC library. Allowed for JDBC connections over Unix sockets instead of TCP/IP sockets.
Tika	2	Content analysis toolkit. Allowed for the HTML Browser widget or for the FWD web client.

To see specific versions of the libraries used, see Software Dependencies. Please add entries in alphabetical order.

Project

General

Profile

FWD

Wiki