A modern programming language that makes developers happier.

kotlinlang

hello :wave:  , im hoping to get traction on this <https://discuss.kotlinlang.org/t/kotlin-java-setter-interop-issues/23357|post> , thanks in advance for your time and consideration.

A compiler flag is a bad idea, because it would produce inconsistent output in different code bases. Removing the false positive warning is a good idea, and maybe an IDE hint could be added that shows a public field is being used and not a setter.

as a workaround, you could create a API stub that only has public accessors, not public fields, and use that as `compileOnly` while using the real dependency as `runtimeOnly`?

&gt; maybe an IDE hint could be added that shows a public field is being used and not a setter.
i think this can greatly help us spot these issues. It would be nice to be able to configure a warning when a public prop gets directly updated

&gt; as a workaround, you could create a API stub
this is going to be tedious, we have hundreds of these java classes with public props and they are evolving

you could transform it automatically, like what Android does to make its stub android.jar

<@U02LSS9N7MX> hundreds of Java classes that have public fields and a corresponding public setter as well?
With setters that behave differently from setting the field, and where setting the field manually breaks the invariants of the class?

This is a terrible API design, where are those Java classes coming from? I mean the example in the post itself scares the hell out of me, even if Kotlin was not involved at all

there's no debate exposing properties as public is a mistake (in this case and generally speaking). Also i agree the api is error prone.

but it also feels to me that Kotlin should not always assume that setting a property is equivalent to calling a setter and  direct devs to call the wrong thing in our case especially when the POJO exposes public properties + public setters.

Yes, I totally agree that the IDE shouldn't warn about explicit getter/setter usages when there is both a public field and public getter/setter in Java. If it does, IMO this is an inspection bug

My point is about the importance of such bug. Depending on how hard it is to fix it, I'd rather have the Kotlin team invest time in other things, because clearly the confusion in your case comes from a poorly designed Java API, and this is the thing that should urgently be fixed.

Of course, this doesn't mean we shouldn't open the bug in YouTrack, though. I think you should open an issue for this

That being said, I really don't believe we need anything more than fixing this inspection bug. The compiler flag thing for using setters instead of fields when using the property `=` syntax just feels wrong (because then you cannot use the direct field access anymore).

&gt; The compiler flag thing for using setters instead of fields when using the property `=` syntax just feels wrong
makes sense

&gt; maybe an IDE hint could be added that shows a public field is being used and not a setter.
^ this was suggested before.
because we dont have much control over the evolution of the poorly designed api, i believe this approach can  greatly help us detect unintended usage.

i can open a youtrack issue. thanks for looking into this.

jfyi, created an issue <https://youtrack.jetbrains.com/issue/KT-49742>
for whatever reasons, i was unable to tag it.

again, thanks for your time and the consideration!

somebody on JB team can tag it. also I think should have been in KTIJ component, but they can take care of that during triage