Toolkit extensibility threatened by java method size limit (#237) · Issues · ExaHyPE / ExaHyPE-Engine

Toolkit extensibility threatened by java method size limit

Problem description

When adding a few more tokens to the exahype.grammar file, the ExaHyPE Toolkit does not compile anymore. The compilation stops with the following error:

javac -cp ../lib/commons-cli.jar -sourcepath . eu/exahype/GenerateSolverRegistration.java  
eu/exahype/parser/Parser.java:104: error: code too large
    public Start parse() throws ParserException, LexerException, IOException
                 ^
1 error

Function parse() in file eu/exahype/parser/Parser.java contains a large switch-case statement considering nearly 3000 cases and has more than 17000 lines of code. Parser.java is unfortunately autogenerated by SableCC.

The Typical Let's rewrite everything! Proposal

From my point of view, above issue is just another reason why we should abandon SableCC grammars and switch to a proper data serialisation format like JSON or YAML (internally). Validation can be performed via JSON schemata. It would be still possible to keep our current specification file format. We would just introduce a precompilation step.

Additionally, we could consider to rewrite the toolkit in python. A lot is realised via template files anyway and the code generator for the optimised kernels is written in python, too.

Problem description
-------------------
When adding a few more tokens to the `exahype.grammar` file, the ExaHyPE Toolkit does not compile 
anymore. The compilation stops with the following error:
```
javac -cp ../lib/commons-cli.jar -sourcepath . eu/exahype/GenerateSolverRegistration.java  
eu/exahype/parser/Parser.java:104: error: code too large
    public Start parse() throws ParserException, LexerException, IOException
                 ^
1 error
```
Function `parse()` in file `eu/exahype/parser/Parser.java` contains a large `switch`-`case` statement
considering nearly 3000 cases and has more than 17000 lines of code.
`Parser.java` is unfortunately autogenerated by SableCC.

Further reading:
* https://dzone.com/articles/method-size-limit-java
* https://stackoverflow.com/a/17422590

The Typical *Let's rewrite everything!* Proposal
------------------------------------------------
From my point of view, above issue is just another reason why we should abandon SableCC grammars and switch to a proper data serialisation
format like JSON or YAML (internally). Validation can be performed via JSON schemata. It would be still possible
to keep our current specification file format. We would just introduce a precompilation step.

Additionally, we could consider to rewrite the toolkit in python. A lot is realised via template files anyway and
the code generator for the optimised kernels is written in python, too.

Edited Aug 04, 2018 by Dominic Etienne Charrier