I have noticed two problems with the generated Java client code. At the moment, these require manual changes by me in order to use the client API code.
The user ‘pmi’ field is typed as a Java Integer in the InlineResponse20033 model class, but the field is required to have 10-digits. This means that any pmi which represents a number greater than 2147483647 (0x7FFFFFFF) will overflow the Java Integer type, and de-serialization (for example, Jackson libraries) will throw an exception.
The account ‘id’ field is typed as a java.util.UUID in the AccountListAccounts model class, and the UUID type has a specific 36-character format (including 4 dashes). The ids of the test accounts that we have created do not follow this format (they are 22-character strings), and so de-serialization (for example, Jackson libraries) will throw an exception. I am assuming these id’s are generated by the Zoom system.
I have noticed the account ‘id’ field is now a String and so no more error there. However, the user ‘pmi’ field still errors with numbers greater than 2147483647 (as described before). Also, the lower-case ‘object’ type is still present and must be manually fixed.
Also, I notice that the generated MeetingsApi.java class returns a GroupList object from the meetings() method - this must be the wrong return type because it does not contain any meeting info.
