Official repo for external annotations


#1

Hi,

Is there any repositories for external annotations of popular Java libraries, like jackson/guava/netty? It is a bit annoying to annotate every use of third party Java libraries, and it also leads to API incompatiblities because not everyone would annotate a library the same way.

I hope there are some centralized solution for this feature, and probabily integrated into build process, similar to maven’s javadoc/sourcecode finding mechanism (gradle/maven?).


#2

There will be build-time centralized solution pretty soon. We are changing the type system to include so called "platform types", which are basically types with unknown nullity. When types are imported from binaries built by Java (or any other JVM language), their members' parameters and return types are treeted like this. Hence, no need for annotations at all, and no `!!` operators all the way either. Hope this helps.


#3

Wow, that is interesting.

So what would happen if these platform type actually return a null value?

If you will remove ‘!!’ operator, how does it affect current code?

Will this be available at M9?


#4

If the value happens to be null, and you pass it somewhere where null is not expected, exception will be thrown, much like with !! operator. Advantage of such system is that you will have exception as early as possible, not like in Java when you store received value in a field, and then use sometime later on a different call-stack.

We will not remove operator !!, it is still needed. There could be a warning about redundant use of said operator on platform type.


#5

Reasonable :-)

I’m really looking forward to this release. Kotlin is already quite usable, I hope to use it in production soon.

Do you have a wiki page for these kind of feature roadmaps?


#6

We are planning slight reconstruction of kotlinlang.org web site to include some news, roadmaps and progress report to community. Stay tuned ;)


#7

Hi, do you mean that you will do away without the external annotation mechanism? I actually liked a lot to be able to give hints to the compiler/IDE about the contract of "unsafe" library methods. I fear this "automation" may make the situation similar to what we have now when we work with plain old Java.


#8

Unfortunately, the external annotation mechanism doesn't play very well with build tools, and annotated Java code is prone to rather nasty corner cases when you may not be able to extend a certain set of Java interfaces from Kotlin, because their annotations make signatures incompatible.

So, we are changing the compiler so that it does not depend on annotations for compilation. It will issue watrnings on Java nullable/notnull contract violations, as well as the Java IDE does now.


#9

then, if I understand correctly compilation will not rely on external annotations, but we will still be able to supply them to suppress/issue warnings? That would be good enough