api/runtime modules have non-obvious interdependencies which could break user code in surprising ways.

[mjg123]

In the documented usage of Java FDK, the api module is added by the user to their pom.xml. The runtime module is part of the base image. This should be fine initially, but after that the user is free to try to update either to a newer version.

Example 1: User changes to use a newer api module. This should be OK unless we have made a breaking change to api.

Example 2: User changes to use a new base image (including an updated runtime jar). The newer version of the runtime jar, may have been compiled against a newer version of api than is actually present. This may or may not be a problem depending on if any of the method/class signatures in api have changed or been added.

Example 1 shows that we can't make breaking changes to the api module classes/methods without risking breakage to our users, even if we use semver to signal a breaking change (because not all the code which calls api methods is under user control). Fine. Example 2 shows that we can't change methods in api which are called from runtime - even adding a new method could cause failures as that method will be compiled against but might not be present at runtime.

[mjg123]

The root cause IMO is that the runtime arrives on the classpath from the base image, and the api arrives via a maven dependency.

Strawman solution is to make the user have runtime from maven as well, and remove it from the base images.

[panga]

I vote for bundling the dependencies from Maven project dependencies instead of hardcoded jars in the Docker image (which is an anti-pattern IMO).

This can be reached using maven-dependency-plugin to identify runtime dependencies or a better approach create a Maven plugin to handle FDK commands.