<div dir="ltr"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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.</div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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.</div><div><ol><li>My journey was "FluentJPA first" and not the code model first. </li><li>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.</li><li>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.</li><li>My primary concern was the ability to generate SQL from the Model.</li><li>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.</li><li>I wanted all these goodies available bacause otherwise I would not be able to say "SQL written in Java".</li><li>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).</li><li>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.</li><li>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.</li><li>You may reasonably say that the FluentJPA library developer should filter out inappropriate Ops.</li><li>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.</li><li>Next problem is branching. Consider the following expression (borrowed from the Babylon test suite - nestedConditionalExpr method): (i < 2) ? (j < 3) ? i : j : i + j<br></li><ol><li>Basically it's a completely valid SQL/Mongo construct that should be mapped to e.g. CASE statement in SQL.</li><li>Babylon Code Model generates 6 blocks with complex branching between them. Do you think it would be easy to transpile it to CASE?</li><li>With expression tree it maps quite well.</li><li>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.</li></ol><li>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.</li><li>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.</li></ol><div>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.</div></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Kosta</div><div><br></div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 22, 2024 at 9:25 PM Paul Sandoz <<a href="mailto:paul.sandoz@oracle.com">paul.sandoz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
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.<br>
<br>
Paul.<br>
<br>
> On Apr 21, 2024, at 7:11 PM, <a href="mailto:liangchenblue@gmail.com" target="_blank">liangchenblue@gmail.com</a> wrote:<br>
> <br>
> Hi Konstantin,<br>
> What you propose has a large overlap with Project Babylon (<a href="https://openjdk.org/projects/babylon/" rel="noreferrer" target="_blank">https://openjdk.org/projects/babylon/</a>), 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.<br>
> <br>
> 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.<br>
> <br>
> Regards<br>
> <br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Regards,<br>Konstantin Triger<br></div></div>