[Proposal] Language for Plugins

[AlexRuiz7]

Description

We want to start developing plugins for wazuh-indexer (OpenSearch). We need to decide the programming language to use, as we can use any language compatible with the JVM.

OpenSearch has both, Java and Kotlin plugins. We asked them about which one is preferred, but it's up to the authors to decide.

It's worth mentioning that the @wazuh/devel-indexer team is not familiar with the development cycle for OpenSearch plugins, neither with Kotlin, and only a bit with Java. We understand that Kotlin is getting more and more market share, but Java is still one of the most used programming languages nowadays, being the most one used for the JVM. Using Kotlin would add a second factor to our learning curve on developing plugins for OpenSearch.

The goal of the issue is to elaborate a comparison between the languages, to better understand the implications on using one or the another. This comparison must help us decide one of them with proper arguments and justification.

Java

• Bigger popularity overall.
• More legible code, easier to learn.
• Older.
• Functional programming added on latest version, but stands a bit behind the standard.
• 10 OpenSearch plugins implemented in Java, that we can use as examples.
• Requires a semicolon to end each statement.
• Most of the documentation is using Java.

Kotlin

• Less popular, but growing quickly.
• Modern approach.
• Less verbose.
• "Native" support for functional programming.
• 7 OpenSearch plugins implemented in Kotlin, that we can use as examples.
• Unknown language for us, steeper learning curve.
• No semicolon.
• Scarce or nonexistent documentation within OpenSearch.

[AlexRuiz7]

Code comparison

• Example of how to implement a REST endpoint in Java.
  • https://github.com/opensearch-project/asynchronous-search/blob/main/src/main/java/org/opensearch/search/asynchronous/rest/RestDeleteAsynchronousSearchAction.java
• Example of how to implement a REST endpoint in Kotlin.
  • https://github.com/opensearch-project/index-management/blob/main/src/main/kotlin/org/opensearch/indexmanagement/indexstatemanagement/resthandler/RestGetPolicyAction.kt#L39

[f-galland]

Below is an in depth comparison between the two languages from the Kotlin team themselves:

Kotlin fixes a series of issues that Java suffers from:

• Null references are controlled by the type system.
• No raw types
• Arrays in Kotlin are invariant
• Kotlin has proper function types, as opposed to Java's SAM-conversions
• Use-site variance without wildcards
• Kotlin does not have checked exceptions
• Separate interfaces for read-only and mutable collections

What Java has that Kotlin does not:

• Checked exceptions
• Primitive types that are not classes. The byte-code uses primitives where possible, but they are not explicitly available.
• Static members are replaced with companion objects, top-level functions, extension functions, or @JvmStatic.
• Wildcard-types are replaced with declaration-site variance and type projections.
• Ternary-operator a ? b : c is replaced with if expression.
• Records
• Pattern Matching
• package-private visibility modifier

What Kotlin has that Java does not:

• Lambda expressions + Inline functions = performant custom control structures
• Extension functions
• Null-safety
• Smart casts (Java 16: Pattern Matching for instanceof)
• String templates (Java 21: String Templates (Preview))
• Properties
• Primary constructors
• First-class delegation
• Type inference for variable and property types (Java 10: Local-Variable Type Inference)
• Singletons
• Declaration-site variance & Type projections
• Range expressions
• Operator overloading
• Companion objects
• Data classes
• Coroutines
• Top-level functions
• Default arguments
• Named parameters
• Infix functions
• Expect and actual declarations
• Explicit API mode and better control of API surface

Reference:

• https://kotlinlang.org/docs/comparison-to-java.html

[AlexRuiz7]

We are finally using Java as our main programming language for wazuh-indexer plugins, for the reasons listed below. We don't discard using Kotlin in the future.

• Core's language (OpenSearch)
• Easier to understand - softer learning curve.
• Better documented.
• Better engagement with OpenSearch devs and community.