Fixed
Status Update
No update yet.
Comments
yb...@google.com
I should probably elaborate on that a bit more here :P. The ideal case would be that data classes written in other modules work the same when consumed. A standard data class (no secondary constructors, `val` properties) works fine when in the same module. The errors produced are also pretty confusing. They'll usually give what they read from the bytecode (constructor params called "var0" or the like) and reports missing setters for fields without names of said fields.
yb...@google.com
I can confirm the bug and the workaround. The same problem arises when you use a data-class from a library with @Embedded
yb...@google.com
given that log, looks like kotlin again not generating proper parameter names for methods.
yb...@google.com
so turns out this is not about kotlin.
does not work w/ javac either because parameter names are not part of the class signature unless compiled w/ debug.
We will need to add a new annotation to support this.
does not work w/ javac either because parameter names are not part of the class signature unless compiled w/ debug.
We will need to add a new annotation to support this.
yb...@google.com
True on the javac bit, but for kotlin you should be able to read the parameter names from the `@Metadata` annotations (since the param names are part of the public API in kotlin). There's no public API around this today though admittedly :/
lo...@gmail.com
actually i have a CL that makes this work for java as well but may not work for release builds (didn't try)
but it is shady, uses private APi and someday will break.
on the other hand, kotlin version seems to make sense, I'll ask kotlin folks to see if they have any plans to open it up.
but it is shady, uses private APi and someday will break.
on the other hand, kotlin version seems to make sense, I'll ask kotlin folks to see if they have any plans to open it up.
Description
Version used: beta-1
Devices/Android versions reproduced on: happens at compile time
The sample project attached to this bug report shows that Room does not check if I'm trying to get an entity from another table. The consequence is that sometimes I get an error which doesn't really say much: "error: incompatible types: <null> cannot be converted to boolean". This error is triggered by Kotlin's Boolean, which in the bytecode can be sometimes primitive types and so null fails to match. But when using another type, everything would be fine except that we are querying the wrong table for that entity.
See in the sample project the SomeDao.kt class: the first query causes a compile time error, while the second one (which for me is still invalid and would crash immediately in Kotlin since the type is non null) apparently is OK (is that expected? I understand that this is what allows Room to returns a different object from the entity and that's really powerful, but at the same time it opens the doors for a lot of mistakes which won't be catched at compile time)