You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update ANTLR grammar to support Java 1.8 syntax #3054
@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)
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.
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.
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.
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.
Activity
joelmoniz commentedon 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:
int x = 30_000)Thanks
benfry commentedon Mar 24, 2015
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 commentedon Jul 12, 2016
Lambda calculus is an abstract mathematical entity: "Lambda calculus (also written as λ-calculus) is a formal system in mathematical logic for expressing computation based on function abstraction and application using variable binding and substitution.". You probably mean lambda expressions.
cansik commentedon Nov 26, 2016
Is someone working on this issue or on #3055 at the moment? There is an existing grammar for ANTLR: https://github.com/antlr/grammars-v4/blob/master/java8/Java8.g4
It would be great to be able to write lambda expression.
kevinkyyro commentedon 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 commentedon 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 commentedon 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.
Move to ANTLR 4 with Java 11 lang features and localization.
Move to ANTLR 4 with Java 11 lang features and localization. (#5)
benfry commentedon Jan 17, 2020
Resolved in the 4.x series: https://github.com/processing/processing4