From what I understand that was just a Spring Boot default

In order to avoid loosing exception mapping if people don’t implement interfaces

See https://github.com/spring-projects/spring-framework/blob/master/spring-aop/src/main/java/org/springframework/aop/framework/DefaultAopProxyFactory.java#L50-L65

i’d still like to strive for something that performs the necessary bytecode manipulation to open Configuration classes, Repositories, etc as necessary without requiring any manual work/special knowledge, realizing that there is a perfectly reasonable workaround for now

I guess there is no issue providing multiple ways to the user and let him decide

I will try to see what is JetBrains feedback for

allopen

, please let me know if you succeed with the kapt approach

I improved my previous commit: https://github.com/sdeleuze/geospatial-messenger/commit/7262aaa3c1240d7a608f60dd8cf4f15173156142

Spring Boot is clever, I just have to create a

PersistenceExceptionTranslationPostProcessor

bean to disable the one autoconfig creates with

proxyTargetClass = true

So with that we have no functionality loss at all

interesting

looking at the interface solution side by side with the manual

open

keyword makes it apparent that we are just trading one keyword everywhere for another

Yes, but conceptually that much cleaner

certainly preferable still

We are overriding an interface instead of opening artificially a class, but I agree the code is not shorter, just better

and we don’t lose smart casting support this way

Yep

@sdeleuze: I’m not sure I follow all your plans here, but there is no such thing as "KEEP issue”, KEEP is (being) designed for proposals, so if you want to work on

allopen

feature you are welcome to submit a proposal of how should it work into KEEP. Otherwise, I believe there is already an issue in YT, or several, about this.

Ok thanks for the clarification

I plan to contribute on the Kotlin -> TypeScript thing but not on that one so I will create an issue

😉

hi guys i'm following your conversation since the beginning so here are my 2 cents making classes

final

by default is a good idea we are all lazy programmers so in java, we skip

final

by default because it's easier just as in kotlin, we skip

open

because it's easier however, what does it really achieves? not much in the end that means that it'll need extra effort when you want to subclass (as opposite of needing extra effort when you don't want to subclass) in most use-cases, that's just bikeshedding (https://en.wiktionary.org/wiki/bikeshedding) because it has zero consequences for application developers only for some (not most) frameworks as for the argument of retro-compatibility, that we are now 1.0 guys, do you imagine many use-cases where changing the default would cause a major issue? i don't think major companies have already developed their information system in kotlin sorry for being pragmatic simple smile

has zero consequences for application developers

but smart casts

you might be wrong on that simple smile

come on @yann.cebron

Why many companies are not embracing Swift? Because this: https://swift.org/blog/swift-3-0-release-process/

Swift 3.0 is a major release that is not source-compatible with Swift 2.2.

But they are Apple, and we don’t haver such luxury…

from a product point of view, that makes sense i've been bitching a lot against scala for the same reason however, you can provide a tool to make migration automatic...

Swift 3.0 = Kotlin 1.0 in term of language stability I guess

https://kotlinlang.slack.com/archives/spring/p1462868967000230 but http://movingfulcrum.com/jetbrains-the-unicorn-silicon-valley-doesnt-like-to-talk-about/