avoiding more NoSuchMethod exceptions #6671
Conversation
|
@aardappel after rebuilding my test Android project from scratch, more methods started to fail. Smells like 2.0.2... |
|
Ugh.. I guess we have no easy way of testing this / adding to the CI? How do we avoid this in the future? I can't be making releases every time we forget this in Java code. Do you have confidence this is the last of it? Also, please update the version number in all the xml files, so it is ready to release. |
|
To be honest, I don't know how to automate it. I tried to manually look for calls returning the subclass. Right now, everything seems to work, but it looked like this before. Might be a good idea for another pair of eyes to search for such problematic calls. |
|
Sorry for the late reply, I was on vacation. I never face this problem before, but on Android we usually target Java 8 API. @krojew if I understood it correct it only happens if you target Java 9 API? Is that it? Yes, we can automate. Just run a unit-test against an Android Emulator. I haven't check if we have android specific tests, but this could be a good reason to start. |
|
I really can't tell what exactly triggers this error. I'm targeting Java 8, which in theory, shouldn't be a problem. I know it started to appear after Android Studio update (which coincided with gradle update). That's why I'm not sure what would be a repeatable scenario for an automated test. Maybe any simple Android project, maybe some specific combination of settings. |
Can you leave your gradle, android, etc versions and basic project config in a comment so we can try to reproduce later? |
|
Android Studio: 4.2.1 |
|
Can this be merged? |
|
@aardappel @paulovap will there be another patch release? |
|
release seems to have succeeded.. |
|
The user seems to be claiming that the 2.0.2 package from Maven doesn't work for them because it was built with Java 9, even though it has all @krojew's fixes in it? I am confused how that works.. |
|
I took a look at the code from the error and there is an explicit cast there: https://github.com/google/flatbuffers/blob/master/java/com/google/flatbuffers/FlatBufferBuilder.java#L605 Maybe he's not using the latest package. |
|
I suspect I'm also seeing this issue and think that perhaps jetty/jetty.project#3244 provides a lead on how to fix it. |
With the changes introduced on google#6729, google#6671, google#6658 it seems that using java compiler version 8 is no longer possible. We are adjusting our CI build for Kotlin to use Java 11 as compiler, while still emiting 1.8 bytecode. The Kotlin CI action is also being breakdown into two: Mac & Linux. Kotlin mac will test ios & mac builds while Linux will test js and JVM. This change will improve build times for Kotlin on CI, which is currently taking long times.
With the changes introduced on #6729, #6671, #6658 it seems that using java compiler version 8 is no longer possible. We are adjusting our CI build for Kotlin to use Java 11 as compiler, while still emiting 1.8 bytecode. The Kotlin CI action is also being breakdown into two: Mac & Linux. Kotlin mac will test ios & mac builds while Linux will test js and JVM. This change will improve build times for Kotlin on CI, which is currently taking long times.
This reverts commit 752c7b5.
* Revert "avoiding even more NoSuchMethod exceptions (#6729)" This reverts commit 6fb2c90. * Revert "avoiding more NoSuchMethod exceptions (#6671)" This reverts commit 752c7b5. * Revert "avoiding NoSuchMethod exception (#6658)" This reverts commit 813d363. * Use Java 8 for Kotlin Linux builds to verify
refs #6657