I'm testing a new plugin version that adds a cross-file check. It works like this:
Rule: Builds compiled to target Java 8 must not be executed on older JVM versions to avoid bugs
triggerFilePattern: /pom.xml
triggerExpression: .1.8.
disallowFilePattern: _/start.sh
disallowExpression: ._jdk1.(6|7).
Any matches of the "disallow" criteria will be raised as issues if and only if the trigger expression matched at least once.
Other possible uses:
This rule type can be run against files with any extension (last I checked extensionless files were problematic - I clone those and add .txtcpy to them before I scan) so in theory one could detect that a project uses a particular version of xerces (the trigger) and then look for java code that exercises functionality from that library that is known to have a problem such as a memory leak. There's no Java AST here so scanning complex content like XML or Java will be imperfect but it is possible.
Another similar example is failure to set the CachingConnectionFactory's consumer caching feature under Spring versions that offer it (2.5.6+). Generally we set that to false to avoid leaks unless there's a particular need for it and due diligence has been done to determine that it is safe to use / won't leak. I'm expecting people to forget to set it during Spring version upgrades and in those cases it'll silently turn on since it defaults to "true" if you don't set it explicitly. To implement this you'd need to run "mvn help:effective-pom -Doutput=effective-pom.xml" prior to scanning your project.
gjd6640
commented
6 years ago
I'm testing a new plugin version that adds a cross-file check. It works like this:
Rule: Builds compiled to target Java 8 must not be executed on older JVM versions to avoid bugs triggerFilePattern: /pom.xml triggerExpression: .1.8 .
disallowFilePattern: _/start.sh
disallowExpression: ._jdk1.(6|7).
Any matches of the "disallow" criteria will be raised as issues if and only if the trigger expression matched at least once.
Other possible uses:
This rule type can be run against files with any extension (last I checked extensionless files were problematic - I clone those and add .txtcpy to them before I scan) so in theory one could detect that a project uses a particular version of xerces (the trigger) and then look for java code that exercises functionality from that library that is known to have a problem such as a memory leak. There's no Java AST here so scanning complex content like XML or Java will be imperfect but it is possible.
Another similar example is failure to set the CachingConnectionFactory's consumer caching feature under Spring versions that offer it (2.5.6+). Generally we set that to false to avoid leaks unless there's a particular need for it and due diligence has been done to determine that it is safe to use / won't leak. I'm expecting people to forget to set it during Spring version upgrades and in those cases it'll silently turn on since it defaults to "true" if you don't set it explicitly. To implement this you'd need to run "mvn help:effective-pom -Doutput=effective-pom.xml" prior to scanning your project.