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

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

Closed
spring-issuemaster opened this issue Dec 23, 2016 · 7 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented Dec 23, 2016

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:

  • #19398 Add a functional way to register a bean
  • #19620 Kotlin extension for Web function API
  • #19615 Document functional configuration style

Referenced from: commits ff675f5

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 23, 2016

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 23, 2016

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 23, 2016

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 23, 2016

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 23, 2016

Sébastien Deleuze commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 26, 2016

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 26, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.