rascal
rascal copied to clipboard
usethesource
Add Java versions beyond 1.8
When I try to get going with rascal to apply it to my Java 11 project my understanding is that it won’t work due to missing support for Java 9 and later.
I would like support for Java LTS versions: 11 and 17. If possible every version.
Syntax seems to be available on https://docs.oracle.com/javase/specs/jls/se17/html/jls-19.html (also other versions).
But where to start?
The intent of having modern Java version support is that I can start writing transformations for library updates. E.g. to upgrade my project from jUnit 4 to 5. Or an easier start: to update from jUnit 4.12 to 4.13 and rewrite @Test(expected = NullPointerException.class) to Assert.assertThrows(…)
Please note that the current Java versions have an incorrect version indicated in the file name. https://github.com/usethesource/rascal/blob/master/src/org/rascalmpl/library/lang/java/syntax/Java15.rsc https://github.com/usethesource/rascal/blob/master/src/org/rascalmpl/library/lang/java/syntax/Java18.rsc
Both should have a . or remove the 1 as a prefix. Unfortunately that will break existing code…
Excellent issue! Are you looking for support in the abstract syntax suport and M3 relations too? or are we just looking for the extensions of the grammars? Maybe both would be good to do in concert.
Renaming the files seems a logical thing to do. The impact to existing clients would be a minor rename.
I'm not too sure what M3 is (yet?). Just entering this field from the point of view: I should be able to automate this.
ok that's clear. we have several analysis features for Java which are based on first running the Eclipse compiler front-end to extract all kinds of facts and relations. That model is called M3 and also is not supported beyond Java 8 in a certain sense (it skips fact extraction from lambda's for example). Although this is not relevant for you, for the current issue in general it is good to notice that that part too needs updating.
Just a brainwave: The Java language is backwards compatible until now I think. So I wonder whether only supporting Java 17 (as the latest version) should be enough for all use cases regarding parsing of code. Sure, when generating transformed code the target version is very much of interest.
I think that makes sense. It's not completely backward compatible because new reserved keywords were added here and there. It's smart to go ahead and implement Java17 first, and then perhaps extract the earlier versions to save time. The only issue would be those reserved keywords.
As implied by my lack of communication since last year: this has not been a priority and by now I’ve found OpenRewrite. Moving jUnit 4 to 5 already has a recipe.
thanks for the heads up; we have plans for hiring 4 to 5 engineers pending a big funding request. If that goes through this issue is certainly on of the first things. In the meantime, have fun!
We're not at Java 13 and Java 14 with preview on a branch that is soon to be merged. Thanks.