Field must be either non-private or provide a getter and setter method
See original GitHub issueIn my Kotlin project I have only three fragments using Android-State. Each of them has three properties to save and restore. Some of them are like this
@State lateinit var mVariable: SomethingParcelable
The others are Strings and Booleans (all variables are called mSomething). None of them is private. Nevertheless I obtain this error:
Error:Field must be either non-private or provide a getter and setter method
Error:Execution failed for task ':app:compileDebugJavaWithJavac'.
> Compilation failed; see the compiler error output for details.
I can’t say which of my variables is causing this issue, but it seems to be a bug.
Issue Analytics
- State:
- Created 6 years ago
- Comments:11
Top Results From Across the Web
Advantage of set and get methods vs public variable [duplicate]
there are much more advantages: getters and setter can have validation in them, fields can't; using getter you can get subclass of wanted...
Read more >Why getter and setter are better than public fields in Java ...
Shall I use getter and setter method or public field, is a classical doubt in a Java programers mind. I advise against public...
Read more >Getters and Setters Methods in Java - CodeGym
First, all instance variables (fields) must be marked with the private modifier. Private is the strictest access modifier in Java.
Read more >Why Should I Write Getters and Setters? - DZone
If you make a field public, it means you provide direct access to the caller. Then, the caller can do anything with your...
Read more >Never Write a Getter or Setter in Java Again - YouTube
Use this to never have to write or even SEE a getter or setter in your Java programs ever again.Hate how much clutter...
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 FreeTop 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
Top GitHub Comments
Yes. When I removed the internal modifier, it was all good.
@vRallev Still happens with 1.2.0. I’ll try to isolate a repro case.