Spring Data 团队于 2025 年 3 月 14 日发布了 Spring Data 2025.0.0 的第二个里程碑版本（M2）

本文链接：https://blog.csdn.net/blog_programb/article/details/106173241

Spring Source宣布发布了多个Spring Data模块的GA版本，包括Spring Data Commons 1.4、Spring Data JPA 1.2等。此次发布强调了跨项目兼容性和JavaConfig支持，改进了XML命名空间并引入了注解支持。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Spring Data 2025.0.0-M2 发布

Spring Data 团队于 2025 年 3 月 14 日发布了 Spring Data 2025.0.0 的第二个里程碑版本（M2）。以下是该版本的主要特性：

新特性与改进

接口投影（Interface Projections）：
- 现在接口投影会正确地抛出 NullPointerException，如果方法返回值为 null（例如 getter 方法），尽管方法被定义为返回非空值。此功能默认对所有 Kotlin 接口启用。对于其他接口，当包或接口被注解为非空（或继承了包级别的 @NonNullApi）时，会启用验证。
Spring Data Redis：
- 增加了对 Redis 哈希字段过期的支持。
- 扩展了过期命令支持。
- 支持 GET … SET 操作。
MongoDB 验证回调：
- 引入了 ValidatingEntityCallback 和响应式变体 ReactiveValidatingEntityCallback，允许在响应式流程中使用 Bean 验证。回调必须注册为 beans 才能启用其使用。
MongoDB 的 BigDecimal 和 BigInteger 存储方式变更：
- 允许用户将存储 BigDecimal 和 BigInteger 的默认方式从 String 更改为 Decimal128。MongoDB 的下一个主要版本将默认切换到 Decimal128，并弃用基于 String 的表示。

发布计划

团队计划在 2025 年 4 月发布候选版本（RC），并在 5 月发布通用可用版本（GA）。
Spring Boot 3.5 M3 将升级到此里程碑版本，以便开发者更方便地使用。

模块版本

以下是 Spring Data 2025.0.0-M2 包含的模块及其版本：

Spring Data Commons 3.5 M2
Spring Data JPA 3.5 M2
Spring Data MongoDB 4.5 M2
Spring Data Neo4j 7.5 M2
Spring Data for Apache Cassandra 4.5 M2
Spring Data KeyValue 3.5 M2
Spring Data LDAP 3.5 M2
Spring Data REST 4.5 M2
Spring Data Redis 3.5 M2
Spring Data Elasticsearch 5.5 M2
Spring Data Couchbase 5.5 M2
Spring Data Relational 3.5 M2

下一步

团队鼓励开发者尝试此版本，并提供反馈，特别是如果遇到任何问题。

Spring Data 2025.1.0-M1 发布

此外，Spring Data 团队还于 2025 年 1 月 24 日发布了 Spring Data 2025.1.0 的第一个里程碑版本（M1）。该版本的主要特性包括：

提高了对 Jakarta EE 11 和 Kotlin 2.x 的支持。
对 Spring Data JPA 进行了重大修订，包括使用 JPQL 进行派生查询，从而显著提高了查询执行性能。
引入了 PredicateSpecification、UpdateSpecification 和 DeleteSpecification 等变体，以优化 Specifications 的安排。
提供了对 JSpecify 空值注解的早期支持。

该版本的通用可用版本（GA）计划于 2025 年 11 月发布。

总结

Spring Data 2025.0.0-M2 和 2025.1.0-M1 的发布为开发者提供了新的特性和改进，帮助他们更好地利用 Spring Data 构建现代应用程序。团队将继续收集社区反馈，并计划在 2025 年 5 月和 11 月分别发布通用版本。

Spring Data Release Train Arrived 是 Spring Data 项目的一个重要里程碑，标志着多个 Spring Data 模块的正式发布（GA 版本）。这一发布模式被称为“发布列车”（Release Train），旨在确保各个模块之间的兼容性和一致性，同时为开发者提供一套完整的工具集，用于处理现代持久化技术。以下是关于这一发布的核心内容：

发布列车的背景与意义

统一发布模式
Spring Data 发布列车将多个模块（如 Spring Data JPA、Spring Data MongoDB 等）打包在一起，确保它们基于相同的 Spring Data Commons 版本，从而避免兼容性问题。
命名规则
发布列车采用著名计算机科学家的名字作为代号，例如“Arora”和“Babbage”，以方便开发者识别和记忆。
兼容性与稳定性
通过发布列车模式，Spring Data 团队能够更好地管理模块之间的依赖关系，确保每个版本都经过充分测试和验证。

