Supported Java version for input source code? (3.0.4)

[AM307]

Hello,

I just wanted to ask which input Java source code versions are officially supported by the latest 3.0.4 release.

It seems the ASTParser compiler options used to be set to Java 20 and were then reverted back to Java 8: 1e60433

Support for record declarations was seemingly added here: 139a701

Still, it seems record declarations do not get detected by the current version. The types List of the CompilationUnit as generated in gr.uom.java.xmi.UMLModelASTReader appears to be empty.

[tsantalis]

Hello Andre,

Indeed, we added support for matching Record declarations, but when the compiler options are set to Java 20,
record is considered a Java keyword.
Therefore, if some older java code (i.e., before records were introduced in Java) contains a variable named record
the Eclipse JDT parser will skip parsing this code (when set to Java 20 compatibility).

As a result, we decided to go back to the original configuration options, as we had some failing tests.

A proper solution would be to somehow detect the Java version for each commit and setup dynamically the compiler options.
However, this is not so easy. If you have any solution to suggest, I would be glad to hear it and implement it.

[AM307]

Hello @tsantalis,

Thank you for the response. I did not consider this breaking change and agree that Java version detection would be difficult to implement.

I suppose allowing the library client to specify what version of Java is used (if they have access to such knowledge) and falling back to Java 8 would be a possible option that would not require any detection mechanism. Then again, this would only be a viable option for repositories which did not change Java version mid-development.

[tsantalis]

Hello @AM307

We try our best to have simple APIs, so that they are easy to use.
Perhaps, we can extend the APIs to have an additional parameter for the Java version, and have the existing APIs pass Java 8 as the default value.

Ideally, we would like to have an internal mechanism to detect the Java version of the commit, by extracting the Java version from build files, such as build.gradle or pom.xml
However, the Java version is not always specified in build files.

I will have to think better about it, as this is an important issue.
In the way Eclipse JDT Parser is designed, it skips parts of the AST that do not comply with the specified Java version.

[tsantalis]

@AM307

I have some good news about this issue.
After some investigation, we found that the Eclipse Parser generates some problems,
when there exist parts of the AST that cannot be parsed.
Specifically, when parsing a record declaration with 1.8 compatibility, it generates a problem suggesting the use of Java 16 compatibility to parse record declarations.

So, our idea is simple.
We will collect all problems reported by the ASTParser initially with 1.8 compatibility,
and based on the reported problems, we will adjust the compatibility and re-parse.
We are working on this feature right now.

[tsantalis]

@AM307

The issue has been fixed with the latest commit 15cada7
We can process now record declarations.
Please give it a try and let us know.

[AM307]

Sounds great!
I will be sure to give it a try when I find the time.

[tsantalis]

@AM307
FYI, we fixed a bug related to record declarations. Everything should be working fine with the latest release 3.0.7