We announced the first release of unify-jdocs on HN back in August 2020. Since then, unify-jdocs has had multiple feature enhancements and has been used extensively within American Express as part of the project it was developed for. We have had tremendous success with it and have been able to reduce the size of our codebase substantially, make it much easier for developers and improving maintainability and agility significantly. In the process, the API of unify-jdocs has been invoked billons of times and demonstrated great reliability in production. The original post can be found here: https://news.ycombinator.com/item?id=24332382.

My reason for posting again is to continue promoting unify-jdocs. This kind of a JSON manipulation library, in my opinion, does not exist elsewhere. Unify-jdocs makes life simpler for any Java development project that works with JSON documents. While I can understand that for projects that deal with few simple JSON documents (served well by the likes of Lombock, Records, etc.), unify-jdocs absolutely shines in projects that have to deal with multiple complex JSON documents (and their transformations) and whose structure can undergo change over the project lifetime. It also provides for a much simpler way of validating documents as compared to JSON schema. Why would we not want to read and write any JSON path in one line of Java code? The counter argument which I have faced (even from senior folks) is around type safety. When we use Records or Lombock or POJOs, the read / write operations on the document are statically compiled into the JAR file, whereas, in the case of unify-jdocs, these operations take place dynamically at run time. In my opinion, the benefits we get from using dynamic typing far outweigh the benefits of static typing using POJO / model classes. Looking forward to discussing more. Thanks.