Cannot be @Required or @NotNull.
See original GitHub issueGoal
Compile the project
Expected Results
Compile without errors
Actual Results
Error: Field “fields” with type “com.myApp.sample” cannot be @Required or @NotNull.
Steps & Code to Reproduce
I just updated the Realm version (realm-gradle-plugin) from 3.5.0 to 3.7.2. If I move back to 3.5.0 it works.
Code Sample
class Class(@PrimaryKey var id: Int = 0, var fields: Fields): RealmObject()
Version of Realm and tooling
Realm version(s): 3.7.2
Realm sync feature enabled: No
Android Studio version: 3.0 Beta 6
Which Android version and device: None
Issue Analytics
- State:
- Created 6 years ago
- Reactions:5
- Comments:20 (12 by maintainers)
Top Results From Across the Web
java - cannot be @Required or @NotNull - Stack Overflow
It means that Realm single link CAN be null in the database. So if you access the field on a managed RealmObject where...
Read more >@Nullable and @NotNull | IntelliJ IDEA Documentation
@Nullable and @NotNull annotations let you check nullability of a variable, parameter, or return value. They help you control contracts ...
Read more >Required vs @NotNull - Vaadin
@NotNull is practically equal to required flag Vaadin field, which is kind of built in Validator executed before any other validators. In Viritin...
Read more >Difference Between @NotNull, @NotEmpty, and @NotBlank ...
@NotNull: a constrained CharSequence, Collection, Map, or Array is valid as long as it's not null, but it can be empty. @NotEmpty: a...
Read more >Nullability in Java and Kotlin
The parameter a has the String type, which in Kotlin means it must always contain a String instance and it cannot contain null...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

Hi folks.
You are breaking the implementation of the library on all possible
Kotlinprojects just to satisfy a new behavior. I recommend you to think again the implementation and stop forcing the developer to, in a very hard way, change the source code. Just becauseRealmis not capable to always return a non null object, it doesn’t means that the library can’t handle it. Should be good to have a way to disable this nullability verification or add a default value. But let the developer choose what to do with the project, not the inverse. I will expend a lot of time just to solve this nullability issue and I will increase the risk of failure on my software.Sorry, but this is very frustating and annoying.
@ppamorim It isn’t really a new behavior, but just exposing the reality of the underlying Realm correctly.
If you can guarantee internally that the reference is never null, you can use it as a backing property: https://kotlinlang.org/docs/reference/properties.html#backing-properties and then do the conversion in custom getters and setters, like: