#53 Error while instrumenting class com/steadystate/css/parser/SACParserCSS21TokenManager

[Vincent Massol]

The problem is when using jacoco and cssparser. CSSParser has a very long class SACParserCSS21TokenManager.java which makes it choke, as described at http://stackoverflow.com/questions/14559117/how-do-i-disable-jacoco-agent-after-jacocoreport (we're having the exact same issue on the XWiki project).

It would be nice if this class could be refactored to make it a bit shorter and thus more jacoco-friendly :)

Thanks a lot for your nice tool!
-Vincent
XWiki committer

[RBRi]

Sorry Vincent,
i know that problem because i have used emma in the past for checking the code coverage. The Token Manger classes are generated by JavaCC so at the moment i see no solution here.
Maybe cobertura is a bit more clever in handling this kind of classes.

Thanks for using CssParser.

[Vincent Massol]

Thanks for answering. The generated jjMoveNfa_0 method is huge (over 4000+ lines) and thus probably not that far from the 64K java limit for a method.

I think one answer is to review the grammar and change so that it doesn't generate such long methods. See http://www.javakey.net/1-java/10e00279c64f9645.htm

There's also https://javacc.java.net/doc/lexertips.html which provides "Tips for writing good JavaCC lexical analyzer specs. This can also help you if you are getting 'code size too big' error message from javac when you compile the generated token manager."

I haven't checked the CSSParser javacc grammar though so I don't know how easy/hard this would be.

Thanks

[RBRi]

Vincent,

as i said, i'm aware of this problem. The size of the lexer is at the moment the biggest pain point in the ongoing development of the CssParser. I spend a lot of my time during the last months trying to reduce that size. But thats not that simple because of some strange parts of the css spec.

Feel free to provide a patch if you have found a way to simplify the lexer.

RBRi