Senior Software Engineer at Noom, formerly Team Lead Engineering at XING. I intend to write about functional programming and occasionally some random engineering topic.
I'd also suggest to use that plugin. It doesn't just blindly open all the classes, but only those with certain annotations such as @Service, @Component...
I'd argue it's worse to put open in classes that aren't supposed to be, as those welcome maintainers to potentially subclass them, which could have worse consequences. At the end of the day, the issue here is not Kotlin but Spring doing black magic from behind.
Oh, I knew about all-open, so now there's another one specific for Spring? Okay, I'll have a second look at it.
Well it's a very unfortunate combination of Kotlin doing its thing, and Spring doing its thing. Plus, Spring should throw an exception if this case is encountered (code simply breaks if it is final, this is not a use case that needs to be preserved). But in general I agree: bytecode generation has a bad smell to it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd also suggest to use that plugin. It doesn't just blindly open all the classes, but only those with certain annotations such as @Service, @Component...
I'd argue it's worse to put
openin classes that aren't supposed to be, as those welcome maintainers to potentially subclass them, which could have worse consequences. At the end of the day, the issue here is not Kotlin but Spring doing black magic from behind.Oh, I knew about
all-open, so now there's another one specific for Spring? Okay, I'll have a second look at it.Well it's a very unfortunate combination of Kotlin doing its thing, and Spring doing its thing. Plus, Spring should throw an exception if this case is encountered (code simply breaks if it is
final, this is not a use case that needs to be preserved). But in general I agree: bytecode generation has a bad smell to it.