"The Java model layer is a Java-centric, type safe, object-oriented persistence layer for Java applications"
That's exactly the kind of thing Codd was arguing against 50 years ago.
Information does not fit in Java objects. It doesn't want to be stuck (and does not work well) in hierarchical property & inheritance relationships. That's not how knowledge works.
Information (and the human mind) does tend towards working better when formulated in terms of first order / predicate logic. Which is what the relational data model is based upon. SQL is a rather crude approximation of that.
True, but we're talking about persisting Java objects, not relational data or an approximation of human knowledge or whatever. This is a narrower problem space, and one solution is treating the storage layer as a KV store, ignoring the problem of translating queries to SQL or mapping classes to DDL. This library is deliberately throwing away the relational model and its power, and the README acknowledges such.
The answer is to stop persisting Java objects, and start writing applications with relations (facts / propositions) in mind.
The OO stuff I think has gotten in the way of our jobs. When I worked in Java it was a mountain of pointless data/transfer object transformations. Microservices has made this worse. It's a really bad paradigm.
https://github.com/permazen/permazen/wiki/FAQ#architecture
It provides a Java view of the data, and handles translating operations in that later into operations on the underlying stores.