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

Add Transient annotation to private accessor methods #425

Merged
merged 23 commits into from
May 6, 2024

Conversation

evie-lau
Copy link
Contributor

@evie-lau evie-lau commented Feb 22, 2024

What's changed?

OpenJPA -> EclipseLink recipe
Add @Transient annotation to private accessor methods

What's your motivation?

https://wiki.eclipse.org/EclipseLink/Examples/JPA/Migration/OpenJPA/Mappings#Private_Accessor_Methods

Anything in particular you'd like reviewers to focus on?

Question for this recipe, and maybe even all the other EclipseLink migration recipes...
Do all the JPA migration recipes require the class being tagged with @Entity or some JPA annotation? @cjobinabo

Checklist

  • I've added unit tests to cover both positive and negative cases
  • I've read and applied the recipe conventions and best practices
  • I've used the IntelliJ IDEA auto-formatter on affected files

@evie-lau evie-lau added the recipe Recipe requested label Feb 22, 2024
@evie-lau evie-lau self-assigned this Feb 22, 2024
*/
private boolean methodReturnsFieldFromClass(J.Return returnStatement) {
J.ClassDeclaration classDecl = getCursor().dropParentUntil(parent -> parent instanceof J.ClassDeclaration).getValue();
JavaType.Variable returnedVar = ((J.Identifier)returnStatement.getExpression()).getFieldType();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about matching on the field type here ; I'd expect we'd want to match that the identifier or accessed field name are the same as what's returned.

Copy link
Contributor Author

@evie-lau evie-lau Feb 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seemed like the Identifier sometimes had different object numbers when I was debugging, but getting it's FieldType object always matched up (which also contains the variable name).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the return expression can be a lot of things, but I imagine we'd only want to add an annotation when it's exactly an identifier or field access that references a field in the surrounding class; I think that were we were headed already right?

Copy link
Contributor Author

@evie-lau evie-lau Feb 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For visual reference:
image
The J.Identifier object (name) didn't match up between the class's field Identifier and the method's returned Identifier. simpleName and fieldType were the highest level matches I found, and comparing the objects seemed like a better choice than comparing strings.

@evie-lau evie-lau marked this pull request as ready for review February 26, 2024 17:42
@evie-lau evie-lau requested a review from cjobinabo February 26, 2024 18:37
evie-lau and others added 2 commits April 10, 2024 14:37
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
github-actions[bot]

This comment was marked as resolved.

timtebeek and others added 2 commits April 26, 2024 11:10
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@evie-lau evie-lau requested review from cjobinabo and timtebeek May 3, 2024 19:01
}

@Test
void doNotChangePublicOrProtectedGetter() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec and tests don't seem to mention package private cases. Would we want to make explicit what we do with those in the tests? Right now it seems we only change private cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think since the spec doesn't mention it, it may be best to only stick with the explicit private case.

Comment on lines 101 to 107
if (expression instanceof J.FieldAccess) {
return ((J.FieldAccess) expression).getName().getFieldType();
} else if (expression instanceof J.Identifier) { // ie: return field;
return ((J.Identifier) expression).getFieldType();
} else {
return null;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a way we're iterating over returns twice; first as we visit each return, and then again to extract the returned field type; would it make sense to fold those into one by doing this extract in the visitor just above?

Copy link
Contributor Author

@evie-lau evie-lau May 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch, will update to do that. Also I noticed that I'm collecting the class variables in each method, so I'll extract that to a higher scope variable to be reused.

Copy link
Contributor

@timtebeek timtebeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved already, and you're welcome to merge as is; I just had two small suggestions that I'd like your thoughts on, but they are not a requirement to address before we merge.

Copy link
Contributor

@cjobinabo cjobinabo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @timtebeek for helping me review this. Thanks @evie-lau for making these updates.

@cjobinabo cjobinabo merged commit bc8e2f7 into openrewrite:main May 6, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
recipe Recipe requested
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants