Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-15048

Kotlin extension for GenericApplicationContext with registerBean(KClass) variants

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 5.0 M4
    • Component/s: Core:DI
    • Labels:
    • Last commented by a User:
      false

      Description

      Following up on the GenericApplicationContext revision in SPR-14832, 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

          Activity

          Hide
          sdeleuze Sébastien Deleuze added a comment - - edited

          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.

          Show
          sdeleuze Sébastien Deleuze added a comment - - edited 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.
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          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!

          Show
          juergen.hoeller Juergen Hoeller added a comment - 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!
          Hide
          sdeleuze Sébastien Deleuze added a comment -

          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.

          Show
          sdeleuze Sébastien Deleuze added a comment - 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.
          Hide
          juergen.hoeller Juergen Hoeller added a comment - - edited

          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.

          Show
          juergen.hoeller Juergen Hoeller added a comment - - edited 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.
          Hide
          sdeleuze Sébastien Deleuze added a comment -

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

          Show
          sdeleuze Sébastien Deleuze added a comment - Awesome, thanks for your help. I will work on this Monday then.
          Hide
          sdeleuze Sébastien Deleuze added a comment - - edited

          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 SPR-15054) in order to provide a complete out of the box support for such functional Web application use case.

          Show
          sdeleuze Sébastien Deleuze added a comment - - edited 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 SPR-15054 ) in order to provide a complete out of the box support for such functional Web application use case.
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

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

          Show
          juergen.hoeller Juergen Hoeller added a comment - Sounds great! Let's make the Kotlin story as complete as we can for M4 and blog about it in January already.

            People

            • Assignee:
              sdeleuze Sébastien Deleuze
              Reporter:
              juergen.hoeller Juergen Hoeller
              Last updater:
              Stéphane Nicoll
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                38 weeks, 4 days ago