Idea: JVM getter name change. Currently: ```data c...

# language-proposals

[Nicole]

Idea: JVM getter name change.
Currently:

data class Component(val active: Boolean) {
    val getList get() = listOf("empty")
    val isPoorlyNamed get() = 10
    val isCorrectlyNamed get() = true
}

JVM code:

Component component = new Component(false);
component.getActive();
component.getGetList();
component.isPoorlyNamed();
component.isCorrectlyNamed();

Proposal: To better match Java Bean naming conventions:
val active -> boolean isActive() - Boolean return maps to “isProperty”
val getList -> List<String> getList() - Already prefixed with “get” -> leave it
val isPoorlyNamed -> int getIsPoorlyNamed() - Prefixed with “is”, but isn’t a boolean -> add “get” prefix
val isCorrectlyNamed -> boolean isCorrectlyNamed() - Same as today

[gildor]

“Change” means backward incompatible, so unlikely it would be even concidered

[gildor]

also, what is point of this?

[karelpeeters]

Why would you call an integer field isPoorlyNamed in the first place?

[cbruegg]

And why a property like a getter? (getList)

[raulraja]

I think @Nicole is arguing the compiler should observe methods already with a prefix that follow the javabeans conventions and not append an extra prefix when consumed from java. The example of active: Boolean is a good example. If Kotlin is generating today getActive in the getter property as seen from java that does not follow the javabeans conventions (I have not verified that). I think it’s a legit concern and most likely an expectation of many frameworks that use reflection.

[benleggiero]

I like this proposal. It addresses what I would consider a bug in the compiler and improves consistency of the interfaces that compiler generates

[gildor]

If Kotlin is generating today getActive in the getter property as seen from java that does not follow the javabeans conventions

For property isActive Kotlin generates method isActive() and setActive and field isActive, which perfectly follows Java bean convention

If you have property active it will generate getActive and setActive with field active, which also follows Java bean convention, because is is not requirement, but optional naming convention for booleans, get prefix is still completely valid

[gildor]

Not “require” or “must”, but “allow"

[gildor]

Also, if for some reason you really want to have boolean property without is prefix in Kotlin, but with get prefix in Java, just use JvmName:

@get:JvmName("isActive")
var active = false

[gildor]

It addresses what I would consider a bug in the compiler

What kind bug? what is exactly not consistent?
Also remember that this is backward incompatible change, it will break all Kotlin/Java interop of existing code

[benleggiero]

@gildor The bug and inconsistency I see is the auto-generated prefixing for Boolean getters. It's not obvious whether a given Boolean will generate get or is as a prefix, even if there is a logic behind which it chooses.

I think if we put in zero special cases (all getters with auto-generated JVM names start with get), that's OK.

I think that if we put in one special case for Boolean getters (their auto-generated JVM names all start with is), that's OK.

I think that if there's some logic where the special case is only sometimes applied (Boolean getters with auto-generated JVM names start with is if and only if their Kotlin counterpart also starts with is, otherwise they start with get), that's not OK and is unnecessarily confusing/inconsistent.

[gildor]

It’s not obvious whether a given Boolean will generate get or is as a prefix

It’s obvious. is generated if your property has is prefix`

all getters with auto-generated JVM names start with get)

This will make Java interop not so pleasant, you will have getSomething instead isSomething everywhere, even if original property has is prefix

Also, existing behaviour have a lot of sense not only for Java interop, but also for any kind of serialisation, when to map Kotlin property to some serialized property you can choose between boolean property with is prefix or without it.

Again, all this “would be good to have” probably doesn’t make a lot of sense because it will break a lot of code without any significant advantage