Add Java9 support #63
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ng time, a simple check to only keep the recursive tree of used class files does bring almost no benefit (only ca. 70/1800 classes could be excluded); seems Guava is pretty tangled on class level. To create a more elaborate check walking through the method tree doesn't seem worth the complexity vs archive size. This will unfortunately increase the archive size from ca 1MB to 3MB...
….), since in the future we need to plug in an additional support for 'jrt://' URLs
…generic UrlSource to pass around all URLs from the classpath, independently of how those where retrieved. Background: In Java 9 we don't have URLClassLoaders anymore, so the detection fails. We'll retrieve the URLs from the classpath in a different way then.
…can be dispatched according to Java version
…nce it changed with Java 9 :-(
…e legacy versions of LocationResolver and Location.Factories
…gacy value formatter for AnnotationProxies
…e expected types of failure, so we can run this test with different Java versions in the future
…t Java 9 classes, as well as relocate ASM itself during the build (without the Shadow upgrade, this would throw an exception)
…ts our modules already have the correct name for the future when we can go to Java 9 internally). Also don't relocate module-info.class or we'll end up in a module hell, when archunit.jar suddenly has the module-info of ASM, etc.
…gins to support Java 9. Javadoc has a bug -> doesn't work at the moment. Findbugs misses classes from the JDK. Some tests fail because of different classpath handling with Java 9.
…hes modules on the modulepath and supports jrt:// locations for JMOD files. Most tests run again (AnnotationToString is still wrong, since the Java 9 specific Plugin is still missing). Massive performance decrease though, probably from searching missing entries in all jrt:// locations, we also always create a new module reader for every entry. Thus needs some optimization.
…sed entries, if we couldn't locate the resource before. This should remove all the unnecessary lookups for known classes or packages that we already found (like our own application). Note that this opens a little hole, if we have a package entry in one Jar (so the classloader finds it) and another Jar contains a sub entry, but no package entry, we won't find it anymore. But this seems a border case, since it should be unlikely that the same package is contained in two Jars, but one is packed in a way that skips the folder entries, and one is not.
…le change to fqn
…efault of ClassFileImporter.importClasspath(), since it mimics the old behavior
… (~6000 -> ~50000), so we limit the imported classes so that we don't run out of heap
…treat them as "JavaClass", and they all have the same relative path.
… the wrong results as failures
…a 9, if the respective Gradle property java${version}Home is set
…JDK, since classpath import of JDK classes differs with different Java versions.
…for certain implementation (e.g. Maven) we won't be able to access classes from rt.jar and similar. In these cases the Bootstrap ClassLoader might also always be represented by null, making it hard to programmatically access it in a reliable way.
…n to ClassFileSource.
…fortunately behaves differently depending on the environment, e.g. Maven, Gradle, IDE, ...)
…orrect execution order (no parallel execution) and clean up, even if prepare fails or gets interrupted
…support we will make this version 1.0.0 of ArchUnit, so we can do semantic versioning from then on.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds support for Java 9 projects, in particular
Resolves: #47