Kotlin extension for GenericApplicationContext with registerBean(KClass) variants [SPR-15048]

[spring-projects-issues]

Juergen Hoeller opened SPR-15048 and commented

Following up on the GenericApplicationContext revision in #19398, let's consider creating a dedicated GenericKotlinApplicationContext subclass with registerBean(KClass) variants or Kotlin extensions to GenericApplicationContext itself with the same method variations.

---

Issue Links:

• Add a functional way to register a bean [SPR-14832] #19398 Add a functional way to register a bean
• Kotlin extension for Web function API [SPR-15054] #19620 Kotlin extension for Web function API
• Document functional configuration style [SPR-15049] #19615 Document functional configuration style

Referenced from: commits ff675f5

[spring-projects-issues]

Sébastien Deleuze commented

Juergen Hoeller Instead of creating a dedicated GenericKotlinApplicationContext, what about providing the same kind of extensions I created here builtin with Spring JARs to provide these additional methods?

From a Kotlin developer POV, that would allow to write exactly the same code, but without requiring us to create a parallel class hierarchy for Kotlin additional methods. And extensions are really widely used in Kotlin, they are not perceived as less natural or second class support. They are statically resolved, you have to import them to have the additional methods, but the IDE make a very good job to auto import them when needed.

2 additional avantages I can see: this will make these additional methods available in every class extending GenericApplicationContext like AnnotationConfigApplicationContext and that will allow us to provide extension like KClass variants in many other places (WebClient, RestTemplate, functional web framework) in a consistent way without having to create Kotlin specific wrappers.

[spring-projects-issues]

Juergen Hoeller commented

Good point, and as long as they are aligned with the existing registerBean methods on GenericApplicationContext, they are not sneaking a new concept into that existing class either... rather just variants of existing methods with KClass arguments. So yes, sounds good to me; let's try to ship those Kotlin extensions in M4 then!

[spring-projects-issues]

Sébastien Deleuze commented

Ok perfect :-)

The tricky part will be to disable conditionally the kotlin compiler to avoid breaking JDK9 builds since https://youtrack.jetbrains.com/issue/KT-14988 is not fixed yet on Kotlin side. Do you think this is something doable? I will have a look myself but I just want to raise the point in case you have some thought about the feasibility.

[spring-projects-issues]

Juergen Hoeller commented

It looks like conditional apply statements for a plugin actually work:

if (!JavaVersion.current().java9Compatible) {
	apply plugin: "kotlin"
}

I've just tried it with our test sources but I guess it'll also work for regular resources.

[spring-projects-issues]

Sébastien Deleuze commented

Awesome, thanks for your help. I will work on this Monday then.

[spring-projects-issues]

Sébastien Deleuze commented

Implemented via this commit.

I used Kotlin extensions nested in an object container to provide a scalable way to organize such extensions without risking naming conflicts.

IDEA currently fails to suggest automatically these extensions due some limitation on extension detection, so I have created KT-15440 to ask some improvements.

Mix-IT website has been updated to use directly these extensions instead of its own.

Juergen Hoeller If you are ok with that, I suggest adding for M4 similar extensions for Web functional client and server (see #19620) in order to provide a complete out of the box support for such functional Web application use case.

[spring-projects-issues]

Juergen Hoeller commented

Sounds great! Let's make the Kotlin story as complete as we can for M4 and blog about it in January already.