Btw, just want to share, I once saw an agent that called "Signatures" or something like this. Tricky and beautiful in some way. The agent is designed to provide synthetic interface that depicts all public methods of the class for each class within instrumented classloader. So that in such runtime each object have an indirect "signature" interface that bound to this object. I have no idea how the agent makes changes for a references type (fields, variables, parameters), but it's works somehow, at such runtime each reference have a type of synthetic "signature" interface, and a whole graph of objects is build over such interfaces.

I made some tests with

spring-aspects

with compile-time weaving or load-time weaving but even if this is possible for some specific Spring fonctionalities (transaction, cache, security), this is not supported for some other features including Spring Boot configuration, and it is VERY difficult to get all the tooling (IDE, build tool) working as expected

So, I think we are back to 2 solutions to support CGlib proxies

The one that seems to cleanest is to make Kotlin supporting

allopen

keyword

Maybe I could create an issue in https://github.com/Kotlin/KEEP to discuss this

The other one, more hackish, is to create IDEA, Maven and Gradle plugin for https://github.com/yanex/AutoOpen

If somebody has an idea for a better name than

allopen

, feel free to submit a better name

(I am not a huge fan of this name)

Any thoughts @jkschneider ?

for the reasons cited in Andrey’s blog post on the subject of default finality (https://discuss.kotlinlang.org/t/a-bit-about-picking-defaults/1418), most notably smart casting of closed vals, i think it is best if kotlin classes remain closed by default from the perspective of the source and the initial compilation step

i think we just need a way to influence the bytecode after that initial compilation step, which is why i’d like to see kapt support in JPS or a more generalized compile-time metaprogramming facility

…and there are other reasons i want that metaprogramming facility, i.e. so i can build diagrammed assertions (a.k.a. power assertions) into kotlin

is your test work on spring-aspects somewhere public @sdeleuze?

@jkschneider: I will push a branch of geospatial-messenger later yes, I need to finish my tests to be 100% sure that is not possible currently

Did you have a look to https://github.com/yanex/AutoOpen ?

this is the project you are building up for your spring-io talk?

As kapt alternative ?

Yes simple smile

yes, the author wrote it in respose to andrey’s blog post, he first mentioned it here: https://discuss.kotlinlang.org/t/classes-final-by-default/166?page=2

the kapt solution more or less works the same way, but doesn’t require you to have a jar first… so if we were going to hack the ide to add compiler flags, i’d rather hack it to just run kapt

JB folks might not be too opposed to building into JPS, i think they just hadn’t yet imagined a use case for it

I think the author said it was not possible with kapt to do what we need

respectfully disagree 😉

Ok 😉

But kapt solution would make the class

open

for real no ?

I mean not throwing an error if a user extend this

@Service

class for example

nope, same solution, just stripping ACC_FINAL in the bytecode

Ok

Do you have a POC somewhere ?