You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Clients using protobuf-java instead of protobuf-javalite have to migrate their codebase to protobuf-javalite in order to integrate with PlaidSDK
The PlaidSDK is using protobuf-javalite, which expects GeneratedMessageLite classes, while our project is using protobuf-java, which works with GeneratedMessage classes (such as Struct). This mismatch unfortunately causes the verifier to reject the class during runtime, as it’s expecting GeneratedMessageLite but encountering a class from protobuf-java instead , which is the Struct.
This leads to the following error :
java.lang.NoSuchMethodError: No virtual method build()Lcom/google/protobuf/GeneratedMessageLite; in class Lcom/google/protobuf/Timestamp$Builder; or its super classes (declaration of 'com.google.protobuf.Timestamp$Builder' appears in /data/app/~~kr4cSZrPd_dXG0MQKGpZDQ==/com.kaching.merchant.dev0-yhGyMQvWrSi28Sq9If92wg==/base.apk!classes39.dex)
at com.plaid.internal.xk.a(SourceFile:106)
at com.plaid.internal.z8.a(SourceFile:3436)
at com.plaid.internal.z8$j.invokeSuspend(SourceFile:1)
We have encountered similar cases and there is multiple solutions to support clients that use protobuf-java as well as protobuf-javalite
Possible solutions :
PlaidSDK keeps using protobuf-javalite but generate the protobuf files for protobuf-java , i.e. generate the classes from the .proto files to be compatible with protobuf-java ( i.e. Use Struct instead of GeneratedMessageLite for example)
additionally include the dependency : com.google.firebase:protolite-well-known-types , which includes (the Struct for example). That way a client using protobuf-javalite can simply integrate
and a client using protobuf-java , can simply exclude the dependencies , similar to firebase-performance
like :
Since protobuf-java already includes these well-known-types, that’s the most minimally invasive option to accommodate SDK integrators in both cases.
We have also seen SDK providers that offer 2 versions , one with protobuf-java and one with protobuf-javalite, however that requires maintaining both versions , so its not the most direct approach.
The problem
Clients using
protobuf-java
instead ofprotobuf-javalite
have to migrate their codebase toprotobuf-javalite
in order to integrate withPlaidSDK
The PlaidSDK is using
protobuf-javalite
, which expectsGeneratedMessageLite
classes, while our project is usingprotobuf-java
, which works withGeneratedMessage
classes (such asStruct
). This mismatch unfortunately causes the verifier to reject the class during runtime, as it’s expecting GeneratedMessageLite but encountering a class fromprotobuf-java
instead , which is theStruct
.This leads to the following error :
We have encountered similar cases and there is multiple solutions to support clients that use
protobuf-java
as well asprotobuf-javalite
Possible solutions :
protobuf-javalite
but generate theprotobuf
files forprotobuf-java
, i.e. generate the classes from the.proto
files to be compatible withprotobuf-java
( i.e. UseStruct
instead ofGeneratedMessageLite
for example)com.google.firebase:protolite-well-known-types
, which includes (theStruct
for example). That way a client usingprotobuf-javalite
can simply integrateand a client using
protobuf-java
, can simply exclude the dependencies , similar tofirebase-performance
like :
Since
protobuf-java
already includes thesewell-known-types
, that’s the most minimally invasive option to accommodate SDK integrators in both cases.protobuf-java
and one withprotobuf-javalite
, however that requires maintaining both versions , so its not the most direct approach.Useful links :
protocolbuffers/protobuf#8104
firebase/firebase-android-sdk#5997 (comment)
https://github.com/firebase/firebase-android-sdk/tree/main/protolite-well-known-types#problem
Environment
Expected Result
Should not be required to change our dependencies for protobuf.
The text was updated successfully, but these errors were encountered: