Andy Seaborne

Reading the JavaCC issue, it seems the query size is not the problem. It is the presence of large tokens over 2048 bytes. @SimonBin Is that correct? `SimpleCharStream` and `JavaCharStream`...

I don't see a PR on the javacc issue that is suitable. There is an interesting suggestion about lexical states. ARQ only parses from strings, not streams, and only from...

javacc/javacc#85 has not been integrated into javacc releases. Jena running it's own fork of javacc is highly undesirable - it's technical debt. Users must be able to build Jena and...

Does quite explain why there is a 100Mb literal in a query but no matter. SPARQL parsing is central so any changes need to be done carefully, and be proven...

Yes, good to report. It might be more of an issue in `INSERT DATA` although then there is usually the option of POSTing RDF. Fuseki has "Fuseki modules" so adding...

The issue we experience is buffer management. Linear growth of a few Kbytes for 100Mb is a lot of recopying. If it grew at say x1.5 (like a Java ArrayList)...

@SimonBin The contents of the literal (XML use of `"` or `'`) is up to the application.

@new-javacc In https://github.com/javacc/javacc/pull/85 the apraoch is a level of indirection but with the advantage that there is no contents copy. The current reallocation strategy in javacc is `char[] newbuffer =...

@new-javacc thank you for the suggestion for rewriting the grammar but it does not address the original report which is the buffer reallocation which is https://github.com/javacc/javacc/pull/85. For a 1Mbyte buffer,...

Thank you - a grammar change may help but `ExpandBuff` reading more characters is dominant.