You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix tests not behaving consistently with Android TNG#347
It seems like Gradle Android support treats Java and Android libraries differently. When run from Gradle `ClassLoader.getResources(..)` would return a package entry only from the library JAR, but not the Android JAR. When run from Android Studio it seems like plain file paths and no archives are used, so `ClassLoader.getResources(..)` returns URLs from both libraries.
In the beginning we only used `ClassLoader.getResources(..)`, but then the first bug occurring was that JARs containing a package would not be detected if the folder entry for the package was missing (e.g. look for `java.io` but the entry `/java/io` from the JAR is missing, even though `/java/io/File.class` is there, then `ClassLoader.getResources("/java/io/")` would not give a result). As a workaround we would check if the requested resource was no class file and we got no result and then in turn look through all the JARs on the classpath to return all entries starting with the respective package prefix. Unfortunately this did not work for Android, because `ClassLoader.getResources(..)` provided a partial result, just missing some entries that should be present on the classpath. The only consistent solution seems to be to immediately do the scanning through the classpath ourselves and completely drop the usage of `ClassLoader.getResources(..)`.
I did some performance analysis on Hibernate Core which seemed fine (similar times). What was needed though is a cache for the entries or the build time would explode. This will not make a difference if every location is only scanned once, but as soon as we repeatedly import classes from the classpath the scanning of all archives would cost massive performance (in the end the `ClassLoader` caches all these entries internally as well). I have compared the heap usage with and without the cache on Hibernate core and could not notice a significant increase. Thus it seems okay to go this way and keeping the resource entries in the cache for the lifetime of ArchUnit seems okay.
0 commit comments