主要特性与改进

注解驱动的审计支持
引入了 @CreatedDate、@CreatedBy 等注解，简化了实体审计功能的实现。
Spring Data Mapping 增强
改进了映射信息的暴露方式，支持从访问器方法中读取映射信息，提升了灵活性和可扩展性。
Spring 4 和 JDK 8 兼容性
在 Spring Data Core 中进行了优化，确保与 Spring 4 和 JDK 8 的兼容性，并将这些改进扩展到所有模块。
分页 API 扩展
增强了 Pageable 和 Page API，提供了更强大的分页功能。

如何使用发布列车

Maven 配置
在 pom.xml 中指定发布列车的版本号，例如：
```
<properties>
    <spring-data-releasetrain.version>Arora</spring-data-releasetrain.version>
</properties>
```
这样可以确保所有 Spring Data 模块使用兼容的版本。
模块选择
开发者可以根据项目需求选择所需的模块，例如 Spring Data JPA、Spring Data MongoDB 等，并确保它们属于同一发布列车。

发布列车的历史与发展

早期发布
发布列车模式最初在“Arora”版本中引入，随后在“Babbage”版本中进一步优化。
后续演进
Spring Data 团队持续改进发布列车模式，增加了对新技术的支持（如 JDK 8 和 Spring 4），并扩展了功能集。

总结

Spring Data 发布列车模式为开发者提供了一种高效、稳定的方式来管理和使用 Spring Data 模块。通过统一的版本管理和命名规则，开发者可以更轻松地构建基于现代持久化技术的应用程序。如果您想了解更多细节，可以参考 Spring Data 官方文档或相关博客文章。
It’s a pleasure to announce that we have just released the GA versions of a variety of Spring Data modules. With this release we continue to manifest the commitment of SpringSource to provide Java developers with tools to work with state-of-the-art persistence technologies. In this blog post I’d like to give you detailed insight into what the release includes, why we decided for a release train and a brief outlook into what the next steps on the Spring Data roadmap are.
The release train

Looking back at the way Spring Data modules were developed, release cycles were usually managed by the individual module leads. Given the different pace and maturity of the modules this caused some issues when trying to work with multiple modules at once. Especially the projects depending on Spring Data Commons were suffering from this problem.

We were working hard on minimizing these issues but eventually came to the conclusion that it makes sense to coordinate the releases much more and sync up minor releases of the modules. The general Spring Data release now ships with the following participants:

Spring Data Commons 1.4

Spring Data JPA 1.2

Spring Data MongoDB 1.1

Spring Data Neo4j 2.1

Spring Data Gemfire 1.2

Spring Data REST exporters 1.0

Moving forward we will continue to sync up the releases of upcoming minor versions. Still modules are free to do bug fix releases at their own pace.
What’s in this release

As just outlined, the core theme of the release is the cross-project compatibility. Besides this rather non-functional one the most important feature probably is the JavaConfig support for Spring Data repositories. We improved the XML namespace and introduced annotation support in Spring Data Commons to allow the integration of JavaConfig based repositories for store specific modules.

We introduce @Enable(Jpa|Mongo|Neo4j|Gemfire)Repositories that are 1:1 equivalents of the XML repositories namespace element. So what had to be configured like this in former versions (using JPA as example).

<jpa:repositories base-package=“com.acme.repositories” />

Can now be achieved in Spring JavaConfig configuration classes by using the @EnableJpaRepositories annotation.

@EnableJpaRepositories(base-package = “com.acme.repositories”)
class ApplicationConfig {

}

With this style of configuration we enable completely XML-free application configuration across the store implementations. More advanced examples of annotation configuration usage can be found in the sample code for the recently released Spring Data book written by the Spring Data team members. The code is on GitHub and uses all the new features of the latest Spring Data release as well as the most recent Spring 3.2 milestones. Consider this repository as a canonical sample repo for Spring Data related code samples going forward.

The integration of @Enable… annotations for repositories required us to raise the Spring dependency to the 3.1 line. Still all the rest of the codebase is fully compatible with the Spring 3.0 branch. So the modules shipped with the release all depend on Spring 3.1.2 by default. If you really need to work with 3.0.7, manually define the Spring dependency in your project’s pom.xml to enforce the older version to be used.
JPA

