Class GeneralCodingRules
ArchConditions
and ArchRules
for coding that might be useful in various projects.
When checking these rules, it is always important to remember that all necessary classes need to be
imported. E.g. if ACCESS_STANDARD_STREAMS
is checked, which looks for calls on classes
assignable to Throwable
, it is important to ensure that Exception
and RuntimeException
are imported as well, otherwise ArchUnit does not know about the inheritance structure of these exceptions,
and thus will not consider a call of RuntimeException
a violation, since it does not know that
RuntimeException
extends Throwable
.
For further information refer to ClassFileImporter
.
-
Field Summary
Modifier and TypeFieldDescriptionstatic final ArchCondition<JavaClass>
A condition that matches classes that accessSystem.out
orSystem.err
.static final ArchRule
A rule that checks that allAssertionErrors
(e.g.static final ArchCondition<JavaField>
A condition that matches fields that have an annotation for injection.static final ArchRule
A rule checking that no class accessesDeprecated
members (i.e.static final ArchRule
A rule that checks that none of the given classes access the standard streamsSystem.out
andSystem.err
.static final ArchRule
A rule that checks that none of the given classes throw generic exceptions likeException
,RuntimeException
, orThrowable
.static final ArchRule
A rule that checks that none of the given classes uses field injection.static final ArchRule
A rule that checks that none of the given classes access Java Util Logging.static final ArchRule
A rule that checks that none of the given classes access JodaTime.static final ArchCondition<JavaClass>
A condition that matches classes that throw generic exceptions likeException
,RuntimeException
, orThrowable
.static final ArchCondition<JavaClass>
A condition that matches classes that access Java Util Logging.static final ArchCondition<JavaClass>
A condition that matches classes that access JodaTime. -
Method Summary
Modifier and TypeMethodDescriptionstatic ArchRule
A rule that checks that every test class has the same package as the implementation class.
The rule assumes that tests can be identified by having the same name as the implementation class, but suffixed with "Test" (e.g.static ArchRule
testClassesShouldResideInTheSamePackageAsImplementation
(String testClassSuffix) A rule that checks that every test class resides in the same package as the implementation class.
This rule will identify "test classes" solely by class name convention.
-
Field Details
-
ACCESS_STANDARD_STREAMS
A condition that matches classes that accessSystem.out
orSystem.err
.Example:
System.out.println("foo"); // matches System.err.println("bar"); // matches OutputStream out = System.out; // matches out.write(bytes); try { // ... } catch (Exception e) { e.printStackTrace(); // matches }
For information about checking this condition, refer to
GeneralCodingRules
. -
NO_CLASSES_SHOULD_ACCESS_STANDARD_STREAMS
A rule that checks that none of the given classes access the standard streamsSystem.out
andSystem.err
.It is generally good practice to use correct logging instead of writing to the console.
- Writing to the console cannot be configured in production
- Writing to the console is synchronized and can lead to bottle necks
Example:
System.out.println("foo"); // violation System.err.println("bar"); // violation OutputStream out = System.out; // violation out.write(bytes); try { // ... } catch (Exception e) { e.printStackTrace(); // violation }
For information about checking this rule, refer to
GeneralCodingRules
.- See Also:
-
THROW_GENERIC_EXCEPTIONS
A condition that matches classes that throw generic exceptions likeException
,RuntimeException
, orThrowable
. More precisely, the condition matches when a constructor of the mentioned classes is called.Example:
throw new Exception(); // matches throw new RuntimeException("error"); // matches throw new Throwable("error"); // matches class CustomException extends Throwable { // matches } class CustomException extends Exception { CustomException() { super("error"); // does not match } }
For information about checking this condition, refer to
GeneralCodingRules
. -
NO_CLASSES_SHOULD_THROW_GENERIC_EXCEPTIONS
A rule that checks that none of the given classes throw generic exceptions likeException
,RuntimeException
, orThrowable
. More precisely, the rule reports a violation when a constructor of the mentioned classes is called.It is generally good practice to throw specific exceptions like
IllegalArgumentException
or custom exceptions, instead of throwing generic exceptions likeRuntimeException
.Example:
throw new Exception(); // violation throw new RuntimeException("error"); // violation throw new Throwable("error"); // violation class CustomException extends Throwable { // violation } class CustomException extends Exception { CustomException() { super("error"); // no violation } }
For information about checking this rule, refer to
GeneralCodingRules
.- See Also:
-
USE_JAVA_UTIL_LOGGING
A condition that matches classes that access Java Util Logging.Example:
import java.util.logging.Logger; Logger logger = Logger.getLogger("Example"); // matches
For information about checking this condition, refer to
GeneralCodingRules
.- See Also:
-
NO_CLASSES_SHOULD_USE_JAVA_UTIL_LOGGING
A rule that checks that none of the given classes access Java Util Logging.Most projects use the more powerful LOG4J or Logback instead of java.util.logging, often hidden behind SLF4J. In this case it's important to ensure consistent use of the agreed logging framework.
Example:
import java.util.logging.Logger; Logger logger = Logger.getLogger("Example"); // violation
For information about checking this rule, refer to
GeneralCodingRules
.- See Also:
-
USE_JODATIME
A condition that matches classes that access JodaTime.Example:
import org.joda.time.DateTime; DateTime now = DateTime.now(); // matches
For information about checking this condition, refer to
GeneralCodingRules
.- See Also:
-
NO_CLASSES_SHOULD_USE_JODATIME
A rule that checks that none of the given classes access JodaTime.Modern Java projects use the [java.time] API instead of the JodaTime library.
Example:
import org.joda.time.DateTime; DateTime now = DateTime.now(); // violation
For information about checking this rule, refer to
GeneralCodingRules
.- See Also:
-
BE_ANNOTATED_WITH_AN_INJECTION_ANNOTATION
@PublicAPI(usage=ACCESS) public static final ArchCondition<JavaField> BE_ANNOTATED_WITH_AN_INJECTION_ANNOTATIONA condition that matches fields that have an annotation for injection.Example:
class Example { @Resource DataSource dataSource; // matches @Inject File configFile; // matches @Autowired CustomerService customerService; // matches }
For information about checking this condition, refer to
GeneralCodingRules
.- See Also:
-
NO_CLASSES_SHOULD_USE_FIELD_INJECTION
A rule that checks that none of the given classes uses field injection.Field injection is seen as an anti-pattern. It is a good practice to use constructor injection for mandatory dependencies and setter injection for optional dependencies.
Example:
class Example { @Resource DataSource dataSource; // violation @Inject File configFile; // violation @Autowired CustomerService customerService; // violation }
For information about checking this rule, refer to
GeneralCodingRules
. -
ASSERTIONS_SHOULD_HAVE_DETAIL_MESSAGE
A rule that checks that allAssertionErrors
(e.g. from theassert
keyword) have a detail message.Example:
assert x > 0; // violation throw new AssertionError(); // violation assert x > 0 : "x is not positive"; // no violation throw new AssertionError("x is not positive"); // no violation
-
DEPRECATED_API_SHOULD_NOT_BE_USED
A rule checking that no class accessesDeprecated
members (i.e. calls methods or constructors, or accesses fields) or in other ways depends onDeprecated
classes.
-
-
Method Details
-
testClassesShouldResideInTheSamePackageAsImplementation
@PublicAPI(usage=ACCESS) public static ArchRule testClassesShouldResideInTheSamePackageAsImplementation()A rule that checks that every test class has the same package as the implementation class.
The rule assumes that tests can be identified by having the same name as the implementation class, but suffixed with "Test" (e.g.SomeClass
->SomeClassTest
).
To customize the name suffix that identifies test classes please refer totestClassesShouldResideInTheSamePackageAsImplementation(String)
-
testClassesShouldResideInTheSamePackageAsImplementation
@PublicAPI(usage=ACCESS) public static ArchRule testClassesShouldResideInTheSamePackageAsImplementation(String testClassSuffix) A rule that checks that every test class resides in the same package as the implementation class.
This rule will identify "test classes" solely by class name convention. I.e. for a given classSomeObject
the respective test class will be derived asSomeObject${testClassSuffix}
taking into account the suppliedtestClassSuffix
. If thetestClassSuffix
would for example be"Tests"
, thenSomeObjectTests
would be identified as the associated test class ofSomeObject
.- Parameters:
testClassSuffix
- The suffix that distinguishes test classes from their respective implementation class under test, e.g."Test"
- See Also:
-