Fork me on GitHub
#java
<
2024-02-01
>
genekim17:02:45

A request for opinions — Over the holidays, I downloaded all my gmail in preparation to analyze them using LLMs, to see if I could make it easier for me to respond to emails. In the past, I’ve used the Google Java libraries to access Sheets and Drive (copying the work of https://github.com/pvgomes/clojure-google-sheets and https://github.com/SparkFund/google-apps-clj), as well as Google Cloud Storage. So I used the Gmail libraries — I was a little surprised at how strange and difficult I found it to use. • side-effecting calls to Gmail happened at surprising times (you fetch a list of Gmail threads, and then when you iterate over each thread, it calls Gmail APIs behind the scenes again for each thread). • everything return object seems to be a different type of object in a vast object hierarchy, requiring lots of digging around and trial-and-error to figure out what to do with them — I often just called (bean object) , but still had to dig through the Java method, searching for the name of getters to actually retrieve the underlying string (e.g. “email sender”). Earlier this week, I decided to start a project to use LLMs to go through my Google Photos to find all screenshots of my podcast player, to retrieve the current playtime, so I can go back and find out what I thought was so interesting at the time. (When listening to a podcast, when I hear something interesting, I take a screenshot, in the hopes of going back sometime and doing something.) I found the Google Photos Java client to be even worse, to the point of being outright frustrating — I’m wading through objects like SearchMediaItemsPagedResponse, SearchMediaItemsPage, MediaItem, MiediaItemMetadata. (Building search filters was even worse, because you needed to call builders for each type of search parameter.) This was jarring to me, because I had used the REST API for Google Photos years before, and you just passed search filters as a string, and got back a nice JSON data structure, which is very easy to parse. After pondering this overnight, I think I will abandon using the Google Photos Java client, and instead use the REST API. (I will keep all the code to do the OAuth authentication, and I figured out how to generate an access token from the refresh-token.) My question: I’ve heard many people complain about having to deal with Java objects, getters, setters, etc. But this is the first time I’ve found it genuinely frustrating — to escape from it, I took two hours to learn more about the different types of OAuth tokens, generate that access token, so I could just use an HTTP client instead. How common is this situation in the Java environments? I found the Java clients for Drive, Gmail were bearable. Google Jib and Cloud Storage library were easy. But Photos to be nearly unusable (i.e., “the juice isn’t worth the squeeze.). Are there ways to easily tell which Java libraries have this characteristic? And maybe more concretely — how have people’s experiences been using the Google Java libraries?] Thank you in advance!

hiredman17:02:48

I find the java clients for google apis to be extremely low quality, they are obviously machine generated from an api description, but generated in such a way that every different json document gets a different type, with little to no checking that the members of the type are valid until you actually make an api call with them

hiredman17:02:23

google does publish their api descriptions (starting with https://discovery.googleapis.com/$discovery/rest?version=v1 which is their api for listing apis) and I have used those to create my own aws-api style clojure clients

genekim18:02:46

Thank you — this is super helpful, and it’s good to know that I’m not crazy. I had assumed that, given that most of these Google services were written in Java, that the Java client libraries would be super ergonomic. (Because, I assumed that’s what the Google devs were using internally!) I had seen the API descriptions, but never knew what they were used for — this is great!

hiredman18:02:50

the format for the description seems to be close to but not exactly the openapi format, so my guess is the descriptions are themselves generated from a google internal protobuf definition of the service

Alex Miller (Clojure team)18:02:46

same story in the AWS api - the clojure wrapper for the Java API is a pain, or the cognitect (now nubank) aws-api library wraps the rest API and lets you work directly in data

genekim18:02:29

Honestly, I’ve never seen an API like Google Photos before — yesterday, I was literally thinking, “how can anyone make something so cumbersome to use? after all, it takes work to name all of these objects.” Your explanation about protobuf -> object makes so much sense. The genius of the aws-api library is now so evident, @U064X3EF3!

seancorfield18:02:41

My experience with Java APIs (and, frankly, C++ APIs before that stretching back into the 90s) has often been that they can be terribly verbose to work with -- compared to bare HTTP APIs. I think people got used to awful stuff like CORBA and SOAP and then just applied the same approach to more modern remote APIs as well 😞 A lot of these SDKs wrapping APIs are a really good example of what Perlis said about functions and data structures! 🙂

genekim20:02:26

Haha. Totally. The first time I saw what a SOAP API looked like, my reaction was, “is this a joke?” In the 1980s, I wrote a SunNFS client, which was so easy. SunRPC was so simple, CORBA was utterly incomprehensible to me, luckily I never had to personally use it. Thank you for all the validation, all — can’t wait to abandon most of what I wrote yesterday and use Hato instead! ( @U04V70XH6 , thanks to you, I’m ditching most of the Apache commons libraries and Jackson, after finding it surprisingly smooth and easy and not scary to migrate!)

1