Call for Dicussion: JEP: Java Expression Trees API

Tue Apr 23 21:47:12 UTC 2024

Thank you all for your comments. Indeed, similar goals expressed
differently. Unfortunately, I wasn't aware of the Babylon project and could
not comment before.

I did a review of the Code Model and do have a few concerns regarding
usability of MLIR-like approach for libraries such as FluentJPA and
FluentMongo and full freedom of what can be inside the lambda. Let me
explain.

   1. My journey was "FluentJPA first" and not the code model first.
   2. This project goal is an ability to fully express SQL in Java, so I
   first prototyped the "end game", i.e. some SQL statements written in Java.
   3. Then I built the desired "Code Model" classes and interfaces.
   Actually, I was quite confident that I would not be too challenged by byte
   code transformation into the Code Model since I had some experience in the
   field.
   4. My primary concern was the ability to generate SQL from the Model.
   5. Why? There are several C# Database LINQ providers. All of them solve
   a much, much simpler problem - the ability to transform just a single
   expression to SQL. Multi lines, variables, functions are not allowed.
   6. I wanted all these goodies available bacause otherwise I would not be
   able to say "SQL written in Java".
   7. So I carefully added more capabilities to what can be inside "SQL
   lambda" (compared to what C# compile time Expression Tree parser can have
   inside the lambda).
   8. On the other hand, there are many Java capabilities that are not
   translatable to SQL at all and should not be allowed in this context.
   9. These additions added huge complexity to the SQL transformer, so I'm
   quite confident that if Babylon aims to be a foundation to transpile JBC
   into something like SQL, there must be a mechanism to enforce some
   restrictions on what can be inside the Lambda.
   10. You may reasonably say that the FluentJPA library developer should
   filter out inappropriate Ops.
   11. Well, here is the first problem - it would mean there is no way for
   the tooling to perform any runtime validation and ensure that no
   "unsupported" constructs exist inside the method.
   12. Next problem is branching. Consider the following expression
   (borrowed from the Babylon test suite - nestedConditionalExpr method): (i <
   2) ? (j < 3) ? i : j : i + j
   1. Basically it's a completely valid SQL/Mongo construct that should be
      mapped to e.g. CASE statement in SQL.
      2. Babylon Code Model generates 6 blocks with complex branching
      between them. Do you think it would be easy to transpile it to CASE?
      3. With expression tree it maps quite well.
      4. I deliberately don't support BranchExpression (GotoExpression in
      C#) due to associated complexity. The decompiler performs some work to
      convert branching into binary tree with conditions. If it fails, a method
      is considered not compatible with SQL/Mongo.
   13. The next problem is MLIR-like approach. Clearly, it's convenient to
   the JDK developers and allows straight forward mapping to/from JBC. Is it
   useful for transpiling, i.e. producing high level language code? I'm not
   sure. And vice versa, if I need to produce a machine level code - I feel at
   home.
   14. The final problem is logical transformation/normalization. Consider
   2 BigDecimals that we compare using compareTo method. Clearly, we would
   want them to be compared using an appropriate operator, but JBC does not
   allow that. When transpiling to SQL I normalize this sort of
   constructs ahead of the main transpiler. On a larger scale, consider an
   ecosystem language that might have more numeric types, support operators,
   etc. All this is usually compiled to the corresponding runtime library
   methods. Ideally it should be possible to normalize it to a condition. I'm
   not an expert in Code Model, but my impression is that it's not possible to
   express something that does not really exist in JBC.

Overall, I don't feel that Code Model provides any significant upgrade on
top of Class-File API beyond the standard way to get the "quoted" object. I
will have to transform the Code Model to expressions first to address the
issues raised above.
Don't misunderstand me, the Code Model introduced in Babylon is great and a
huge step forward. I can find a lot of use cases where it would be
especially useful. My point is that it's not THE perfect fit for projects
like FluentJPA/FluentMongo and basically any transpiler to a simple
high-level language.

If you find it useful, I'll be more than happy to have a conversation, show
and explain different use cases, provide pros/cons, etc.

Thanks,
Kosta

On Mon, Apr 22, 2024 at 9:25 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> Yes, very similar goals expressed differently e.g., the modeling of Java
> code (Babylon's code model is more MLIR-like rather than C# expression
> tree-like). Please see the articles linked to from the Babylon project
> page. One of the goals is to enable developers to write libraries such as
> FluentJPA and FluentMongo. If you are willing to experiment it would be
> very interesting to see if Babylon’s code reflection can easily support
> those libraries you have written.
>
> Paul.
>
> > On Apr 21, 2024, at 7:11 PM, liangchenblue at gmail.com wrote:
> >
> > Hi Konstantin,
> > What you propose has a large overlap with Project Babylon (
> https://openjdk.org/projects/babylon/), which accomplishes "code
> reflection" from the Java compiler. The project itself also ships a code
> model that's suitable for representing ASTs from different programming
> languages, including ones from Java bytecode. Then your proposal would be
> much simpler - to generate an expression tree from class files.
> >
> > Since the discuss list isn't really for development questions, I am
> replying to babylon-dev mailing list instead and we will sail from there.
> >
> > Regards
> >
>

-- 
Regards,
Konstantin Triger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20240424/a75390aa/attachment.htm>