What I like in the "META-INF file" solution is that's:

• Not intrusive
• Will avoid some IDE and tooling integration issues compared to other solutions
• Allow each library to contribute its "open annotation" list without some custom configuration

We are ok to integrate such META-INF file directly in Spring Framework JAR.

Instead of listing every single annotation like @Service or @Configuration, if think that could be better to just identify classes annotated directly or indirectly by @Component (see Configuration annotated with @Component).

@sdeleuze

What I like in the "META-INF file" solution is that's:

• Will avoid some IDE and tooling integration issues compared to other solutions

Could you clarify? What issues do you mean?

• Allow each library to contribute its "open annotation" list without some custom configuration

Isn't such file an example of custom configuration?

Instead of listing every single annotation like @Service or @Configuration, if think that could be better to just identify classes annotated directly or indirectly by @Component (see Configuration annotated with @Component).

I see your point, and it's very appealing.

One problem: this brings the notion of "indirectly annotated" into the picture, and while it may be very obvious what that means for Spring, I'm not sure that it can be defined in a one-size-fits-all way. This speaks in favor of a compiler plugin where each framework could potentially define its own predicate using the full power of a programming language, not a restricted declarative format in META-INF.

One of my main concern is to make such behavior reliable and minimize the amount of customization for the end user.

I would like to avoid issues like the default open class behavior is taken in account by the Gradle/Maven but not the IDE. META-INF file solution is maybe a kind of custom configuration but it would be taken in account by any Kotlin 1.1 based compiler without any custom configuration at build tool level.

My remark about @Component is also about a similar concern, we have a lot of different @Component annotations is Spring projects, and users can define their own. So the ability to detect any kind of indirectly annotated @Component would make such support much more reliable.

If the chosen solution is a compiler plugin, what would be the requirement for us? Some kind of org.springframework.kotlin.CompilerPlugin class parameter added to the Gradle or Maven plugin configuration? Do you plan to bundle such class with Maven/Gradle Kotlin plugin in order to avoid requiring another plugin or do you expect us to provide it as an additional dependency?

I would like to avoid issues like the default open class behavior is taken in account by the Gradle/Maven but not the IDE. META-INF file solution is maybe a kind of custom configuration but it would be taken in account by any Kotlin 1.1 based compiler without any custom configuration at build tool level.

Fair point, a pro for the static config file is that it can be read with equal ease by all tools. Effectively, all tools would inherit this functionality from the compiler. I'm not entirely convinced that adding such (arguably ad hoc) things to the compiler is generally a good course to take.

My remark about @Component is also about a similar concern, we have a lot of different @Component annotations is Spring projects, and users can define their own. So the ability to detect any kind of indirectly annotated @Component would make such support much more reliable.

This is an important refinement of the initial requirements, we should probably think a little more about it.

If the chosen solution is a compiler plugin, what would be the requirement for us? Some kind of org.springframework.kotlin.CompilerPlugin class parameter added to the Gradle or Maven plugin configuration? Do you plan to bundle such class with Maven/Gradle Kotlin plugin in order to avoid requiring another plugin or do you expect us to provide it as an additional dependency?

I'd imagine that it should be something like apply plugin: "kotlin-spring" for Gradle, and not exactly sure what we can do for Maven, but we should definitely look more into it. Adding a <kotlin-spring/> tag somewhere would be ideal, IMO.

@abreslav Is that still expected to be available in Kotlin 1.1 ?

btw, solution "META-INF file` also provides ability to specify nullable/not-nullable annotation types. Some frameworks (for example vert.x) use their own annotations so they can supply such meta-inf file for better Kotlin compatibility

@abreslav Any estimation when we'll have this ..fixed''? I'd really like to apply shiny kotlin syntax to my projects. But it's a showstoppper for now as we are heavily using spring..

@sdeleuze @Writtscher We are currently working on a prototype with the following properties:

• there's a compiler plugin that takes a list of "all-open" annotation class names,
• annotated classes and their members and their descendants become open,
• annotated annotations are added to the "all-open" list.

This plugin will be available from the command line, and in build scripts we are planning to have plugins that configure a particular framework with more or less a one-liner, like

apply plugin: 'kotlin-spring'

If everything works out alright, this will ship in 1.0.x EAP soon enough (long before 1.1).

We also plan to do the same for no-arg constructors for JPA and other serialization frameworks.

I'll update the KEEPs accrodingly next week.

That's awesome news @abreslav thanks a lot!!!

Brilliant work, thanks a lot!
Can't wait to use it. Especially when migrating big java projects to kotlin (automatically) this would avoid many problems. :-)

Can I check if the proposed solution will work for tests run directly from IntelliJ? For instance for spring integration tests? As far as I know IntelliJ uses Kotlin compiler directly bypassing maven/gradle

@pbartoszek According to https://blog.jetbrains.com/idea/2016/10/intellij-idea-2016-3-eap-refactorings-to-java-8-vcs-integration-and-gradle/ this won't be an issue in IDEA 2016.3

@pbartoszek The IDE will run everything correctly after importing the settings from Gradle (as it routinely does for dependencies)

It looks like it's time to move from maven to Gradle :)

@pbartoszek We are planning to have the same support for Maven as well

Looking forward to the plugin as well... Definitely one of the reasons I've been holding off on trying kotlin for a spring project 😁

@abreslav apply plugin: 'kotlin-spring' made me cringe a bit. This is a problem faced by a wider dev community (not just spring). We're heavily invested in CDI/Weld and this is a pain point for us too. Meanwhile, with CDI when bean discovery mode is set to all in beans.xml, it is possible to not annotate the bean class at all and the CDI container treats it as @Default.

For such classes can we have a Kotlin annotation or keyword like this?
proxyable class MyBean { . . . }

@oluwasayo There will be a generic plugin that uses the list of "all-open" annotations provided by the user, as well as some plugins for the popular frameworks (such as "kotlin-spring").
Also, it will be easy to write the new Gradle/Maven plugin (as an "extension" for the generic one) for any other framework.

@yanex Awesome!