Skip to content

Conversation

@Zegveld
Copy link
Contributor

@Zegveld Zegveld commented Oct 15, 2022

@filiphr do you know how to add a failure test for java 17+ situations?

Currently I've only added the happy flow situation to the integration test.

Fixes #3054

Comment on lines 453 to 457
permitted -> ctx
.getTypeUtils()
.isSameType(
permitted,
subClassOption.getSource() ) )
Copy link

Choose a reason for hiding this comment

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

I haven't played around with this, but would changing this check to be either the "same type" check or a recursive "isCorrectlySealed" check be enough to fully cover a sealed subtype hierarchy, rather than just the case where it's only one-level deep and only the direct subtypes are covered?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed I missed the hierarchy bit here.
This should be covered in the next commit where I've added a Motor that is extended by a Harley and Davidson using the sealed structure for the test. And in code it now checks recursively, but only if the sealed subtype is abstract.

@filiphr
Copy link
Member

filiphr commented Feb 5, 2023

@filiphr do you know how to add a failure test for java 17+ situations?

In order to achieve this we are going to need to use java 17 for our processor test suite. We used to have something like this back when we were supporting java 7. The pattern would be to use java17 in test suite packages and then make sure that the MavenIntegrationTest#fullFeatureTest ignores all packages with java17 when run with Java 8.

btw @Zegveld, I've been really busy with other things and haven't had the time to properly review things. I hope I can catch up soon.

@Zegveld
Copy link
Contributor Author

Zegveld commented Feb 5, 2023

@filiphr, no worries. I've been busy myself (and still am atm) so it will take a while before I have more time then a few minutes to look at things here myself.

Copy link
Member

@filiphr filiphr left a comment

Choose a reason for hiding this comment

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

I have some questions regarding the implementation. When you have some time have a look at my comments @Zegveld

Type mappingSourceType = method.getMappingSourceType();
return isCorrectlySealed( mappingSourceType );
}
catch ( Exception e ) {
Copy link
Member

Choose a reason for hiding this comment

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

What kind of an exception can happen here?

Copy link
Contributor Author

@Zegveld Zegveld Apr 22, 2023

Choose a reason for hiding this comment

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

good question, reading the code there should be no chance of an exception happening here when not java 17.

Copy link
Member

Choose a reason for hiding this comment

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

In that case let's remove the try catch. We should handle it properly if something throws an exception

Comment on lines 457 to 468
method.getOptions().getSubclassMappings().forEach( subClassOption -> {
unusedPermittedSubclasses
.stream()
.filter(
permitted -> ctx
.getTypeUtils()
.isSameType(
permitted,
subClassOption.getSource() ) )
.findFirst()
.ifPresent( unusedPermittedSubclasses::remove );
} );
Copy link
Member

Choose a reason for hiding this comment

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

I think that this would be more readable if we write in without streams. Perhaps use an iteratorfor removing from theunusedPermittedSubclasses`

@Zegveld Zegveld requested a review from filiphr April 27, 2023 16:55
@Zegveld
Copy link
Contributor Author

Zegveld commented Apr 27, 2023

I've made the wanted changes, and they were definitely an improvement.

@filiphr do you know how to add a failure test for java 17+ situations?
In order to achieve this we are going to need to use java 17 for our processor test suite.
So I guess this would become a new issue to move the processor test suite to java 17?
(And perhaps repeat this every time a java LTS version is released?)

@filiphr filiphr merged commit bc5a877 into mapstruct:main May 1, 2023
@filiphr
Copy link
Member

filiphr commented May 1, 2023

So I guess this would become a new issue to move the processor test suite to java 17?
(And perhaps repeat this every time a java LTS version is released?)

We don't need to do it now. Perhaps we can create an issue for when we change our LTS version. I am not sure how easy / difficult is to have the test suite with a different java version in Maven

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Do not require subclassExhaustiveStrategy when source is a sealed class and all subtypes are specified

3 participants