Fixed
Status Update
Comments
da...@google.com <da...@google.com> #2
Thank you for the report and the code causing the issue. I have landed a reproduction which shows that the code thrown an ArrayIndexOutOfBoundsException
from the last bitSet.toByteArray()[0]
when not processed by R8.
ap...@google.com <ap...@google.com> #3
Project: r8
Branch: main
Author: Søren Gjesse <
Link:
Add reproduction of
Expand for full commit details
Add reproduction of issue 391417819
Bug: b/391417819
Change-Id: I37eb909c100104fadeb895bf5d930f4f54e94ba0
Files:
- A
src/test/java/com/android/tools/r8/B391417819Repro.java
Hash: bf9b1962052bf91689120a09deded518e37862a2
Date: Wed Jan 22 09:41:15 2025
el...@google.com <el...@google.com>
ma...@justpinch.com <ma...@justpinch.com> #4
deleted
da...@google.com <da...@google.com> #5
I'm really sorry, please use the source code below:
public class R8Test {
public byte[] toBytes(boolean on) {
byte[] bytes = new byte[3];
bytes[0] = 1;
BitSet bits = new BitSet(8);
byte[] byteArray = bits.toByteArray();
if (byteArray != null && byteArray.length >= 1) {
bytes[1] = bits.toByteArray()[0];
}
BitSet bitSet = new BitSet(8);
byte[] byteArray2 = bits.toByteArray();
if (byteArray2 != null && byteArray2.length >= 1) {
bytes[2] = bitSet.toByteArray()[0];
}
return bytes;
}
}
ma...@justpinch.com <ma...@justpinch.com> #6
Thank you for the update. Most likely the initial source code will still be sufficient to fix the issue.
Description
Component used:androidx.room:room-*
Version used: 2.3.0, 2.4.0-alpha02
Devices/Android versions reproduced on: N/A -> code-gen error (kapt)
The documentation on states:
@Transaction
But unless I'm misunderstanding what this is trying to communicate, reality seems to be different.
Given the following dao:
Although implementations are generated, errors are thrown for the
@Transaction
annotated functions returningLiveData
andFlowable
:This seems to contradict the earlier statement from the documentation on
@Transaction
? Is there another way to use@Transaction
with a deferred/async return type?What's also interesting is that the
@Transaction
annotated function returning aFlow
does not yield any errors. Isn'tFlow
also a deferred/async return type? Does this mean that Room can in fact guarantee that all queries in the method are performed on the same thread? If so, how?The generated code looks like this:
This function is no longer deferred, because the transactional operations involve blocking I/O, and there are assertions in place that will fail if this is called from the main thread. And even if we were to make this function suspendable (we would then have a suspendable function returning a Flow?🤨), it would still not be main-safe.
In conclusion, I suspect:
@Transaction
is no longer accurate?@Transaction
annotation returning aFlow
should also yield a code-gen error?