Is it safe to expect NotNull / Nullable annotations to always be present ? (Added to fields by Kotlin compiler)

1

I'm pondering using java reflection to look for the NotNull / Nullable annotations that the kotlin compiler adds.  The purpose is to implicitly determine properties on ORM entity beans that must not be not null db columns.

Is it safe to expect those annotations to always be present (always added to the associated fields by the Kotin compiler)?  

Thanks, Rob.

Example:

 
Size(max = 100)
public var subject: String? = null;
  
// NotNull ... no need to explictly add separate NotNull annotation
 
//             because Kotlin compiler will always add one for us
 
Size(max = 100)
public var code: String = "";






 

  // access flags 0x2
  private Ljava/lang/String; subject
  @Ljavax/validation/constraints/Size;(max=100) // invisible
  @Lorg/jetbrains/annotations/Nullable;() // invisible

  // access flags 0x2

  private Ljava/lang/String; code

  @Ljavax/validation/constraints/Size;(max=100) // invisible

  @Lorg/jetbrains/annotations/NotNull;() // invisible

            


            

              
              
              
            


          

          

            

              



              
                  
                  
              2
              
            

            

              
As your listing mentions, @NotNull is not visible through reflection, because its retention policy is CLASS

            


            

              
              
              
            


          

          

            

              



              
                  
                  
              3
              
            

            

              
I think with JetValueParameter you had a type of "?" but that is deprecated.  Don't remember clearly if that was always accurate.

No plan @andrey for making this visible to reflection.  I was just working on a data binder for JSON to replace the front-end of Jackson (still using core) to do smarter binding with Kotlin.  Knowing if something is nullable would let it know better if there is an error or not before setting a value.  Which could let it pick different constructors, or try to determine if there is one with a default value, etc.

            


            

              
              
              
            


          

          

            

              



              
                  
                  
              4
              
            

            

              
Yes, it will be available once we roll out the full Reflection API