I understand your concern

What you probably have now is “spring-kotlin” language, which is slightly different from the Kotlin. And then something else, etc. It’s gonna be a mess.

The current issue we have is that we are forcing developers to make their code longer, less readable etc. because their class must be extended for technical reasons (that’s the way Spring and some other framework works, it has some pro and some con, but it is what it is and for goodr easons), not because the user want to extend these classes. The only 2 possible solutions I see are:

First solution, allow frameworks to technically extend these classes even if the user can’t, the compiler plugin is an attempt to do this. Maybe hackish, but at least it works.

Second solution:

Find a way to make that issue have less impact on code readability. Currently Spring developers are forced to put open keyword on classes + each method. Maybe a way to specify only at class level that he want this class and all its method to be open by default would be a nice compromise

That would keep Kotlin final default strategy, while lowering the pain by saying that a single time : I want the open behavior by default on this class.

Any thoughts?

Yes, we were considering something like

allopen

keyword on a class which makes it Java-like. It didn’t make the 1.0 cut, and there are numerous issues with that either. Like smart casts not working, because, well, it’s open and can return not-null now and then null.

A solution like

allopen

keyword would be nice.

The pain is really adding

open

everywhere again and again, just requiring one time at class level would be ok for Spring developers I think.

We understand the problem, and we discussed this a lot, we only didn’t come to a good solution. Hack is hack, it can work, but it’s not a language design… Anyway, the fact that I don’t like it is my personal opinion, and it won’t stop people from doing hacks simple smile

And did you discussed the

allopen

keyword solution?

Yes, we did. It opened a lot more questions and issues than it solved.

Prior to 1.0 we didn’t have enough time to find all answers, so we didn’t include it.

Since nobody seems to have found the perfect solution, I guess it is expected to see people trying to move forward with some workaround 😉

I have updated https://youtrack.jetbrains.com/issue/KT-12149 to reflect our discussion

Is there a link somewhere with the questions raised by

allopen

style keyword?

Nope, it was internal discussion.

Ok

@sdeleuze: Is there any reason not to use a load-/compile- time weaving approach as the main AOP mechanics at this case?

I really would like to avoid any agent based solutions like LTW approach, but we should eventually give compile time weaving approach a try indeed. I am not an Aspect guru but I will discuss that with Juergen and other Spring team members.

I wont complain, but to be honest, I would be happy to avoid any CGLIB approach that is a hijack by design, anywhere. But it's irrelevant to this discussion. 😆

Anyway, thanks for the idea, I have asked Juergen his advice on CTW, and I will make some tests

Yay 👍, let us know if there is such way. I'm still up here to think about the right way to solve the problem. I'll let you know if something out.

As far as I understand (not much AOP Java experience here), CTW will still need to open Kotlin final classes to do its work, no?

Nope, CTW is the streight and the simplest approach, ajc will compile from source and produce woven class files as output.

There is also post-compile weaving and load-time weaving, the first is used to weave existing class files and the second will operate over classes byte code using JVM TI and special "weaving class loaders" as well as the agent instrumentations

But, well, how ajc is going to compile Kotlin code?