Edgar Avuzi
08/09/2025, 7:34 AMKotlin extension functions
VS future Java class instance methods
. Name collisionsEdgar Avuzi
08/09/2025, 7:34 AM// The code:
fun InputStream.bufferedReader(): BufferedReader = ...
// Usage:
val reader = socket.getInputStream().bufferedReader()
(Imaginary situation)
Later, suppose in JDK Java bufferedReader()
instance method will be added to InputStream.java
itself:
public BufferedReader bufferedReader() { ... }
When we increment Java version in our project, on recompilation:
• Calling bufferedReader()
now uses the new Java instance method instead of my extension method.
• For my extension method there will be compiler warning only like:
This extension is shadowed by a member: 'fun bufferedReader(): BufferedReader' defined in 'java/io/InputStream'.
This seems like a foot gun and bug that can easily slip through when the project codebase gets upgraded to a new Java version.
Having pipeline-style with pipe operator function calls in Kotlin itself (e.g., stream |> bufferedReader
) like in Elixir/Gleam languages would avoid that because we would use pipe operator stream |> bufferedReader
to mimic extension methods, so there won't be name collisions. That is we would use stream.bufferedReader()
for instance methods AND stream |> bufferedReader
to mimic extension functions.
Giving today's state of Kotlin :
• How do you handle this risk in your Kotlin codebases?
• Is there a way to have the compiler error on these collisions?hfhbd
08/09/2025, 7:59 AMhfhbd
08/09/2025, 8:00 AMHuib Donkers
08/09/2025, 10:09 AM