<div dir="auto">A few months ago I wrote a letter to this mailing list asking how can I be helpful to this project. I have been quite busy since then, but now I have finally spared some time to work on LINQ-like apy in Java.<div dir="auto"><br></div><div dir="auto">I am currently at architecture drafting stage, and already see quite a bunch of of problems that are present on a way of implementing such API, and I would like to share them with you so you are also aware of these obstacles.</div><div dir="auto"><br></div><div dir="auto">Most of the problems originate from the backward compatibility of existing code with existing Jakarta EE-based code (which also includes spring framework). The most significant ones include:</div><div dir="auto"><br></div><div dir="auto">1) Name resolution strategy: @jakarta.persostence.Column annotation allows to define custom column names. It's relative @JoinColumn also allows the same thing. There are also @Table and @JoinTable annotations that allow defining custom column names, and even allow changing the way many to one relationships are represented in database. Even thinner jdbc wrappers like Spring Data JDBC allow custom naming strategies. So there is where the problem originates: how do we know, where and what to look for in the database. We for sure don't want to make users change their db structure just so they can use this feature. What I am currently came up with is defining PropertyPathResolver interface that can have multiple implementations for JPA, plain JDBC or custom persistence providers. However, it is still unclear on where to configure this name resolver. It is possible to define some DBSessionFactory, that is configured to path a resolver to each created session, but this imposes another problems related to dependency management because using this factory won't be pleasant at all outside of DI containers. The other thing is should we put weight of implementing those strategies on providers? If so, we risk missing some very important, deeply rooted hidden ideas or concepts that are not clear until you try to implement strategy for certain type of provider (like JPA provider or other JDBC wrappers) ourself. This could potentially lead to endless previewing and rewriting things from scratch a few times (ressembles valhalla a bit :) ).</div><div dir="auto"><br></div><div dir="auto">2) Bean validation, AOP proxying, entity management of persistence providers etc. Introducing a new fresh alternative to JDBC could create a mechanism to bypass fine-tuned for decades frameworks data fetching pipelines. Modern frameworks rely on proxying in virtually every aspect. While it is possible, to, for example, still perform Bean validation assuming that framework will provide proxy of query builder that will perform validation of query result or proxying, what should we do, for example, with lazy loading? Framework can't "break into" query building flow and say "hey, I will manage those additional queries myself". You could allow configuring fetch type in query, but historically it has been done through annotations in entity class, and, once again, it's leads to creating another interface like "JoinFetchConfigurer" that will define relationships fetching strategy and implementation will be left on persistence providers, or at least I don't see the other way without looking up jakarta.persistence annotations ourself. </div><div dir="auto"><br></div><div dir="auto">This and much more issues lead to a fact that LINQ in java would have to be *EXTREAMLY* configurable, and this dramatically complicates implementation.</div><div dir="auto"><br></div><div dir="auto">And 3), which is more like a nice-to-have goal: it would be just great to make query object to implement Stream API, so they can be used interchangeably, and create custom collection implementations that lazily fetch data and custom iterators for this purpose. But I think you, as much as I am, understand how much more complex implementation becomes with this, especially having what I have said earlier.</div><div dir="auto"><br></div><div dir="auto">This is the issues I have encountered just at draft layer. I will make sure to keep you updated with development process when I will have more to say.</div><div dir="auto"><br></div></div>