Breaking changes on Android with Java SDK

[roncbird]

Hi,

The changes in 3.11.0 "Moved to Java 11 to support HTTP Client. This is a breaking change for anyone using earlier versions of Java", has prevented Android users from importing the smartystreets-java-sdk from maven. Android/Google only provides a subset of features in Java 11. One of them is not java.net.http.HttpClient. Therefore, when we try to instantiate a client with ClientBuilder, we get

Caused by: java.lang.ClassNotFoundException: Didn't find class "java.net.http.HttpClient" on path: DexPathList.

I could go back to the previous version of 3.10.7 which uses com.google.api.client.http, but the issue with that is, my product manager has asked that we set the source to "postal" to eliminate P.O box results, and that option was not added to US Autocomplete Pro lookup until 3.11.0. We are currently in the evaluation process, and my PM has not purchased a license yet, but if I can't find a way to import java.net.http.HttpClient into our Android project, then this catch-22 with java.net.http.HttpClient/source field availability, may force us to have to go with Google Places. So, I wanted to ask what you would recommend? Hopefully, we can receive an answer asap, as my requirements are to finish the address search feature this sprint. Thank you in advance.

Here is a link showing what java.net classes are available on Android: https://developer.android.com/reference/java/net/package-summary

Unfortunately, importing java.net.http as a library is not a viable option. See some of the reasons here in this StackOverFlow: https://stackoverflow.com/questions/69750452/how-can-i-use-jdk-11-http-packages-in-android

[DuncanBeutler]

postal is actually the default in this case, so 3.10.7 should work great for you! The flaw that you may come across is that the google client decodes semi colons before sending the request. The Smarty API adheres to HTTP standards which necessitate encoding semi colons - so if you try to filter multiple states, for example, it'll only filter the first state entered in the query. This is the unfortunate bug that we were fixing by moving to the built in HTTPClient in Java 11 but barring that use case, version 3.10.7 should work for you without a hitch!

[roncbird]

Duncan,

Thank you so much for the quick response. I agree. If 3.10.7 defaults to postal, then it would work great for us. However, the response results I'm getting back with version 3.10.7 are returning P.O. Box autocomplete suggestions. I apologize for the screenshot, but I couldn't find a way to enable network logs for SmartyStreets. In the screenshot, you can see on the left hand side that I have added com.smartystreets.api:smartystreets-java-sdk:3.10.7 as a dependency. I added a break point where the results are being returned, and you can see in the bottom right hand corner of Android Studio, the values for the Suggestion objects in the lookup.results list contain PO Boxes. I also included what is being displayed in our app for further context. Is there maybe something I'm missing I need to do with version 3.10.7 to ensure only postal address are returned?

[smartybryan]

PO Boxes are valid postal addresses. There is not a way to eliminate them from the results in US Autocomplete Pro.

Your earlier concern was that non-postal addresses would not be returned with the older version of the Java SDK (which has no option to set the "source" parameter). Since "postal" is the default, you will never get non-postal addresses back.

[roncbird]

Ok, thank you for the clarification. I appreciate it. That answers my question.

[RyanLCox1]

I'm closing this issue as resolved. Question was answered above.