Where database blog posts get flame-broiled to perfection
Alright, let's take a look at this... groundbreaking piece of literature. The answer is in the title, it says. "Use Document." Oh, absolutely. If the question is "How do I speed-run my way to a career-ending data breach and a nine-figure regulatory fine?" then yes, by all means, "use Document."
You've written a whole dissertation on five ways to deserialize untrusted data, and your grand conclusion is to pick the one that's a glorified Map<String, Object>. Let me say that again, slowly. Map. String. Object. Are you trying to write a database driver or a "Build Your Own Remote Code Execution" kit? This isn't a "flexible representation"; it's a gaping, boundless security hole with a convenient Map interface. Storing values as a generic Object is the developer equivalent of leaving your front door wide open with a neon sign that says "Free Gadget Chains Inside." Every deserialization library vulnerability from the last decade just lit up like a Christmas tree. I can already hear the Log4j maintainers shuddering.
You call it "loosely-typed". I call it "un-sanitized, un-validated, and un-employable." You're practically begging for a deserialization attack. An attacker crafts a malicious BSON payload, your "flexible" driver happily unpacks it into a set of Java objects, and boom, you're running arbitrary code on your server. But hey, at least it was easy to work with before your entire cloud infrastructure was commandeered for a crypto mining operation.
And the other options! It's a spectacular buffet of bad choices.
BsonDocument? Oh, "type-safe," you say. It's a fig leaf. You're just forcing developers to wrap their untrusted garbage in another layer of objects before it hits the fan. It’s like putting a child-proof cap on a bottle of nitroglycerin. The "verbose code" is just more opportunity for someone to make a mistake and accidentally revert to a less safe type.
RawBsonDocument is my personal favorite. You call it "lazy parsing." I call it a ticking time bomb. You've got an un-validated, un-parsed blob of bytes sitting in memory, and you're telling me that's efficient? Efficient at what, bypassing static analysis? So the payload sits there, dormant, until some poor, unsuspecting method tries to access one field. Then, your "efficient" sequential scan kicks in. What happens when that byte array is malformed? A clever attacker could craft a payload that sends your BsonBinaryReader into an infinite loop, causing a Denial of Service. Or better yet, trigger a buffer overflow in the native code that I'm sure is perfectly written and has no vulnerabilities whatsoever. "Immutable," you say. Right. Because UnsupportedOperationException has never been caught and ignored in the history of programming.
JsonObject. This one is just sad. You're so proud that it "avoids conversion to Map structure." Congratulations, you've invented a string. It's a String with a fancy hat. You're just deferring the inevitable, massively insecure parsing operation to some other poor soul down the line, probably a library with five new CVEs discovered last week. You haven't solved a security problem; you've just passed the buck.
And then there's BasicDBObject, the "legacy class." You call it legacy; I call it a registered biohazard. The advice to "only use for migration" should be replaced with "douse in kerosene and light on fire for compliance purposes."
The fact that you boast about how you can "convert between types" is the cherry on top of this disaster sundae. Every one of those conversion points—BsonDocument.parse(), RawBsonDocument.decode()—is an attack surface. A parser is just a formal invitation for an attacker to get creative.
Neither Oracle nor PostgreSQL provides BSON as they use OSON and JSONB... PostgreSQL’s JDBC driver... values are always returned as text.
You present this as a weakness! Returning data as text and forcing the application to explicitly parse it is a feature, you madman! It creates a clear boundary where validation and sanitization must occur. You're bragging that you've eliminated that boundary for the sake of "convenience."
This entire philosophy of working "directly through your domain objects, without an intermediate object-relational mapping layer" is a compliance nightmare. An ORM, for all its flaws, provides a crucial abstraction layer that helps prevent injection attacks. You're advocating for stripping that away and just YOLO-ing raw objects into your database.
Try explaining Map<String, Object> to a SOC 2 auditor. Go ahead, I'll wait. "So, Mr. Williams, can you tell us about your data validation and integrity controls?" "Well, you see, it's an Object. It can be anything. It's... flexible." You won't just fail your audit; you'll be laughed out of the building and possibly placed on a watchlist.
So go ahead. Use Document. Build your "modern applications" on a foundation of "flexibility" and "ease of use." I'll be waiting for the inevitable post-mortem on The Register. Don't call me when your customer PII is for sale on the dark web for pocket change. Actually, do call me. I charge a premium for "I told you so" forensics.