Hi, @snicoll @poutsma
Issue Description
Package org.springframework.expression, org.springframework.core are a promiscuous package, and groups together miscellaneous functionalities that might be useful to different subsystems. The package structure violates the “high cohesion and low coupling” design rules. I found that Class Operation, SpringVersion is not used by classes in their package. The project has grown larger, leading to becoming increasingly hard to maintain. During the development process, one groups together classes (that often co-change) with similar responsibilities in one package to facilitate maintenance, which prevents a change that causes other packages to be modified. For example, if one modifies package org.springframework.expression (i.e., package rename), resulting in multiple classes of package org.springframework.expression.spel.ast to be changed.
Location: The source file can be found at path File spring-expression/src/main/java/org/springframework/expression/Operation.java spring-core/src/main/java/org/springframework/core/SpringVersion.java
Refactoring suggestions
I suggest to move class Operation into package org.springframework.expression.spel.ast, class SpringVersion into package org.springframework.lang.
Comment From: poutsma
We strive to maintain backwards compatibility in Spring Framework, even between major release. And because of the migration to Jakarta artefacts in the upcoming version 6.0, we do have more options with regard to refactoring than we typically do.
But moving Operation and SpringVersion to a different package is still going to upset people dependant on those types. With so many projects dependant on Spring, we can only make breaking changes like that with a very good reason. I don't think the violation of a coupling rule is a good enough reason.