João Abecasis

This is what I found: - the test has a race condition in that it is not able to ensure both consumers have joined the consumer group when they start...

Another way to fix the test may be to switch it to use `partitionsMapStream`, and then check that there are no duplicate records whenever the assignment changes. Perhaps that's a...

Picking up the conversation here again, I happened upon a couple more interesting inputs where allowing identifiers to start with numbers leads to unexpected results, namely due to the way...

I have some concerns about the approach taken in https://github.com/schibsted/jslt/tree/own-json-interfaces to drop the Jackson dependency. Rolling a custom JSON parser adds significant complexity to the project and is also added...

One way we could define the success criteria for a JSLT without Jackson could be that we're able to usefully maintain both the existing `jslt-jackson` interface and the new `jslt-own-json-interfaces`...

I understand and can sympathise with some of the motivations for moving away from Jackson. We regularly have to deal with dependency hell across a few of our projects with...

Besides concerns that may be more operational than development related, I think these two stated goals require that we ponder where we're going with this effort: > - Potentially better...

Would an approach like that taken in https://github.com/jimblackler/jsonschemafriend#format be feasible? It seems that, in that project, they define interfaces in terms of Java interfaces, and the user is then responsible...

Apologies. In my last comment I meant to suggest (and didn't) that the JSLT runtime could be defined in terms of Java interfaces. Of course, JSLT should still be usable...

I would like to understand a little bit more the reasoning for using a `throwOnFailures` parameter, as opposed to a fallback parameter as is customary (as pointed out in #152)....