Module code isn't constructing in topologically sorted order?

[mikehearn]

I upgraded to 6.10 but hit a weird bug, where the generated module code isn't constructing objects in the right order. It tries to build an object before its dependency, which then yields:

java.lang.IllegalStateException: Injecting null for hydraulic.parts.tasks.jvm.DetectJDK name:!detectJDK when creating class hydraulic.parts.tasks.jvm.DownloadLinkerJDKTask - potential beans to inject: []. Check for missing module? [ missing beanScopeBuilder.withModules() ]. If it is expected to be externally provided, missing beanScopeBuilder.withBean() ?

And indeed, if we look at the module code, we can see:

  public void build(Builder builder) {
    // register external dependencies
    builder.withBean(Machine.class, machine);
    this.builder = builder;
    // create beans in order based on constructor dependencies
    // i.e. "provides" followed by "dependsOn"
    build_jvm_DownloadLinkerJDKTask();
    build_jvm_LinkDistributionJVMTask();
    build_jvm_RepackJarsTask();
    build_jvm_LinkDevJDKTask();
    build_jvm_FetchJDKInputsTask();
    build_mac_GenerateAppleICNSTask();
    build_mac_SparkleRepositoryTask();
    build_mac_ZipUnnotarizedTask();
    build_mac_NotarizeTask();
    build_mac_ZipNotarizedTask();
    build_mac_BundleMacJVMAppTask();
    build_mac_FetchSparkleInputsTask();
    build_tasks_JSONTask();
    build_linux_AptRepositoryTask();
    build_linux_BuildLinuxJVMAppTask();
    build_linux_CreateDebianPackageTask();
    build_tasks_FetchBaseInputsTask();
    build_tasks_PackageForMachine();
    build_jvm_DetectJDK();
  }

so DetectJDK is built last, even though it's needed first. I'm not totally sure how to make a smaller repro case for this because I'm not sure what causes it, but this module depends on another module.

In this code, DetectJDK depends on FetchJDKInputsTask, which in turn depends on three externally provided dependencies, but they're provided by the scope this scope depends on. So maybe there's a sorting problem when scopes depend on each other?

[rbygrave]

So maybe there's a sorting problem when scopes depend on each other?

That very much sounds like it.

DetectJDK depends on FetchJDKInputsTask

Can you show me the dependencies of these 2. I need to try and reproduce. I suspect the issue is more with FetchJDKInputsTask somehow.

[mikehearn]

I can privately send you the codebase if you like. It's got a fairly complex inheritance hierarchy.

class DetectJDK(private val fetchJDKInputsTask: FetchJDKInputsTask) : BuildTaskWithResult<Optional<JDK>> {...}

class FetchJDKInputsTask(build: Build, part: PartConfigView, machine: Machine) : FetchInputsTask(
    build,
    part.jvm.inputsFor(machine)!!
)

abstract class FetchInputsTask(build: Build, configuredInputs: List<InputConfigView>) : ResolveTreeTask(build) {... }

abstract class ResolveTreeTask(build: Build) : CachedTreeTask(build) { .... }

abstract class CachedTreeTask(build: Build) : CachedBuildTask<Path>(build), SummarizableTreeTask { ... }

abstract class CachedBuildTask<T : Any>(protected val build: Build) : BuildTaskWithResult<T>, Summarizable { ... }

interface BuildTaskWithResult<T : Any> : BuildTask, Summarizable

interface Summarizable

interface BuildTask

[mikehearn]

Ah, and ...

/**
 * A dependency injection scope for top level tasks that build one or more packages and then add them to a repository.
 * Classes annotated with this can be fetched from [PartsApplication.scope].
 */
@Scope
@InjectModule(
    requires = [
        Build::class,
        PartConfigView::class,
        SiteConfigModel::class,
        KeyManager::class
    ]
)
annotation class RepositoryTask

/**
 * A dependency injection scope for the construction of a single package targeting a specific machine.
 */
@Scope
@InjectModule(
    requires = [
        RepositoryTask::class,
        Machine::class,

        // https://github.com/avaje/avaje-inject/issues/140
        // Build::class,
        // PartConfigView::class,
        // SiteConfigModel::class,
        // KeyManager::class
    ]
)
annotation class MachineScopedTask

[rbygrave]

Hi @mikehearn Are you able to send me the code base? I'm struggling to reproduce.

[mikehearn]

I'll try debugging it locally. Was working on a separate feature but just finished so I can return to this now.

[mikehearn]

I believe this is the fix:

--- a/inject-generator/src/main/java/io/avaje/inject/generator/MetaDataOrdering.java	(revision fccdb3ab832e9ec7aa79996ee53049d1bb9d62c3)
+++ b/inject-generator/src/main/java/io/avaje/inject/generator/MetaDataOrdering.java	(date 1630922693351)
@@ -175,7 +175,9 @@
         // check non-provider dependency is satisfied
         ProviderList providerList = providers.get(dependency);
         if (providerList == null) {
-          return scopeInfo.providedByOtherModule(dependency);
+          if (!scopeInfo.providedByOtherModule(dependency)) {
+            return false;
+          }
         } else {
           if (!providerList.isAllWired()) {
             return false;

Previously, if a constructor parameter list begins with a class that comes from another module, no other parameters would be checked. After this change, all dependencies are checked.

[rbygrave]

Ah yes, it is hence ordering incorrectly bringing some things in too early.

[rbygrave]

Great work @mikehearn - I did manage to get a failing test once I saw that fix. Releasing as 6.11.

[mikehearn]

Thanks!!