Skip to content
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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

chwoerz
Copy link

@chwoerz chwoerz commented Jul 5, 2023

I have applied the features available in new Java-versions by analyzing the files in IntelliJ.

  • You have read the Spring Data contribution guidelines.
  • You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
  • You submit test cases (unit or integration tests) that back your changes.
  • You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

@pivotal-cla
Copy link

@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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jul 5, 2023
@pivotal-cla
Copy link

@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;

Copy link
Contributor

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 {

Copy link
Contributor

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.

Copy link
Contributor

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;
Copy link
Contributor

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.

Copy link
Contributor

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)));

Copy link
Contributor

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)));

Copy link
Contributor

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)));

Copy link
Contributor

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)));

Copy link
Contributor

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))
Copy link
Contributor

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);
}
Copy link
Contributor

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);
}
Copy link
Contributor

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.

@gregturn gregturn added status: waiting-for-feedback We need additional information before we can continue and removed status: waiting-for-triage An issue we've not yet triaged labels Jul 6, 2023
Copy link
Contributor

@gregturn gregturn left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-feedback We need additional information before we can continue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants