



It is the kotlin take on a java feature that existed when the kotlin take was designed. I can best explain it using a new feature.Īll of kotlin's features fall in one of 3 categories:

If kotlin is supposed to be 'java but better' forever If you ask someone more familiar with kotlin than I am to explain what kotlin is and/or why the following two arguments do not apply or are properly mitigated, make sure you first establish with them what kotlin's supposed to be. I get the feeling that kotlin folks sort of think it is both, but they are mutually exclusive, so that makes no sense. But, what does that mean? Is kotlin supposed to remain 'extremely easy to pick up if you already know java' and 'so close to it, you can interop java and kotlin code with relatively little headache' for the foreseeable future (in which case I foresee some problems I will explain below), or was that mostly just a bootstrap scenario a way to get a bunch of existing java programmers on board quickly, and give them the ability to transfer their codebase from java to kotlin step by step (by using the interop / double-compile feature)? If that's what it is, then I too foresee some issues in the future. Kotlin seems to be marketed (both by the community and idea) as java with some minor warts removed. But perhaps you find this lack of openness more important than 'minor niggle'. This is all quite pragmatic, but it also means that without IDEA, kotlin dies immediately. For example, quite a few details about how kotlinc works internally is managed by having kotlin-genned class files have a annotation that contain a binary blob (a byte array, legal in annotations) with data that is, as far as I know, not according to any publically available spec.
