Skip to content

GitLab

Notice to GitKraken users: A vulnerability has been found in the SSH key generation of GitKraken versions 7.6.0 to 8.0.0 (https://www.gitkraken.com/blog/weak-ssh-key-fix). If you use GitKraken and have generated a SSH key using one of these versions, please remove it both from your local workstation and from your LRZ GitLab profile.

21.10.2021, 9:00 - 11:00: Due to updates GitLab may be unavailable for some minutes between 09:00 and 11:00.

Closed
Created by Dominic Etienne Charrier@domchaOwner

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.

Further reading:

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 by Dominic Etienne Charrier