jmespath-java

[iconara]

I just pushed the first release of jmespath-java to Maven Central only to find that you've just released a JMESPath implementation for Java just hours before... I don't know how far you've come with yours, from the code available in this repo it looks like very early days, so perhaps you want to save yourself some work? Our implementation is fully compliant, has a Jackson interface, as well as the possibility to write your own adapters for other JSON libraries, and you can easily add custom functions.

I totally understand if you want to keep things in-house, but just so that you know that there is another implementation out there.

[shorea]

This looks really interesting and could save us a great deal of work. Our implementation isn't complete and actually uses the Python JP CLI to generate an AST, we don't have our own lexer and parser yet. Do you still generate from antlr or have you handcoded the parser now?

[iconara]

We're dependent on ANTLR at runtime (org.antlr:antlr4-runtime). Not sure that we want to go down the route of hand coding a parser, at least not for a while.

[shorea]

Closing this issue as we have metrics around open issues.

Anyways, browsed the code and it seems like a very attractive option for us. We have to be careful about adding new dependencies to the SDK so antlr makes me a little nervous.

[iconara]

We're not super happy about the ANTLR dependency either, but it beats the maintainability nightmare of a hand coded lexer and parser. What if we just shadowed (is that the right word? shade?) the ANTLR runtime? I think we can figure out how to do that. If you want to talk more just drop me an email it's my first name at burtcorp.com.

[iconara]

@shorea we've experimented with maven-shade-plugin and think we can produce an artifact with a minimal ANTLR runtime shaded into our own package, so there will be no external dependency on ANTLR anymore. Would that work for you? You can see the work in progress here: burtcorp/jmespath-java#25.

[shorea]

I believe that would work for us. I'll schedule some time on our upcoming sprint to evaluate this implementation and see if we can pull it into the SDK.