AOT compilation order is not predictable

[puredanger]

There are some cases where it would be useful to control the order of AOT compilation. Currently, in NamespaceDiscovery.discoverNamespacesIn(), we loop through every namespace in the paths, then check that each path passes every filter, then add that to a set, which is then later iterated to AOT compile. Because a set is used, the iteration will be based on hash order, which is a) not predictable and b) changes between JDKs. I have seen builds that fail with one JDK version but pass with another due to this.

From a user perspective, the namespace regexes mostly looked like a list of namespaces and I expected them to AOT in that order. I realize it's not quite that simple but seems like there might be a way to make the ordering in the pom influence the order they are AOT'ed. Would also need to use a LinkedHashSet with insertion order or a List with a duplicate check to avoid be subjected to the hash ordering.

This is not a critical problem, but just something I ran into.

[emilianbold]

I would have expected that some topological sort is also done based on the imports.

One situation I encountered with https://github.com/emilianbold/enclojure is that I have a clojure file (DefReplWindowFactory) which gets compiled to a Java class and that Java class is imported in another clojure file. So, in theory this would need a 2-step compilation. But in practice, it generally works.

It works if the order is right and the 1st clojure file is compiled first. If the order is wrong, the build fails: Exception in thread "main" java.lang.ClassNotFoundException: org.enclojure.ide.repl.DefReplWindowFactory, compiling:(factory.clj:14:1)

In theory the list order should take into account that:

• the namespace has :gen-class and that
• there is an :import for that class.