Introducing: Java client v3

[Ant-hem]

Introducing Java Client v3 ☕️

ChangeLog/ New features

Maven

To get the beta version add this to your pom.xml

<dependency>
         <groupId>com.algolia</groupId>
        <artifactId>algoliasearch-core</artifactId>
        <version>3.0.0-beta-2</version>
 </dependency>

<dependency>
        <groupId>com.algolia</groupId>
         <artifactId>algoliasearch-apache</artifactId>
         <version>3.0.0-beta-2</version>
</dependency>

Less dependencies!

• org.apache.httpcomponents.httpasyncclient
• com.fasterxml.jackson.core / jackson-core / jackson-databind /jackson-datatype-jsr310
• And that's it...

Injectable HttpCient

The default HttpClient is httpasyncclient from Apache. If you want another one, just implement the IHttpRequester interface with your favorite HttpClient and inject it!

New test suite!

• Powered by JUnit5
• Running in less than 30 seconds locally! ⚡️

Asynchronous and synchronous methods in the same class!

Before, asynchronous and synchronous methods were split in two different classes. Now, they are reunited in the same class!

All asynchronous methods are suffixed with the async keyword and return a CompletableFuture.

SearchClient searchClient = DefaultSearchClient.create(ALGOLIA_APPLICATION_ID_1, ALGOLIA_API_KEY_1);
SearchIndex<Employee> index = searchClient.initIndex("employees", Employee.class);
    
// Async Code
CompletableFuture<SearchResult<Employee>> searchFuture = index.searchAsync(new Query("algolia"));

// Sync code
SearchResult<Employee> search = index.search(new Query("algolia"))

Useful helper: waiTask()

All Algolia's asynchronous operations can now be awaited like this:

index.setSettings(indexSettings).waitTask();

Static factories

We added static factories to Algolia's POJOs such as Synonyms, Rules to help you build valid Algolia's objects.

    Synonym wiiToWiiu =
        Synonym.createOneWaySynonym("wii_to_wii_u", "wii", Collections.singletonList("wii u"));

Getting started locally:

• Clone the repo and checkout on the develop branch.

• Build the project

mvn clean install

• Run the tests

mvn clean test

[ElPicador]

Really nice improvements 👍

[Ant-hem]

ping @BenoitPerrot ! :) Integrated some of the improvements we discussed yesterday.

[PLNech]

Superficial review considering the changeset's size, but still a few (hopefully useful) comments 🙃

[PLNech]

Did you choose to stop reporting Code coverage?

[PLNech]

Still jacoco in pom.xml

[Ant-hem]

Nop I don't want to drop it! I removed it temporarily at the begining of the project. I'll add it back in a few days :)

[PLNech]

Could benefit Nullability annotations (same for HttpResponse) :)

[PLNech]

Same for any model which would be manipulated by our users, when its fields are not covered by methods with Nullability annotations

[Ant-hem]

Could you please elaborate? 🤔 Do you mean to add annotations on the constructors parameters?

[PLNech]

I mean adding annotations wherever our users might benefit it:

• Constructor parameters of classes they could instantiate (not convinced it would be relevant here, as I don't think they have to create a new HTTPRequest() anytime)
• Annotations on public fields / public {g,s}etters that the users would manipulate to avoid unnecessary null-checks (e.g. if headers is never null, would mark getHeaders() as @NonNull)

I think this can be applied more consistently in some classes, e.g. :

• new Variant(...) takes a @NonNull String index in constructor
  -> Variant.getIndex() could be annotated as @NonNull
  -> Variant.setIndex() should have its param annotated as @NonNull

You might want to use Intellij's Infer Nullity to quickly generate consistent annotations based on your current codebase 🙃

[Ant-hem]

Thanks for the clarification! Neat idea. I'll look at it.

[PLNech]

Provided you resolve the last unsolved discussions, LGTM 👌

[Ant-hem]

Provided you resolve the last unsolved discussions, LGTM 👌

Thanks! Still need to have a look at the Nullability annotations for some POJOs :)