paulirwin commented on issue #268: URL: https://github.com/apache/lucenenet/issues/268#issuecomment-2444453566
I looked into this a bit last night, and the situation is less than ideal. To augment/update the original two possibilities in the original issue from 2019 with some other ideas (items 3+ below): 1. ~~Find a similar tool to javacc in .NET that supports similar options that were used in javacc, and create a converter tool to change the javacc configuration into a configuration that the .NET tool supports.~~ This does not seem to exist, as far as I can tell. 2. ~~Do a direct port of javacc to C#, and fix its logic to use a more efficient control flow mechanism than exceptions (perhaps goto would be the most direct replacement).~~ While possible, this is quite a large undertaking, as javacc even builds its own parser itself. I do not think this amount of effort is worth it, especially given that the queryparser jj files have only seen a few minor updates in the last 10ish years. 3. Convert the javacc syntax to ANTLRv4, like I did with Expressions.JS in #996. This is a significant undertaking though, as javacc syntax is not directly comparable to ANTLR. It's also fairly risky, as there might be subtle incompatibilities in the parsing that are not caught by our tests. It also has the potential for having worse performance (or better performance, who knows) - but we won't know until the work is done. And then it would be a divergent syntax that would be difficult to port future fixes to. 4. An idea I had last night is that I could add a build task library to my [JavaToCSharp project](https://github.com/paulirwin/JavaToCSharp), and instead of trying to automate building the jj file (or porting to ANTLR), we could automate converting the generated Java code from Lucene into C#, treating Java as an intermediate language for this purpose. I tested that the 4.8 generated QueryParser.java file converts successfully, although it has a few warnings I'd need to look into. If we could automate this as part of the build via a msbuild task (like the Antlr4BuildTasks project), that could be a good middle ground. I'll spend a few mental cycles on seeing if this is feasible and worth doing. One possible downside of this is we'd lose possible opportunity for optimizations of the code, unless someone wants to contribute the ability to add rewriting plugins to JavaToCSharp. 5. Leave it as-is and keep porting the generated code by hand (or converting one-off as needed with JavaToCSharp). At this point, I don't know if it makes sense to try to attempt this for 4.8, and that porting work is already done. I think we can revisit this for the next post-4.8 release, so I'm moving this back to the Future milestone for now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
