At its core, the library allows you to pass input data as key-value pairs and evaluate it against rules defined sequentially in either JSON or Excel-based decision table definitions. It supports both first match and all matches policies with strict or lenient validation modes. It can invoke external Java methods as part of rule evaluation or return values and even embed JEXL expressions to manage more complex rules.

The library allows decision tables to be defined as JSON or Excel files. While JSON based tables are recommended for production (since they can be versioned and tracked), they are not friendly to visualize and update. Accordingly, the library provides methods to convert from JSON to Excel and vice versa so that it becomes easy to visualize and make changes.

Developers can further extend functionality by invoking Java methods or embedding JEXL scripts directly within rule definitions. The library also supports analytics by generating events whenever rules are loaded or matches are fired.

We have used this library internally in American Express with great success and we hope the same for the community. It would be great to discuss and get feedback on the library. Thanks!

Comments URL: https://news.ycombinator.com/item?id=45841042

Points: 1

# Comments: 0

* 40 inch 21:9 aspect ratio. 34 is too small and 43 and above are too big

* QHD i.e. 3440 X 1440 resolution - why? Because it renders the programming fonts perfectly - many will complain about pixelation but for me it just seems perfect. This translates to a PPI of approx. 93 which is the same as for a 24 inch FHD monitor. Scaling spoils it for me

* Curve - not too less nor too aggressive - LG OLED is 800R which is way too much - on the other hand 2300R is too less - I think 1800 is ideal

* 60 Hz or more refresh rate

* Accurate color reproduction

* Matte finish / antiglare

Sadly, a curved monitor with the above specs does not exist. The only one as I mentioned is the LG OLED which has a far too aggressive a curve. There are some lesser known brands which come as flat which I currently use but I wish there was one that met all of the above.

On a side note, you will at some point in time have to deal with multi version workflows. I know that this is one feature that limits wide adoption of an orchestrator.

> The trend seems to be in the opposite direction. People became frustrated with the lack of types in Python and JavaScript, hence we get Python with typing and TypeScript.

Regarding typing, what I have tried to achieve is the best of both worlds. In unify-jdocs, we have the concept of typed document. This is a document that defines the structure of the JSON document. It defines what the "type" of a leaf node is i.e. integer, string etc. The validation / determination against this type is however done at runtime. This, I feel is acceptable because whenever we add a JSON path to a document, the first thing we would do is to test the read / write of that path. And any type mismatch would get caught there immediately. And so, from the point of view of being able to read / write / validate in a single line of code (even though dynamically) provides much simplicity and ease of use as compared to using POJOs. Plus we always know the exact JSON path we are dealing with.

Usually, I would prefer static typing but, in a scenario, where we can have hundreds of JSON document types (we deal with more than 500 in the same application), complex JSON document (ours go down more than ten levels deep with hundreds of JSON paths) and where the document structures may undergo change over project lifetime, the use of read / writing using a single line of code has many benefits. I shudder to think of hundreds (if not thousands) of POJO classes, the writing of accessor methods (null / empty handling, namespace etc.) and what it would take to refactor in the face of change. Just my opinion based on my experience in the past.

> I think you will find less traction with this method of posting to HN. People want a clickable link to look at the project

The clickable link to the repo / documentation is actually in the text (https://github.com/americanexpress/unify-jdocs). In the case of this post, I felt it more important for people to read the text rather than be directly pointed to the contents of the link and hence this approach.

We announced the first release of unify-jdocs in August 2020. Since then, it has undergone 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 improve maintainability and agility significantly. Unify-jdocs has been invoked billons of times in production and has demonstrated great reliability. The original post can be found here: https://news.ycombinator.com/item?id=24332382.

Reason for posting again – last time while submitting on Show HN, I listed the URL in the URL field and so this text of mine was not visible! And so, I try to continue to promote unify-jdocs.

This is a one-of-a-kind library in my opinion. Two features stand out – read / write any JSON path in a single line of code – and define a document structure and validate a JSON document against it – along with a host of other features. It makes life so much simpler for any Java project that deals with JSON documents.

For projects that deal with more than a few simple JSON documents, need to do transformations and change structure during project lifetime, unify-jdocs absolutely shines. It provides a much simpler way of validating documents as compared to JSON schema.

One counter argument which I have heard come up again and again against using unify-jdocs is around static / dynamic type safety. When we use POJOs, the read / write operations on the document are statically compiled into the app 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 outweigh the benefits of static typing using POJO / model classes. Looking forward to discussing more. Thanks.

Comments URL: https://news.ycombinator.com/item?id=38446358

Points: 2

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=38309664

Points: 1

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=38252581

Points: 2

# Comments: 0

I made something similar in Java - unify-jdocs - https://github.com/americanexpress/unify-jdocs - though this is not for parsing - it is more for reading and writing when the structure of the document is known - read and write any JSONPath in one line of code and use model documents to define the structure of the data document (instead of using JSONSchema which I found very unwieldy to use) - no POJOs or model classes - along with many other features. Posting here as the topic is relevant and it may help people in the Java world. We have used it intensively within Amex for a very large complex project and it has worked great for us.