Revisiting DMN Editor Import Java Classes feature

[yesamer]

To know more about the feature, I invite you to take a look at my below blog post. https://blog.kie.org/2022/05/dmn-types-from-java-classes.html

The architecture behind that feature has some weak points, in detail:

• It relies on a technology designed for Text Editors: Despite the idea of taking advantage of the LSP protocol and the JDT module gave us access to a power tool to infer Java class info, we needed to implement an unconventional way to use it (simulating a java file class autocompletion request)
• Highly coupled with the "Java Language VSCode extension" version: That VSCode is not under our control, any extension update might break the compatibility with our code (already happened in the past). We're forced to stay with the latest extension version because VSCode always updates the extensions by default, and asking our users to change this behavior results in a forceful act.
• JDT.LS eclipse plugin relies on ephemeral repositories.: Every JDT.LS version relies on an eclipse repository that gets removed every 3 months ---> https://github.com/eclipse/eclipse.jdt.ls/issues/1970
• We are forced staying stick with the latest "Java Language VSCode extension" & JDT.LS version: For the above 2 reasons
• The feature is enabled in VSCode channel only: The ideal solution should work in KIE Sandbox as well, and this is not possible for an architecture that depends on a VSCode extension.
• The feature is enabled in VSCode channel only: The user is forced to create a specific java class to enable the functionality, making it cumbersome.
• Cached old versions: Under some conditions, it seems cached old versions of our extension may interfere with the latest installed version. Please consider this https://github.com/apache/incubator-kie-tools/issues/2110: In that case, the user was forced to reinstall VSCode to have the functionality available.

Based on the above reasons, we decided to temporarily not enable the "Import Java Classes" in the new DMN Editor, to investigate and assess a more robust solution, which is the scope of this ticket.

Possible solutions so far:

1. Continuing with the current approach. With the cost to pay to keep the JDT.LS dependency updated. In addition, I suspect we'll need to base our code on tycho 4.x and JDK 17 to stay updated. In addition, this will not work on KIE Sandbox. 1b. Using the same approach, but using https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java extension instead of the "Java Language VSCode extension". In my opinion, this leads to the same drawbacks as the previous point.
2. Implementing a specific service on the "extended-services" modules, that returns the list of the Java Classes and their public methods present in the user's project. "extended-services" acts like a backend for KIE Canvas (and in the future for the VSCode extension), it should be feasible implementing such a feature. A possible limitation is related to the Quakus native mode: in such a case, reflection has some limitations.
3. Using a Java parser that reads the Java Classes AST and returns the requested info (Java class names and public methods). A NodeJS library for that already exists (here), I tested it in this repo https://github.com/yesamer/java-parser-poc. This approach has a lot of limitations.
4. ...?

Another point to underline is that the feature is a key one for the Test Scenario too, as we need it for RULE-based Test Scenario.

[yesamer]

@tiagobento I updated the above description, discarding the 3rd solution option and adding another problem I faced with the current architecture in the last few days.

However, I think we need to make a decision about the direction of this feature, based on our future tooling strategy. The key point is: Should we have this feature working on VSCode only, or do we need it in the Sandbox too? Before replying, consider that such functionality is required by RULE-based scesim, and might be very useful in the case of a DRL editor. Relying on the current solution means not having that feature enabled in the Sandbox. I guess that clarifying this point can drive us to choose the better solution. Considering the problems we had maintaining the current architecture and the fact it works on VSCode only, I would prefer to explore the second solution.