Breaking Changes
- The
metaAnnotatedWith(..)
predicate, as well as all syntax elements likeclasses().that().areMetaAnnotatedWith(..)
orclasses().should().beMetaAnnotatedWith(..)
, now all also count direct annotations as matching. The background is, that the typical use case always seemed to be "either directly annotated or annotated with some meta-annotated annotation", so we decided to cover this directly.- If your rule has
metaAnnotatedWith(..).or(annotatedWith(..))
it still works, but you can now drop theannotatedWith(..)
part - If your rule really wanted to test that the annotation is not a direct annotation, but only meta-annotated on another annotation, this can still be asserted by
metaAnnotatedWith(..).and(not(annotatedWith(..)))
(see #527)
- If your rule has
Enhancements
- Classes appearing in member signatures (like field types or method return values) are now automatically resolved in import (see #530)
- Support for Java 17 (see #535)
- New API to check if a
JavaAnnotation
has explicitly declared a certain property, i.e. it is set in the annotation and not taken from the default value (see #499)
Lang
- Improved Javadoc and error message to better explain the difference of
classes().that().implement(..)
andclasses().that().areAssignableTo(..)
Library
- New rule to assert no proxy bypasses, e.g. if a Spring bean internally calls an
@Async
method and thus bypasses the proxy (see #539)
JUnit
- We decided to rename
ArchRules.in(..)
toArchTests.in(..)
, becauseArchRules
was considered confusing, if the actual behavior is to collect all@ArchTest
members of the other class.ArchRules
is still present (yet deprecated), so this will not break existingArchTest
suites (see #525)