[Bindgen] Module level mappings could lead to cyclic dependencies

[IrushiL]

Description: When generating module-level mappings Java packages are mapped onto Ballerina modules. However, doing this could cause cyclic dependencies since Java packages are allowed to make cyclic imports within the Java module they reside in and since it supports dynamic class loading.

This design issue should be sorted out if we are to support module-level mappings for Ballerina bindings. The alternative approach will be to let users use the single directory mappings.

Steps to reproduce: Assume there are 2 packages org.test.first and org.test.second and that these contain the following classes.

org.test.first.A 
org.test.first.B

org.test.second.A
org.test.second.B

Imagine a scenario where the user tries to import org.test.second.A in org.test.first.A and org.test.second.B in org.test.first.B. Even though this would be a valid import in Java, this would cause cyclic imports in Ballerina bindings.

Affected Versions: Ballerina Swan Lake Beta 2

OS, DB, other environment details and versions:

Related Issues (optional): https://github.com/ballerina-platform/ballerina-lang/issues/31855

Suggested Labels (optional):

Suggested Assignees (optional):

[sameerajayasoma]

Random thought: Can we create a Ballerina module per Java Class?

[IrushiL]

In order to sort this design issue, we could generate a single Ballerina module per Java library, since we can make the assumption that Java modules do not have cyclic dependencies among them.

If we are to go ahead with this approach, the following design changes will have to be done.

Current Approach:

• The Java package structure in the default bindgen approach is depicted using the breakdown of modules per each Java package.

  Java package -> Ballerina module

• Here the importing of modules in the user's source code is very similar to importing of Java packages and the organization of packages is very clear.

E.g.

import yaml_package.java.io as javaio;
import yaml_package.java.lang as javalang;
import yaml_package.org.yaml.snakeyaml as snakeyaml;

function foo() {
    snakeyaml:Yaml yaml = snakeyaml:newYaml1();
}

Proposed Approach:

• Instead of mapping a Ballerina module to a Java package, an entire Java library is mapped to a Ballerina module. This would be similar to generating single directory bindings. All bindgen files will be created inside a single directory.

  Java library -> Ballerina module

• In order to make the Java package hierarchy clear in the generated bindgen code and to handle duplicate simple class names, we could make the following changes.

  1. Rename the file name from the simple class name to a name that would uniquely identify the fully qualified class name.

2. If it is possible to determine a simplified name that would represent the fully qualified class name, like in the case of default Java packages or by using the artifact id, we could use a unique simplified prefix before the simple class name.

E.g.

javaio_FileInputStream
javalang_String
snakeyaml_Yaml

3. The class names need to be changed similar to the file names, we could use the same unique prefix in front of the simple class name.

E.g.

function foo() {
    snakeyaml_Yaml yaml = snakeyaml_newYaml1();
}

4. The rest of the implementation should ideally be unaltered.

[IrushiL]

The workaround would be to generate single directory mappings using the (-o|--output) <output> option in the bindgen command.