-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using new features available in recent Java versions. #3053
base: main
Are you sure you want to change the base?
Conversation
@chwoerz Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@chwoerz Thank you for signing the Contributor License Agreement! |
import jakarta.persistence.metamodel.Attribute.PersistentAttributeType; | ||
import jakarta.persistence.metamodel.ManagedType; | ||
import jakarta.persistence.metamodel.SingularAttribute; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate this PR as a way to update some of our coding constructions, taking advantage of Java 17 features.
There is certainly a lot of noise generating in the re-ordering of import statements. I can deal with this, but for future PR's, you may want to look into adopting https://github.com/spring-projects/spring-data-build/blob/main/etc/ide/README.md. We have settings configured for both Eclipse and IntelliJ so that we all have the same import statement/static import policies, and avoid generating too much churn just from that.
@@ -71,7 +70,7 @@ | |||
* @author Thomas Darimont | |||
* @since 1.6 | |||
*/ | |||
public enum EntityGraphType { | |||
enum EntityGraphType { | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, don't alter visibility settings without first consulting with the team. We have a strict policy to avoid breaking changes and generally discuss changes in visibility before carrying them out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this modifier has been redundant here because the enum is declared inside an annotation definition. So, this is not a breaking change.
@@ -95,7 +94,7 @@ public enum EntityGraphType { | |||
|
|||
private final String key; | |||
|
|||
private EntityGraphType(String value) { | |||
EntityGraphType(String value) { | |||
this.key = value; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, don't alter visibility settings without first consulting with the team. We have a strict policy to avoid breaking changes and generally discuss changes in visibility before carrying them out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this modifier has been redundant here because the enum is declared inside an annotation definition. So, this is not a breaking change.
ctx.joinSpecifier().forEach(joinSpecifierContext -> { | ||
tokens.addAll(visit(joinSpecifierContext)); | ||
}); | ||
ctx.joinSpecifier().forEach(joinSpecifierContext -> tokens.addAll(visit(joinSpecifierContext))); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am usually a fan of shortening things like this, but since this is an ANTLR Visitor implementation, I actually prefer to retain it the way it is. It makes it easy when grammar tweaks require me to add another tokens.addAll(...)
inside that clause. And since this pattern is used A LOT in this class (and its counterpart), it becomes easier to maintain if I retain the pattern consistently everywhere.
tokens.addAll(visit(caseWhenExpressionClauseContext)); | ||
}); | ||
ctx.caseWhenExpressionClause() | ||
.forEach(caseWhenExpressionClauseContext -> tokens.addAll(visit(caseWhenExpressionClauseContext))); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am usually a fan of shortening things like this, but since this is an ANTLR Visitor implementation, I actually prefer to retain it the way it is. It makes it easy when grammar tweaks require me to add another tokens.addAll(...)
inside that clause. And since this pattern is used A LOT in this class (and its counterpart), it becomes easier to maintain if I retain the pattern consistently everywhere.
ctx.when_clause().forEach(whenClauseContext -> { | ||
tokens.addAll(visit(whenClauseContext)); | ||
}); | ||
ctx.when_clause().forEach(whenClauseContext -> tokens.addAll(visit(whenClauseContext))); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am usually a fan of shortening things like this, but since this is an ANTLR Visitor implementation, I actually prefer to retain it the way it is. It makes it easy when grammar tweaks require me to add another tokens.addAll(...)
inside that clause. And since this pattern is used A LOT in this class (and its counterpart), it becomes easier to maintain if I retain the pattern consistently everywhere.
ctx.simple_when_clause().forEach(simpleWhenClauseContext -> { | ||
tokens.addAll(visit(simpleWhenClauseContext)); | ||
}); | ||
ctx.simple_when_clause().forEach(simpleWhenClauseContext -> tokens.addAll(visit(simpleWhenClauseContext))); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am usually a fan of shortening things like this, but since this is an ANTLR Visitor implementation, I actually prefer to retain it the way it is. It makes it easy when grammar tweaks require me to add another tokens.addAll(...)
inside that clause. And since this pattern is used A LOT in this class (and its counterpart), it becomes easier to maintain if I retain the pattern consistently everywhere.
.collect(StreamUtils.toUnmodifiableSet())); | ||
|
||
this.jpaEmbeddables = Lazy.of(() -> metamodel.getEmbeddables().stream() // | ||
.map(ManagedType::getJavaType) | ||
.filter(it -> it != null) | ||
.map(ManagedType::getJavaType).filter(Objects::nonNull) | ||
.filter(it -> AnnotatedElementUtils.isAnnotated(it, Embeddable.class)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please put a line comment at the end of the map
operation, so that the filter
stays on its own line.
return false; | ||
return manufacturerId != null ? manufacturerId.equals(itemId.manufacturerId) : itemId.manufacturerId == null; | ||
return Objects.equals(manufacturerId, itemId.manufacturerId); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a new template for equals
at https://github.com/spring-projects/spring-data-build/blob/main/etc/ide/IntelliJ.equals-template.txt, which I'll run this by, to ensure we are compliant.
return false; | ||
return site != null ? site.equals(that.site) : that.site == null; | ||
return Objects.equals(site, that.site); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a new template for equals
at https://github.com/spring-projects/spring-data-build/blob/main/etc/ide/IntelliJ.equals-template.txt, which I'll run this by, to ensure we are compliant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I need you to undo the changes in all the import statements. As it currently stands, the number of changes in this PR generates more work for us than the benefit it derives. If you reduce the volume of changes and focus on the REAL tweaks, then I'd be more open to processing in.
52ee55f
to
61e6d36
Compare
I have applied the features available in new Java-versions by analyzing the files in IntelliJ.