Remove customResourceClass from @Controller

[s-soroosh]

Given that the ResourceController must implement io.javaoperatorsdk.operator.api.ResourceController<R extends CustomResource>, IMO getting the customResourceClass in io.javaoperatorsdk.operator.api.Controller is unnecessary and may cause inconsistencies, e.g. developer set a different class in annotation comparing with the one defined in Controller class definition.

I would suggest to remove the mentioned attribute from annotation and take the class type from the actual controller object.
e.g.

@Controller(
        generationAwareEventProcessing = false,
        crdName = TestCustomResourceController.CRD_NAME,
        **customResourceClass = TestCustomResource.class**)
public class TestCustomResourceController implements ResourceController<TestCustomResource>, TestExecutionInfoProvider {

will be come

@Controller(
        generationAwareEventProcessing = false,
        crdName = TestCustomResourceController.CRD_NAME)
public class TestCustomResourceController implements ResourceController<TestCustomResource>, TestExecutionInfoProvider {

[adam-sandor]

It's a good point that this could be simplified. I have worry, that we're currently working on Quarkus framework integration and native binary compilation. As this would need usage of reflection I think it wont work with Quarkus. Can you confirm @kirek007 ?

[s-soroosh]

It's a good point that this could be simplified. I have worry, that we're currently working on Quarkus framework integration and native binary compilation. As this would need usage of reflection I think it wont work with Quarkus. Can you confirm @kirek007?

I think a custom annotation which has @inherited and @RegisterForReflection on CustomResource class should do the job.

[kirek007]

@psycho-ir @adam-sandor
It would be great to move this direction but currently I'm facing troubles and had to bring back here even *Donable class definition because I can't make it work with native builds.

If we'll be able to make it work with native builds then we should simplify this.

[s-soroosh]

@psycho-ir @adam-sandor
It would be great to move this direction but currently I'm facing troubles and had to bring back here even *Donable class definition because I can't make it work with native builds.

If we'll be able to make it work with native builds then we should simplify this.

Thanks for feedback @kirek007, is the progress to build native images publicly available? I would be interested to learn how it works.

[kirek007]

Thanks for feedback @kirek007, is the progress to build native images publicly available? I would be interested to learn how it works.

Sure, Look here for code and more details: https://github.com/java-operator-sdk/basic-native-operator-example/tree/init
It's still early work but it compiles and works.. sometimes :)

[s-soroosh]

Thanks @kirek007,
I think we can overcome this technical issue with static code generation, I'll make a PoC tonight or tomorrow to see how it can help in practice.