Besides the JavaConfig support for repositories the JPA module ships with a plethora of small but important improvements such as updates to the latest versions of persistence providers (Hibernate 3.6.10, EclipseLink 2.4.0). We pro-actively ensure compatibility with the Hibernate 4 branch but haven’t upgraded our dependency yet to not force users into an upgrade or manually configuring their projects down to Hibernate 3.
MongoDB

Amongst the released modules, the MongoDB is probably the one shipping with most new user-visible features. We improved the GridFS support so that you can now easily store and retrieve files into/from MongoDB by using the GridFsTemplate (see this section of the reference docs for details).

class MongoConfig extends AbstractMongoConfiguration {

// …

@Bean
public GridFsTemplate gridFsTemplate() {
return new GridFsTemplate(mongoDbFactory(), mappingMongoConverter());
}
}

class GridFsClient {

public static void main(String… args) throws Exception {
ApplicationContext context = new AnnotationConfigApplicationContext(MongoConfig.class);
GridFsOperations operations = context.getBean(GridFsOperations.class);

File file = new File("myfile.txt");
operations.store(file.getInputStream(), "myfile.txt");

GridFsResource[] txtFiles = operations.getResources("*.txt");

}
}

If you’d like to use Spring Data MongoDB from within a JavaEE 6 environment you can now do so as we ship a CDI extension that allows injecting a MongoDB based Spring Data repository into a CDI managed bean using @Inject (DATAMONGO-356).

Beyond that we’ve received two community contributions by Maciej Walkowiak and Patryk Wasik. Maciej implemented support for JSR-303 validation by leveraging the persistence events we trigger (DATAMONGO-36). Patryk enabled optimistic locking by adding an @Version annotation as well as the necessary tweaks to our persistence mechanism to throw an exception in case document modifications have been done behind ones back (DATAMONGO-279).
Neo4j

The Spring Data Neo4j added most notably support for unique entity creation. You can now annotate entity fields as @Indexed(unique=true) which will allow the Neo4j mechanisms for creating unique nodes and entities to kick in.

We also invested a lot in making working with relationships easier and more comprehensive, you can now populate and save relationship-entities in the same ways as node-entities. We also allow more fine-grained control of relationship-type. It can now also be set on the @RelationshipEntity(type=“REL_TYPE”) annotation or in a field annotated with @RelationshipType to be used on a per-instance basis. Due to popular demand, we now allow @RelatedToVia annotated fields to be constrained by target field type.

With this release the support for storing type-hierarchies in the graph was revamped so you can use @TypeAlias(“myType”) for saving precious space in properties and indexes. The polymorphic reads for aliased types now also work as expected.

An useful addition for audits, validation and other cross-cutting concerns are the new lifecycle events. Like in the other modules ApplicationContextListener can now listen for (Before|After)SaveEvents. We also refactored the internal infrastructure, so that you can now directly create a Neo4jTemplate around a GraphDatabaseService even without an application-context set-up.

Something we’ve put a lot of effort into, was improving the handling of user-defined or finder-method-derived cypher queries. This is an area that will also see a lot of investment in the future of the Spring Data Neo4j module. Spring Data Neo4j’s 2.1 release supports the recently released Neo4j 1.8 version and works with 1.7 as well.
Gemfire

The release of the Gemfire module includes a more advanced Spring namespace to more closely mimic the Gemfire cache configuration options and thus complete the Spring based programming model. It also ships with an implementation of the Spring Data repository abstraction to ease entity access and query execution just as you are used to from using other stores.

The Spring Data Gemfire module will also be shipped alongside the upcoming Gemfire 7.0 release to continue the mission to simplify developing Java applications using data grids.
REST exporter

Another important new addition to the portfolio of the Spring Data projects is the REST exporter. It allows to expose entities managed by Spring Data repositories via HTTP in a hypermedia driven way and allows triggering the execution of query methods defined.

All it takes is registering the RepositoryRestExporterServlet in your application or let your Spring MVC DispatcherServlet configuration include the RepositoryRestMvcConfiguration JavaConfig class. By default, this will cause a resource exposed for every Spring Data repository in your application context. The resources can be discovered by following links exposed in a core resource.

