since the POJO’s are immutable there’s no point in...

# announcements

[ebonet]

since the POJO’s are immutable there’s no point in getter and setters

[gildor]

For val Kotlin generates only getters

[gildor]

Also, properties give you additional abstraction layer:
You can have interfaces with properties (but not with fields), you can override or specify property getter without API change. And this is the reason why getters and setters recommended in Java instead of fields.
So I don't think that annotation of all properties with @JvmField is good idea, it just doesn't worth it in 99.9% cases (in terms of performance or bytecode size)

[ebonet]

yes, but I still have to change all calls from myClass.property to myClass.getProperty() over the code base, which is unnecessary on my code and less readable

[gildor]

If you want to convert existing code yes, maybe it make sense sometimes, but Idea makes all the job for you and refactors existing Java code and doesn't affect Kotlin code.
Also, If you have a lot of code that use existing pojos why do you convert them to Kotlin? Make sense to do that for new classes.

[ebonet]

I am converting the code as a sample of the differences and advantages of kotlin, and the problems we will face if we adopt kotlin on the codebase. We currently use only Java

[gildor]

Kotlin doesn't have fields and don't think that Kotlin Team introduce such solution because it's very rare case with a lot of drawbacks. Compiler plugins API is not public yet, so the only way is annotate properties with @JvmField if you want to keep using fields for existing Java code.