{"id":15200,"date":"2013-07-05T13:00:49","date_gmt":"2013-07-05T10:00:49","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=15200"},"modified":"2013-07-05T08:58:34","modified_gmt":"2013-07-05T05:58:34","slug":"linq-and-java","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2013\/07\/linq-and-java.html","title":{"rendered":"LINQ and Java"},"content":{"rendered":"

LINQ<\/a> has been quite a successful, but also controversial addition to the .NET<\/a> ecosystem. Many people are looking for a comparable solution in the Java world. To better understand what a comparable solution could be, let\u2019s have a look at the main problem that LINQ solves:<\/p>\n

Query languages are often declarative programming<\/a> languages with many keywords. They offer few control-flow elements, yet they are highly descriptive. The most popular query language is SQL<\/a>, the ISO\/IEC standardised Structured Query Language, mostly used for relational databases.<\/p>\n

Declarative programming means that programmers do not explicitly phrase out their algorithms. Instead, they describe the result they would like to obtain, leaving algorithmic calculus to their implementing systems. Some databases have become very good at interpreting large SQL statements, applying SQL language transformation rules based on language syntax and metadata. An interesting read is\u00a0Tom Kyte\u2019s metadata matters<\/a>, hinting at the incredible effort that has been put into Oracle\u2019s Cost-Based Optimiser. Similar papers can be found for SQL Server, DB2 and other leading RDBMS.<\/p>\n

LINQ-to-SQL is not SQL<\/h2>\n

LINQ is an entirely different query language that allows to embed declarative programming aspects into .NET languages, such as C#, or ASP. The nice part of LINQ is the fact that a C# compiler can compile something that looks like SQL in the middle of C# statements. In a way, LINQ is to .NET what SQL is to PL\/SQL, pgplsql or what jOOQ<\/a> is to Java (see my previous article about PL\/Java<\/a>). But unlike PL\/SQL, which embeds the actual SQL language,\u00a0LINQ-to-SQL<\/a>\u00a0does not aim for modelling SQL itself within .NET. It is a higher-level abstraction that keeps an open door for attempting to unify querying against various heterogeneous data stores in a single language. This unification will create a similar impedance mismatch as ORM<\/a> did before, maybe an even bigger one. While similar languages can be transformed into each other to a certain extent, it can become quite difficult for an advanced SQL developer to predict what actual SQL code will be generated from even very simple LINQ statements.

<\/div> <\/div><\/p>\n

LINQ Examples<\/h2>\n

This gets more clear when looking at some examples given by the LINQ-to-SQL documentation. For example the Count()<\/a><\/code>\u00a0aggregate function:<\/p>\n

System.Int32 notDiscontinuedCount =\r\n    (from prod in db.Products\r\n    where !prod.Discontinued\r\n    select prod)\r\n    .Count();\r\n\r\nConsole.WriteLine(notDiscontinuedCount);<\/pre>\n
In the above example, it is not immediately clear if the .Count()<\/code> function is transformed into a SQL count(*)<\/code> aggregate function within the parenthesised query (then why not put it into the projection?), or if it will be applied only after executing the query, in the application memory. The latter would be prohibitive, if a large number or records would need to be transferred from the database to memory.\u00a0Depending on the transaction model, they would even need to be read-locked!<\/p>\n
Another example is given here where grouping is explained<\/a>:<\/p>\n
var prodCountQuery =\r\n    from prod in db.Products\r\n    group prod by prod.CategoryID into grouping\r\n    where grouping.Count() >= 10\r\n    select new\r\n    {\r\n        grouping.Key,\r\n        ProductCount = grouping.Count()\r\n    };<\/pre>\n
In this case, LINQ models its language aspects entirely different from SQL. The above LINQ where<\/code> clause is obviously a SQL HAVING<\/code> clause. into grouping<\/code> is an alias for what will be a grouped tuple, which is quite a nice idea. This does not directly map to SQL, though, and must be used by LINQ internally, to produce typed output. What\u2019s awesome, of course, are the statically typed projections that can be reused afterwards, directly in C#!<\/p>\n
Let\u2019s look at another grouping example:<\/p>\n
var priceQuery =\r\n    from prod in db.Products\r\n    group prod by prod.CategoryID into grouping\r\n    select new\r\n    {\r\n        grouping.Key,\r\n        TotalPrice = grouping.Sum(p => p.UnitPrice)\r\n    };<\/pre>\n
In this example, C#\u2019s functional aspects are embedded into LINQ\u2019s Sum(p => p.UnitPrice)<\/code> aggregate expression. TotalPrice = ...<\/code> is just simple column aliasing. The above leaves me with lots of open questions. How can I control, which parts are really going to be translated to SQL, and which parts will execute in my application, after a SQL query returns a partial result set? How can I predict whether a lambda expression is suitable for a LINQ aggregate function, and when it will cause a huge amount of data to be loaded into memory for in-memory aggregation? And also: Will the compiler warn me that it couldn\u2019t figure out how to generate a C#\/SQL algorithm mix? Or will this simply fail at runtime?<\/p>\n
To LINQ or not to LINQ<\/h2>\n
Don\u2019t get me wrong. Whenever I look inside the LINQ manuals for some inspiration, I have a deep urge to try it in a project. It looks awesome, and well-designed. There are also lots of interesting LINQ questions on Stack Overflow<\/a>. I wouldn\u2019t mind having LINQ in Java<\/a>, but I want to remind readers that LINQ is NOT<\/em> SQL. If you want to stay in control of your SQL, LINQ or LINQesque APIs may be a bad choice for two reasons:<\/p>\n
    \n
  1. Some SQL mechanisms cannot be expressed in LINQ. Just as with JPA, you may need to resort to plain SQL.<\/li>\n
  2. Some LINQ mechanisms cannot be expressed in SQL. Just as with JPA, you may suffer from severe performance issues, and will thus resort again to plain SQL.<\/li>\n<\/ol>\n
    Beware of the above when choosing LINQ, or a \u201cJava implementation\u201d thereof! You may be better off, using SQL (i.e. JDBC, jOOQ<\/a>, or MyBatis<\/a>) for data fetching and Java APIs (e.g. Java 8\u2032s Stream API)<\/a> for in-memory post-processing<\/p>\n
    LINQ-like libraries modelling SQL in Java, Scala<\/h2>\n