external annotations were deliberately disabled

the reasoning is that the outcome of a build cannot be influenced by the presence of an xml file

I agree, but what is the alternative, I must be able to have a warning or an error on code

matcher.group(1).length()

I’m not sure what alternative you expect to find

it’s true that external annotations have been disabled and we have no plans to reinstate them

In the Java editor,

matcher.group(1).length()

shows warning

Method invocation 'length' at line 111 may produce 'java.lang.NullPointerException'

actually, why not show a warning, too?

It would be a bit weird to have both nullability in the type system and as warnings only, but at least it would be consistent with java

on the other hand, external and internal annotations now would be treated differently, which is awkward

The only two alternatives I see is to add `@Nonnull`/`@Nullable` directly in JDK jars, or to create inline extension methods such as

inline fun Matcher.group_(i: Int):String? = this.group(i)

. The first solution is not realistic, and the second solution requires us to always call

matcher.group_(1).length()

instead of

matcher.group(1).length()

many JDK methods, including regex operations, already have Kotlin wrappers with proper nullability

Regex

doesn't have methods

appendReplacement()

and

appendTail()

And for java interop we want to minimize specific Kotlin wrappers

I agree it's a problem, but you have to admit, there's no obvious solution

you can use

replace()

with a lambda instead of

appendReplacement()

and

appendTail()

not sure how the use of

Regex

impacts Java interop. you don’t need to expose it in your API

The obvious solution for us would be to have external annotations for at least platform types...

So the recommended workaround is to create a wrapper for each external API to avoid NPEs due to platform types ?

you can also not create wrappers and handle the nullability on the call site using

!!

,

?:

,

require

,

assert

and so on

and test your code, obviously

A better solution than wrappers would be to being able to add my own mapped types such as MutableList, will that be possible in a future release?

no, it’s not on the roadmap at this time

MutableList

involves a lot of special-case hacks in the compiler, and it’s not clear how it could be exposed in a generic way and whether this would be a good idea at all

Then I will try to use inline extension methods with underscore as suffix, and Structural Search Inspection warnings on use of the original methods. Better than instantiating a lot of wrapper objects...

Structural Search Inspections don't work for Kotlin 😞

Yes it does, I just tried

Pasted image at 2016_05_13 04_51 PM.png

Darn it, you're right 😞