https://kotlinlang.org logo
Join Slack
Powered by
Did someone ever experienced a situation where an ...
# announcements
b
Did someone ever experienced a situation where an 
object
at runtime has multiple instances?
o
This could be with multiple classloaders, I think.
b
I’m not using classloaders.
o
How do you know there are multiple instances? What your code looks like?
b
Thanks to the debugger
o
Well, we might need some more information to help with diagnosing the problem… What kind of picture you have in a debugger?
Also, is it reproducible? I mean you see it all the time, deterministically?
b
I’m using the 
object
inside a 
when
(the object is a case of a sealed class) and the 
when
throws an exception (
NoWhenBranchMatchedException
) because it does not find a matching case (the 
when
is used as an expression and I’m providing all the cases).
Yes, all the time I run that particular code
o
Copy code
fun main(args: Array<String>) {
    val y: S = S.A
    val x = when (y) {
        is S.A -> "1"
        is S.B -> "2"
    }
    println(x)
}

sealed class S {
    object A : S()
    class B : S()
}
Is it like this? This one works fine. Anything special about your code?
a
@brescia123 try a full rebuild. its possible that using when() code with old compiled code produces that problem
b
I'm no using 
is
on case 
S.A
@Andreas Sinz I'll try thanks
o
Still, without 
is
it works fine for me. There should be something special about your case…
Did rebuild help? Or are you still having the issue after rebuilding?
p
It depends how you constrcut the instance
for example I had a situation where I used moshi (like gson) to deserialize a class
And it ended with an object that was not equal to the actual object class
p
Hi guys, thanks for all your replies. I'm a colleague of @brescia123. @Andreas Sinz @orangy I did the rebuild but i still have different instance of same 
object
that lead to 
NoWhenBranchMatchedException
. Sorry for too late response!
o
That sounds scary… We need to reproduce it. Can you share at least some code that I can use to reproduce the problem? Privately, if you wish.
p
You mean his case right? That deserialization creates objects that differ is not scary for you, right? @orangy
I mean objects could also generate an equals method that defines equals based upon it’s class
Copy code
import com.google.common.truth.Truth.assertThat
import org.junit.Test

object MyObject

class T {

    @test
    fun main() {
        val original = MyObject
        val constructor = MyObject.javaClass.getDeclaredConstructor()
        constructor.isAccessible = true
        val throughReflection = constructor.newInstance()
        assertThat(original).isEqualTo(throughReflection)
    }
}
That burned me once
o
Nope, that reflection is not scary. If you break the system by doing something like that, you’re off any guarantees 🙂
p
Even though it's a common thing to do if you use stuff like gson / moshi
So I'd love if it would define equals based on the class
+ print it's class name instead of that ugly hashcode thingy in its toString
p
@orangy i know that share some code should be the better solution. I have to ask to my supervisors and, due to some commitments, it could take some days. I'll update you asap.
o
@Paul Woitaschek please file/find a feature request in our tracker, that’s the best way to have things moving
@paccman thanks, will be waiting
b
Hi @orangy! We found out what was the problem: we defined the object 
Serializable
(to be able to put it inside an Android 
Intent
and pass it between `Activity`s).
o
So, like @Paul Woitaschek said, you deserialized it. Good that you’ve found it!
b
yep
I think that a IDE warning could be useful
when defining an 
object
as 
Serializable
o
Please file an issue in YouTrack
4 Views
Open in Slack
PreviousNext
Powered by