Bernardo Sulzbach

I don't think it could have been patched in any way without breaking existing code. That, combined with the slow death of the project, is why I think this wasn't...

Right now names and values are stored using lists, so an order-independent comparison could be as expensive as O(m·n) where m and n are the number of values. How do...

@ralfstx I like the idea. I don't know if your reasoning for the `equals` method has been documented anywhere else, but it would be nice to have it in the...

@ralfstx glad we agree on Javadoc'ing what we consider JsonObject equality. Documenting the decision is even more important than the decision itself. I don't really care about the performance of...

I think I disagree mainly because of the design rationale of this library. We start by giving it a equalsIgnoreOrder() because it seems almost a requirement to conform to JSON,...

**minimal**-json cannot and **should not** get "nice features" for the sake of convenience. > And what's your opinion about test output on failure? I've missed that one, please provide a...

I do agree that "expected true, found false" is not very informative, as any reasonable developer would. However, I don't think that we should expose internals or add methods to...

> To do this, I see two ways: one is O(m . n) and the other one is O(1). O(1) was a typo, right? The second solution is linear, not...

> I haven't understand this part: "ask everyone to write ordering-independant equality checks". Which checks would those be? I simply meant that I believe the library should provide an equalsIgnoreOrder()...

> @mafagafogigante I'm not generally opposed to the idea of a toMap() method, but I see your concerns. @ralfstx I think you misunderstood me a little bit. I don't really...