GeezerVison is showing github.com — Update ANTLR grammar to support Java 1.8 syntax · Issue #3054 · processing/processing
Update ANTLR grammar to support Java 1.8 syntax #3054DescriptionOur current grammar is out of date and doesn't support many newer Java features. See also #3055. Reacted by Raphael Schweikert Activityjoelmoniz commented on Mar 23, 2015 @benfry I'd like to help out with this. Could you please let me know which features are missing/out-of-date at present? Here are a few missing ones that I have identified, although I'm not quite sure about how relevant/important they may be:
- Multi-catch support
- Support for the diamond operator
- Underscores in numeric literals (such as
int x = 30_000)
- Strings in switch
- Binary literals
- Support for lambda calculus
Thanks benfry commented on Mar 24, 2015 ContributorAuthor More actions Thanks for the interest. This is less about adding the language features one by one than it is finding an existing Java 1.8 grammar for ANTLR and making it work. This would be best handled by fixing #3055 first, and then going after this issue. miguel-negrao commented on Jul 12, 2016 cansik commented on Nov 26, 2016 kevinkyyro commented on Nov 26, 2016 I'm not actively working on it, but I've looked at it a bit and it seems tricky.
It looks like the currently used java 5 grammar is not a vanilla; I don't know ANTLR so it's difficult to try to tease out the modifications and then migrate them to ANTLR 4 since I couldn't find migration guides from ANTLR 2 to 3 and 3 to 4 (found one but not the other).
I wonder if it would make sense to migrate to a code or script-based preprocessor translating from processing syntax to valid java 5, then piping that through ANTLR with the vanilla java 5 grammar. It seems like it would make it easier to drop in the java 8 grammar, ideally without modification. This is based on the assumption that the preprocessor would be relatively simple; most of the modifications seem context-independent -- mainly just globals and type aliases, though type I guess type coercion could need a little more care if type aliasing is not sufficient. sampottinger commented on Mar 27, 2019 Hey there! Just to keep some threads updated... I revisited #3055, bringing it up to speed with processing's current master and #5753. I have a build of processing working (with a few particular error handlers being migrated) at sampottinger#15. I'll redirect that from my fork to this repo after #5753 is concluded. sampottinger commented on Apr 9, 2019 Hey there! Just a quick update for those tracking this thread. sampottinger#15 is stable and ready for feedback. I recommend testing using my master at https://github.com/sampottinger/processing. It has all of the PRs that branch off of #5753 merged in.
Unfortunately #5753 is still under review so there is likely a little runway on my fork but hoping to rejoin mainline soon. benfry commented on Jan 17, 2020 ContributorAuthor More actions locked as resolved and limited conversation to collaborators on Jan 17, 2020
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|