Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Java] Exception on BytBuffer position() #6657

Closed
krojew opened this issue May 19, 2021 · 7 comments · Fixed by #6658
Closed

[Java] Exception on BytBuffer position() #6657

krojew opened this issue May 19, 2021 · 7 comments · Fixed by #6658

Comments

@krojew
Copy link
Contributor

krojew commented May 19, 2021

After updating to Java 2.0.0, I've encountered https://stackoverflow.com/questions/58120357/jeromq-on-android-no-virtual-method-clearljava-nio-bytebuffer on Android. The fix is simple: replace all bb.position() calls with ((Buffer) bb).position(). Unfortunately, I don't see a client-side workaround.

@aardappel
Copy link
Collaborator

Your link seems to suggest it is about the return value of position, i.e. the version of position that takes an argument. The solution would then be to simply not use that return value, but I see no use of that in the code.

Can you point to a use of position that causes this exception?

@krojew
Copy link
Contributor Author

krojew commented May 20, 2021

I actually observed the behavior on the overload setting the position in createString() in FlatBufferBuilder.

@aardappel
Copy link
Collaborator

That does bb.position(space -= length);, and the return value the link talks about is unused.

@krojew
Copy link
Contributor Author

krojew commented May 20, 2021

The actual return value is not relevant - the issue is with the VM not finding the right method to call. It tries to look for a one returning a Buffer, but only finds one returning a ByteBuffer, hence the exception. It simply doesn't handle covariant return types. Upcasting forces it to use the one returning Buffer.

@aardappel
Copy link
Collaborator

Ok, thanks for the explanation. That is pretty bad bad breakage of the Java APIs, surprised they thought that was a good idea.

This should affect the setter version of position, not the getter, and you are also changing the latter?

Remains the issue of what the costs is of all these extra casts. If its only the setter it may be ok?

Yes, and don't understand why this is only now an issue..

@paulovap

@krojew
Copy link
Contributor Author

krojew commented May 20, 2021

I may have gone a bit overboard with replacing calls. I'll revert changes to the getters in ~9h.

@krojew
Copy link
Contributor Author

krojew commented May 21, 2021

Just pushed an update. Seems to work.

krojew added a commit to krojew/flatbuffers that referenced this issue May 27, 2021
krojew added a commit to krojew/flatbuffers that referenced this issue Jun 1, 2021
aardappel pushed a commit that referenced this issue Jun 3, 2021
krojew added a commit to krojew/flatbuffers that referenced this issue Jul 9, 2021
aardappel pushed a commit that referenced this issue Aug 5, 2021
* avoiding more NoSuchMethod exceptions

refs #6657

* avoiding even more NoSuchMethod exceptions

refs #6657
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants