Implement Java SDK in configu

[Sadaf-A]

Description

Presently, configu extends its support to developers using Python, TypeScript, and Go. However, we're excited to introduce a new addition: a Java SDK.

Motivation

Adding support for a Java SDK for configu would greatly expand the accessibility and usability of the tool.

[Sadaf-A]

Shall we opt for Maven to handle our dependency management? If there's a consensus, I'll proceed with configuring the project using Maven.

[rannn505]

@Sadaf-A,thank you for taking the initiative on the Java SDK for Configu. Your insights and contributions are invaluable.

To address your query regarding Maven: While I'm not deeply ingrained in the Java ecosystem, I understand that both Maven and Gradle are popular tools for dependency management. Maven is both a dependency management tool and a central repository to publish dependencies, while Gradle is another tool primarily known for its build capabilities and dependency management.

If we're looking at the requirements:

1. HTTP Client: Java does indeed have a native HTTP client introduced in JDK 11. However, depending on our requirements, we might consider popular libraries like OkHttp or Apache HttpClient for more extensive features.
2. String Validation: I recommend conducting some research to identify a suitable library for this, as several libraries cater to different validation complexities.
3. Templating: The Mustache.java seems like a good fit, but let's ensure it aligns with our specific needs - https://github.com/spullara/mustache.java.
4. Development Dependencies: We'll need to identify and integrate tools for linting, formatting, testing, and generating reference documentation. Again, your guidance here would be beneficial given your familiarity with Java.

[Sadaf-A]

@rannn505 Thanks for the inputs.

You're right both maven and gradle are popular choices for managing dependencies. Both have their pros and cons but maven has an edge over gradle because it has been around for a long time and the The Maven Central Repository has all the dependencies that we may need. Also, maven follows convention over configuration (CoC) approach, team members can expect consistent and reproducible builds, regardless of their individual development environments. Hence, It would be a better choice for working in teams. It's maturity, standardization and stability makes it a more feasible option. However, gradle is comparable and equally good but while working on it we faced some issue and we had to shift to maven midway which was a hectic task. Therefore, I firmly believe maven may be a better choice. gradle uses groovy or kotlin whereas maven uses xml while some developers prefer xml, groovy is more concise and readable which leads to faster and more readable build scripts. gradle also has a better dependency resolution algorithm which is very helpful when we are working with a good amount of dependencies,
gradle also exceeds maven when it comes to plugin system gradle's plugin system is more modular therefore it allows you to include only the plugins you wish to use where as maven has a more monolithic approach towards this. gradle also has incremental builds so it can intelligently determine which parts of the build need to be re-executed based on changes, thus reducing the time required for building. maven also has this feature but gradle is definitely better.
All things considered gradle is more modern and efficient and maven is the standard and more stable. Any inputs from you would be appreciated but as of now I'm more inclined towards maven as it would help us manage our project better.

As for string validation I looked into it and unfortunately, as of now there is no library as extensive as validator.js available for java so we may have to include specific dependencies for validating certain strings. I joined online forums and asked there as well they had the same opinion. I will try to make a GitHub repo trying out different string validations and share the link.

We should definitely use Mustache.java as it would make the code more readable and enhance security as it escapes HTML characters by default which can prevent Cross Site Scripting (XSS) attacks and this security feature makes it really stand out among rest of the templating engines and libraries.

As for Development dependencies I have a few suggestions lombok with it's annotations makes the code way more concise and readable by reducing boilerplate code. For example we may not need to write getters and setters we can simply use @Getters @Setters annotations and for building default constructors we can simply add @NoArgsConstructor and many more annotations that will save alot of time for developers. And we have the jackson library for handling JSON objects I used it for serializing and deserializing JSON objects and I really liked working with it. I would urge you to look into these two libraries

For maintaining standard code format in java we can use spotless. In our project we only used spotless without any other tool as it was sufficient. Here, I would like your opinion as I believe we could use some other tools as well.

I would be honest I haven't much experience with unit testing in java but we can surely use JUnit as it is most widely used this sector we would have to explore more.

we can use javadoc for document generation but we would have to follow some conventions while writing code like for example comments that describe methods should look like

/**
 * This is a sample method.
 *
 * @param a The first number to add.
 * @param b The second number to add.
 * @return The product of the two numbers.
 */
public int multiply(int a, int b) {
    return a * b;
}

As our codebase grows we may need to reconsider our choices and review them regularly.

[rannn505]

@Sadaf-A I see the string validation as the major concern here, I will try to look for alternatives. Also in the background I will promote an issue of maintaining a self validation RegEx library so we can dump this validator dep.

[erzohrakhan]

Adding to @Sadaf-A comment
Maven has been around for a long time and has a large and mature community. It is still widely used in many Java projects.
Gradle: Gradle has gained popularity in recent years and is known for its innovation and flexibility. It has a growing community and is increasingly adopted in various projects.

We can use Spring Boot ( one of the most popular framework in Java)
Apache HttpClient: if we need a traditional, synchronous HTTP client with a focus on stability and configurability. It's a good choice for blocking, request-response scenarios.

Spring WebClient :Building a modern, reactive, and non-blocking application, It's ideal for high-concurrency and asynchronous use cases.

The alternative to Validator.js in the Java ecosystem for server-side validation is typically to use a combination of Java's built-in validation capabilities and libraries such as Apache common validator n Hibernate Validator

Mustache.java is a simple and flexible templating engine that can work well in many scenarios. It is particularly well-suited for applications where you want to keep templates clean and focused on rendering data.

There are several other templating engines available for Java that you can consider, depending on your specific needs.

Thymeleaf: Thymeleaf is a modern and feature-rich templating engine that integrates seamlessly with Spring Framework, including Spring Boot. It offers a powerful and expressive syntax for building dynamic web pages. Thymeleaf is known for its natural templating and easy integration with Spring's model-view-controller (MVC) architecture.

FreeMarker: FreeMarker is a robust, versatile templating engine that provides a template language that is both readable and extensible. It's often used with Spring applications and offers good support for conditionals, loops, and macros.

Lombok: We will be dependent on Lombok for further updates; A year back there was an issue with Lombok when projects wanted to migrate to Java 16 but Lomok was not supporting it
(Lombok is basically a compiler hack that relies on non-public APIs to work. These APIs were there up to Java 16; Java 17 aimed to strengthen encapsulation by further restricting access to internal APIs. This enhances security and encourages developers to use public APIs. )
projectlombok/lombok#2681
We now have records to avoid a lot of boilerplate code
In my opinion we should avoid Lombok

Jackson: Spring boot has support for this;

Testing: for unit testing we can use Mockito and Junit

Documentation:Swagger/OpenAPI: If Java application includes RESTful APIs, we can use Swagger/OpenAPI to document API endpoints.

[Sadaf-A]

Adding to @Sadaf-A comment
Maven has been around for a long time and has a large and mature community. It is still widely used in many Java projects.
Gradle: Gradle has gained popularity in recent years and is known for its innovation and flexibility. It has a growing community and is increasingly adopted in various projects.

We can use Spring Boot ( one of the most popular framework in Java)
Apache HttpClient: if we need a traditional, synchronous HTTP client with a focus on stability and configurability. It's a good choice for blocking, request-response scenarios.

Spring WebClient :Building a modern, reactive, and non-blocking application, It's ideal for high-concurrency and asynchronous use cases.

The alternative to Validator.js in the Java ecosystem for server-side validation is typically to use a combination of Java's built-in validation capabilities and libraries such as Apache common validator n Hibernate Validator

Mustache.java is a simple and flexible templating engine that can work well in many scenarios. It is particularly well-suited for applications where you want to keep templates clean and focused on rendering data.

There are several other templating engines available for Java that you can consider, depending on your specific needs.

Thymeleaf: Thymeleaf is a modern and feature-rich templating engine that integrates seamlessly with Spring Framework, including Spring Boot. It offers a powerful and expressive syntax for building dynamic web pages. Thymeleaf is known for its natural templating and easy integration with Spring's model-view-controller (MVC) architecture.

FreeMarker: FreeMarker is a robust, versatile templating engine that provides a template language that is both readable and extensible. It's often used with Spring applications and offers good support for conditionals, loops, and macros.

Lombok: We will be dependent on Lombok for further updates; A year back there was an issue with Lombok when projects wanted to migrate to Java 16 but Lomok was not supporting it
(Lombok is basically a compiler hack that relies on non-public APIs to work. These APIs were there up to Java 16; Java 17 aimed to strengthen encapsulation by further restricting access to internal APIs. This enhances security and encourages developers to use public APIs. )
projectlombok/lombok#2681
We now have records to avoid a lot of boilerplate code
In my opinion we should avoid Lombok

Jackson: Spring boot has support for this;

Testing: for unit testing we can use Mockito and Junit

Documentation:Swagger/OpenAPI: If Java application includes RESTful APIs, we can use Swagger/OpenAPI to document API endpoints.

Hey, @erzohrakhan I want to express my gratitude for your valuable assistance. Java isn't my strongest suit, so your guidance has been a real help. I'm looking forward to working together to create the best implementation possible.

I agree that Spring Boot is a must, and I appreciate the heads-up about Lombok's compatibility with the latest Java versions as I was not aware of that and it would've been a severe issue.

After checking out Apache Common Validator and Hibernate Validator, I'm not sure if they cover all the specific validation needs in the ConfigSchema.ts which is linked here https://github.com/configu/configu/blob/main/ts/packages/ts/src/ConfigSchema.ts#L21 and the number of validations will only grow with time I'm not sure if these libraries will be able to keep up. Your opinion on this would be much appreciated.

I would urge you to join the configu discord server.

Thanks again for your support and collaboration.

Best Regards,
Sadaf

[erzohrakhan]

@Sadaf-A Yes, you are right we don't have all the validations in Java, Apache validator and Hibernate;
So whatever is not available we have to write custom code or integrate any other third-party library