geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <>
Subject Re: [PROPOSAL] adding java-jq to GEODE dependency for testing
Date Wed, 25 Sep 2019 23:27:45 GMT
I don't know enough about the limitations between the two libraries. BUT

I would prefer, like Kirk, some consistency w.r.t. implementations. 
Also, this is for testing, so I'm really questioning are we going to be 
pushing the boundaries of what this library can do. In addition, if 
there would be some extra steps that we might have to do, to confirm the 
validity of the returned JSON, compared to the native jq implementation, 
so be it.

But, maybe the other question we have not yet answered is, what is the 
our perception on the lifetime of this implementation. IF we go with the 
pure java implementation AND we are so tightly bound to it and they stop 
development on it, then we have a whole team of java devs that can take 
it over and fix/improve. In the native implementation, this is less 
true, so it really becomes a question about, can we maintain it if 


On 9/25/19 4:20 PM, Kirk Lund wrote:
> I would prefer we stick to one family of libraries for JSON. So, if there's
> a comparable release from Jackson, then I think we should go with that
> instead.
> On Wed, Sep 25, 2019 at 12:55 PM Owen Nichols <> wrote:
>> The Jackson-jq project actually imports the full testsuite from the “real"
>> jq project, and asks that any discrepancy be reported as a bug.  They list
>> the known differences in great detail…so unless you are using $__loc__ <
>>$__loc__> or date arithmetic
>> or file I/O in your jq queries, everything else is there.
>> Since the goal of using jq in tests is really to validate against the
>> “real” jq that customers would be using, that might be a good argument for
>> using the native wrapper approach.  On the other hand, since Geode's usage
>> is entirely in tests, switching to another implementation should be easy to
>> validate, just run the tests.  And since the set of JQ inputs is fully
>> under our control, it wouldn’t be hard to work within the constraints of
>> the pure-java implementation.
>> I don’t have a strong opinion on pure-java, just brought this up since Dan
>> mentioned the concern with introducing native libs.  I don’t know if any
>> Geode developers are running the tests on platforms other than the 3
>> supported by arakelian (Mac/Windows/Linux).
>>> On Sep 25, 2019, at 10:41 AM, Jinmei Liao <> wrote:
>>> I did look at jackson-jq before I considered java-jq, but it is a
>>> re-implementation of jq and this statement on that site puts me off:
>>> "jackson-jq
>>> aims to be a compatible jq implementation. However, not all the features
>>> are available; some features are not relevant as being a java library and
>>> some features are just yet to be implemented."
>>> On Wed, Sep 25, 2019 at 9:57 AM Owen Nichols <>
>> wrote:
>>>> For a pure-java implementation, might be worth considering
>>>>> On Sep 25, 2019, at 9:40 AM, Dan Smith <> wrote:
>>>>> +1 - sounds good.
>>>>> BTW - We've previously found libraries that use JNA tend to be more
>>>>> flaky/platform dependent than pure java libaries - for example we
>> ripped
>>>>> out a snappy native wrapper in favor of a pure java implementation.
>>>>> -Dan
>>>>> On Wed, Sep 25, 2019 at 8:39 AM Anthony Baker <>
>> wrote:
>>>>>> Sounds good, thanks for the heads up.
>>>>>> Anthony
>>>>>>> On Sep 25, 2019, at 8:37 AM, Jinmei Liao <>
>>>>>>> Management rest api wants to add some default jq selector to
>>>> swagger
>>>>>>> api docs so that the downstream client tool can use it as a starting
>>>>>> point
>>>>>>> to filter/format the json response to a more readable form. In
>> to
>>>>>>> test these jq selectors, we would like to use a java library
>> described
>>>>>>> here:, it basically provides
>>>> java
>>>>>>> wrapper around 'jq' tool. Github shows both MIT and apache license.
>> We
>>>>>> will
>>>>>>> only be using it for testing.
>>>>>>> --
>>>>>>> Cheers
>>>>>>> Jinmei
>>> --
>>> Cheers
>>> Jinmei

View raw message