This commit picks up where the two previous commits left off.
Specifically, this commit:
- Removes the "severity=warning" configuration to ensure that violations
actually fail the build.
- Fixes regular expressions for suppressions by matching forward
slashes using `[\\/]` instead of `\/`.
- Moves the configuration for newly introduced checks to locations in
checkstyle.xml that align with the existing organization of that file.
- Renames the IDs for RegexpSinglelineJava checks from
javaDocPackageNonNullApiAnnotation/javaDocPackageNonNullFieldsAnnotation
to packageLevelNonNullApiAnnotation/packageLevelNonNullFieldsAnnotation,
respectively, since these checks are not related to Javadoc.
- Simplifies the null-safety annotation checks to match against
imported annotation types, which enforces consistency across
package-info.java files for the annotation declarations.
- Simplifies the RegEx for JavadocPackage suppressions to only exclude
packages not under src/main/java (vs src/main) and those in the
framework-docs module.
- Consistently suppresses all checks for the `asm`, `cglib`, `objenesis`,
and `javapoet` packages in spring-core.
- Adds explicit suppressions for null-safety annotations for the `lang`
package in spring-core.
- Adds explicit suppressions for null-safety annotations for the
`org.aopalliance` package in spring-aop.
- Revises the RegEx for null-safety annotation suppressions to only
exclude package-info.java files not under src/main/java and
additionally to exclude package-info.java files in the framework-docs
module as well as those in the spring-context-indexer,
spring-instrument, and spring-jcl modules.
- Adds all missing package-info.java files.
- Adds null-safety annotations to package-info.java files where
appropriate.
Closes gh-30069
In order to be able to use text blocks and other new Java language
features, we are upgrading to a recent version of Checkstyle.
The latest version of spring-javaformat-checkstyle (0.0.28) is built
against Checkstyle 8.32 which does not include support for language
features such as text blocks. Support for text blocks was added in
Checkstyle 8.36.
In addition, there is a binary compatibility issue between
spring-javaformat-checkstyle 0.0.28 and Checkstyle 8.42. Thus we cannot
use Checkstyle 8.42 or higher.
In this commit, we therefore upgrade to spring-javaformat-checkstyle
0.0.28 and downgrade to Checkstyle 8.41.
This change is being applied to `5.3.x` as well as `main` in order to
benefit from the enhanced checking provided in more recent versions of
Checkstyle.
Closes gh-27481
Introduces a configure method pattern for Supplier-style configuration and a common SingletonSupplier decorator for method reference suppliers. Also declares jcache.config and jcache.interceptor for non-null conventions.
Issue: SPR-17021
Update all classes so that inner classes are always last. Also
ensure that utility classes are always final and have a private
constructor and make exceptions final whenever possible.
Issue: SPR-16968
This commit also removes nullability from two common spots: ResolvableType.getType() and TargetSource.getTarget(), both of which are never effectively null with any regular implementation. For such scenarios, a non-null empty type/target is the cleaner contract.
Issue: SPR-15540
The `CacheResolver` and `ErrorHandler` features introduced in 4.1 were
not properly enabled in AspectJ mode. This commit adds more tests from
the regular proxy-based mode and align the AspectJ caching configuration.
Issue: SPR-14413
Previously, if a `@Cacheable` method was accessed with the same key by
multiple threads, the underlying method was invoked several times instead
of blocking the threads while the value is computed. This scenario
typically affects users that enable caching to avoid calling a costly
method too often. When said method can be invoked by an arbitrary number
of clients on startup, caching has close to no effect.
This commit adds a new method on `Cache` that implements the read-through
pattern:
```
<T> T get(Object key, Callable<T> valueLoader);
```
If an entry for a given key is not found, the specified `Callable` is
invoked to "load" the value and cache it before returning it to the
caller. Because the entire operation is managed by the underlying cache
provider, it is much more easier to guarantee that the loader (e.g. the
annotated method) will be called only once in case of concurrent access.
A new `sync` attribute to the `@Cacheable` annotation has been addded.
When this flag is enabled, the caching abstraction invokes the new
`Cache` method define above. This new mode bring a set of limitations:
* It can't be combined with other cache operations
* Only one `@Cacheable` operation can be specified
* Only one cache is allowed
* `condition` and `unless` attribute are not supported
The rationale behind those limitations is that the underlying Cache is
taking care of the actual caching operation so we can't really apply
any SpEL or multiple caches handling there.
Issue: SPR-9254
Previously, cache transaction managers may be retained outside the
boundaries of an application context with AspectJ since an aspect is
basically a singleton for the current class loader.
This commit adds a "clearTransactionManagerCache" that is similar to the
"clearMetadataCache" introduced in CacheAspectSupport: whenever the
context is disposed, the cache is cleared to remove any reference to a
transaction manager defined by that context.
Issue: SPR-12518
This commits complements 222d2b1 for another required dependency.
javax.persistence.Entity was previously required, regardless of which
aspects were actually used by the project. It is now optional and will
not break the build if it is not present. Note that the side effect is that
AnnotationDrivenStaticEntityMockingControl is disabled as well if the
JPA API is not available.
Issue: SPR-6819
Prior to this commit, a project using compile time weaving upgrading to
4.1 was forced to add spring-context-support and the jcache API in order
to build. This problem is not new really: spring-aspects holds all
aspects provided by the framework and they all are evaluated when
compiling. 4.1 just happens to define a new aspect that requires extra
dependencies.
This commit uses a new annotation of AspectJ 1.8.3. When @RequiredTypes
is added on an aspect, it is evaluated only if the classes defined on the
annotation are actually present. If they are not, the aspect is disabled
and does not break the build.
Issue: SPR-12163
