sdk-generator
sdk-generator copied to clipboard
Show some love ❤️ to the Java SDK
Motivation
Recently I was exploring the Java SDK, and I noticed that it is somewhat difficult to maintain, especially compared to the Python, Go, or JS SDKs, which are well-maintained. Several libraries are outdated - for instance, the HTTP mocking library, which has a bug when handling multiple async requests. Additionally, there are tons of duplications, and Javadocs are almost non-existent.
I have identified the following areas that could be improved, and I'd like to hear your thoughts on the proposed ideas.
I am willing to take the lead on implementing these changes.
Tests
-
Adopt WireMock: This library is a standard for mocking API responses in enterprise projects and is highly reliable for such tasks.
-
Switch to AssertJ: AssertJ is another enterprise standard. Adopting it would help us avoid overly complex assertions like this:
ClientBatchCheckSingleResponse response1 = response.getResult().stream()
.filter(r -> r.getCorrelationId().equals("cor-1"))
.findFirst()
.orElse(null);
assertNotNull(response1);
assertTrue(response1.isAllowed());
assertEquals("user:81684243-9356-4421-8fbf-a4f8d36aa31b", response1.getRequest().getUser());
ClientBatchCheckSingleResponse response2 = response.getResult().stream()
.filter(r -> r.getCorrelationId().equals("cor-2"))
.findFirst()
.orElse(null);
assertNotNull(response2);
assertFalse(response2.isAllowed());
assertEquals("folder:product", response2.getRequest().getUser());
- Revive Integration Tests: Effort should be put into "resurrecting" integration tests. These should be connected with Testcontainers as they are currently, but additional tests should be added.
HTTP Client
First of all, I’d like to ask: why was the Java HTTP Client chosen? Were there specific reasons or constraints that led to this decision?
I believe a better alternative would be Apache HttpComponents HttpClient. However, I acknowledge that I might not be aware of all the pros and cons considered when this library was selected.
Template structure
Currently, all template files are located in a single directory and prefixed by their destination. I suggest adapting the directory structure to better organize the templates, similar to how it’s done in other SDKs.
Java baseline
The SDK currently uses Java 11 as its baseline version. However, most major players, such as Spring and JUnit, have set their baseline version to Java 17. It might be a good idea to align with this trend since Java 11 is no longer supported.
Moreover, our spring-boot-starter also uses Java 17, which further supports the case for upgrading the baseline version.