Assuming you have two repository interfaces CustomerRepository and ProductRepository. You can now go ahead and add the following setup code to your Servlet 3 WebApplicationInitializer:

DispatcherServlet servlet = new RepositoryRestExporterServlet();
Dynamic dispatcher = container.addServlet(“dispatcher”, servlet);
dispatcher.setLoadOnStartup(1);
dispatcher.addMapping(“/”);

Running the app inside e.g. Jetty will give you this:

$ curl -v http://localhost:8080

{ “links” : [ {
“rel” : “product”,
“href” : “http://localhost:8080/product”
}, {
“rel” : “customer”,
“href” : “http://localhost:8080/customer”
}]}

Clients can now follow these links to access products and customers, explore their relationships to other entities (hypermedia-driven in turn) and execute queries declared through query methods in there repository interfaces. Currently, only JPA based repositories are supported but we’re going to add support for all the other stores in upcoming versions.

There are detailed options to configure which resources and which HTTP methods get exposed, extension points to manipulate the returned representations with custom links to enrich your API beyond plain CRUD operations. To find out more about the project check out it’s reference documentation or the relevant chapter of the Spring Data book we wrote with O’Reilly (read more on that below).
Roadmap

The current release finalizes the development of the 1.x branch of Spring Data Commons, which is what all store implementations released alongside rely on. Going forward we’re going to concentrate on a first milestone of a 2.0 release to implement more advanced features and slightly changes some core things that will probably require API changes and adaptions to the programming model. This includes a common auditing mechanism (currently only available in the JPA module) as well as more flexibility in the interface based repository abstraction.

Besides the store implementation modules lead by SpringSource employees we’re starting to see implementations lead by the community popping up recently. Neale Upstone has just released version 1.0 of the FuzzyDB module and the Spring Data Solr module led by Christoph Strobl is close to a first milestone.

If there’s any feature you’d like to see in Spring Data modules, any feedback to the existing ones, now is the time to raise your voice in the the Spring JIRA.
Miscellaneous

The last thing I’d like to point you to is the Spring Data support in STS that has been introduced in the 3.0 version. When editing a Spring Data repository you’ll now get query method validation right in place as you can see below.

Query method validation

Beyond that you also get code completion support when composing query methods.

Code completion support for query methods

If this blog post is your first contact with the Spring Data project or you’d like to get started with the project in general I highly recommend taking a look at the O’Reilly Spring Data book we wrote. It’s a pragmatic introduction into state-of-the art Java persistence, the Spring Data project in general and its core design principles. It introduces the store-specific modules with hands on examples and detailed explanations of the sample code provided alongside the book. Attendees of the SpringOne2GX conference that just started will receive a free copy of the PDF version of the book.
Summary

Over the development time of 8 months we have fixed almost 300 tickets. Special thanks go out to Michael Hunger and Lasse Westh-Nielssen from Neo Technologies for driving the Neo4j module, David Turanski and Costin Leau for their work on the Spring Data Gemfire module, Jon Brisbin for leading the REST exporter module, Mark Pollack for the overall project lead as well as all other Spring Data team members for their support. Special thanks to everyone in the Spring Data community for their extremely valuable feedback through the JIRA and the forums as well as their pull requests on GitHub that helped actually getting even more features into the release.

如果这篇博文是你第一次接触Spring数据项目，或者你想开始这个项目，我强烈建议你看看我们写的O’Reilly Spring数据手册。这是对最先进的Java持久性、Spring数据项目及其核心设计原则的实用介绍。它介绍了特定于商店的模块，并提供了实例和本书附带的示例代码的详细说明。刚刚开始的SpringOne2GX会议的与会者将收到该书PDF版本的免费副本。
摘要
经过8个月的开发，我们已经修复了近300张门票。特别感谢Neo Technologies的Michael Hunger和Lasse Weth Nielssen驾驶Neo4j模块，David Turanski和Costin Leau在Spring Data Gemfire模块上的工作，Jon Brisbin领导其余的exporter模块，整个项目负责人的Mark Pollack以及所有其他Spring数据团队成员的支持。特别感谢Spring数据社区中的每个人，感谢他们通过JIRA和论坛提供的非常有价值的反馈，以及他们在GitHub上的pull请求，这些请求实际上有助于将更多功能引入到发布中。
在这里插入图片描述