Difficulties of integrating LINQ-like apl APIs in Java.

[Olexandr Rotan]

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.

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.

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:

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 :) ).

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.

This and much more issues lead to a fact that LINQ in java would have to be
*EXTREAMLY* configurable, and this dramatically complicates implementation.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20240705/5e590d32/attachment.htm>