LINQ in Java

You are a Java developer that also does some .NET or hangout with some .NET folks and happen to have heard them talking about language integrated query, LINQ. Every so often you wonder what the Java equivalent for LINQ is.

LINQ is a component of the .NET Framework that adds data querying natively to .NET languages. Java 6 does have a solution for type-safe database queries using the javax.persistence.criteria package, but there is nothing exactly the same as LINQ in Java. There are equivalents but nothing similar that is part of the standard Java libraries. Of course Lambdas are coming to Java 8 scheduled for 2012 in the form of JSR-335 - Lambda Expressions for the JavaTM Programming Language, but at the moment Java has nothing like LINQ.

JSR-335 will extend the Java Programming Language Specification and the Java Virtual Machine Specification to support the following features:

- Lambda Expressions
- SAM Conversion
- Method References
- Virtual Extension Methods

This JSR may also consider other related language features in support of adding lambda expressions to the Java language.

Supporting changes may be needed in various reflective APIs, including but not limited to java.lang.reflect and javax.lang.model.

Time permitting, this JSR will also explore selected updates to the Java SE core libraries to support a more lambda-friendly style of programming.

For more information see the discussion on Stack Overflow  titled What is the Java equivalent for LINQ?

Java Equivalents

• jOOQ: http://www.jooq.org
• QueryDSL: http://source.mysema.com/display/querydsl/Querydsl
• JaQu: http://www.h2database.com/html/jaqu.html
• Quaere: http://quaere.codehaus.org/ , Quaere is an open source, extensible framework that adds a querying syntax reminiscent of SQL to Java applications. Quaere allows you to filter, enumerate and create projections over a number of collections and other queryable resources using a common, expressive syntax.
• Flu: Flu on Google Code : How to write SQL in Java in a type safe manner.
• Empire-db: Apache Empire-db is an Open Source relational data persistence component which allows database vendor independent dynamic query definition as well as safe and simple data retrieval and updating. Compared to most other solutions like e.g. Hibernate, TopLink, iBATIS or JPA implementations, Empire-db takes a considerably different approach, with a special focus on compile-time safety, reduced redundancies and improved developer productivity.
• JaQu: JaQu stands for Java Query and allows to access databases using pure Java. JaQu provides a fluent interface (or internal DSL) for building SQL statements. JaQu replaces SQL, JDBC, and object/relation frameworks such as Hibernate. JaQu is something like LINQ for Java (LINQ stands for "language integrated query" and is a Microsoft .NET technology).
• JEQUEL: JEQUEL is a Domain Specific Language for the Structured Query Language (SQL) embedded in Java.
• JoSQL: JoSQL (SQL for Java Objects) provides the ability for a developer to apply a SQL statement to a collection of Java Objects. JoSQL provides the ability to search, order and group ANY Java objects and should be applied when you want to perform SQL-like queries on a collection of Java Objects.
• Liquidform: LIQUidFORM stands for Language Integrated QUeries For Object Relational Mapping and is a Java library that provides a Java Domain Specific Language for building type-safe and refactoring proof JPA queries.
• Squill: Squill is a slick internal DSL for writing SQL queries in pure Java. It uses the database metadata and generics to catch as many errors as possible during compilation and is almost completely typesafe.

There are many LINQ equivalents or aspirations for Java, see here for a comparison.

 

Quotes from the Industry

There is a question some developers are asking: Has LINQ given Microsoft’s latest .NET Framework an edge over Java? Industry experts say “yes,” but with some caveats.
Microsoft shipped Language Integrated Query as part of the .NET Framework 3.5 in November. LINQ was originally one of many research projects that the company has under way. LINQ integrates query concepts directly into .NET programming languages using a syntax that is similar to SQL, to simplify the querying of data, objects and XML.
Patrick Hynds, president of security consultancy CriticalSites, said that LINQ is “an object-oriented revolution for data,” because it, like object-oriented programming, allows programmers to write code that is more like the way people think.  from SD Times

---

Interesting story today asking whether LINQ has given .NET an edge over Java. LINQ is best-known as a way to embed SQL-like statements directly in code. However, it’s really a much deeper technology that allows you effectively build DSL-like constructs in libraries that work as if they are part of the language. And that is undeniably powerful.

From what I’ve seen, the C# code using LINQ also seems to be relatively readable (due to the DSL-like nature of it) and that is a big win from both the power and complexity standpoints. from Pure Danger Tech

---

This is a very critical point: LINQ encourages developers to think about data in a more declarative way -- by defining the characteristics of data that will match a query, and the shape of transformed data -- rather than as an imperative sequence of navigation and data manipulation operations. This has great potential for making code easier to write, understand, and maintain while allowing a relatively painless transition from the current generation of programming languages and the style that they encourage.

Voss makes another point far better than I can:

The common wisdom preached by the Ruby advocates and exemplified by its neatest accomplishments, such as ActiveRecord, is that such can only be accomplished by the dynamic, loosely typed scripting languages. However, the LINQ feature in C# 3.0 will turn this thinking completely on its head. It will bring in to question whether we really have to throw strong typing away in order to do these neat new things. LINQ creates tuples or anonymous types but it is able to retain type checking. The new feature of implicitly typed local variable declarations make it possible to hold a reference to these tuples in order to access and manipulate them. Unlike EJB3 query language, a LINQ query expression is type checked by the compiler. The end result is the simplicity style of the dynamic scripting languages but with the full rigor of a traditional strongly typed language.

Or as Erik Meijer likes to say "static typing when possible, dynamic typing when necessary." It's not conflict between two rival programming styles any more than there is a conflict between the screwdrivers and hammers in your toolbox -- use the best fastener (and the appropriate tool) for the job at hand; when either will work, fall back to the easiest / cheapest / most familiar / whatever, don't agonize or preach about it.

Jonathan Bruce generally agrees with Voss, but makes an important clarification and recommendation:

I do disagree with his assertion that "There will still just be XPath for XML, and nothing at all for in-memory object graphs. Tuples?". He should consider XQuery and what this means as signicifant bridge to providing the mechanics of LINQ for the Java platform.

Feature for feature, XQuery (seen as a programming language rather than an XML query language) and LINQ/XLinq are probably more similar than they are different.  Both have learned from traditional programming languages, functional programming, and XML technologies such as DOM and XSLT. They do take a rather different approach to the question of data integration, however:  XQuery provides an uber-data model to which XML, relations, and object graphs can be converted, and LINQ provides a minimalist abstraction that underlies each of them natively.  We will just have to see which approach resonates best with the .NET and Java users. by Mike Champion

LINQ Java Search on Google

Java EE Application Directory Structure

I had a discussion with a colleague about what would be the best directory structure for a Java EE application. So what is the best structure?

While using Eclipse in the Java EE perspective you can create an Enterprise Application Project that contains a client module, an ejb module, a web module and a connector module. You can add additional projects that will be modules specific to some logical distinction in your application. So you might have a module for  calculations and another for accessing external services etc.

Both Logical and Organizational considerations come into play. Each EAR would contain all the pieces that are related for a particular capability. We can always assume that each EAR will be self contained and can be deployed on one or more containers. The typical approach that I have always followed is to have each EAR contain one or more jars and wars. Each war or jar contains some key component or set of related components. The EAR represents an Enterprise application that contains the components and web apps for the application. An Example is a Payment processing system I was involved in. The EAR contained everything required to run the Payment Processing system. This included half a dozen jars and 3 wars. Each jar represented some functionality or logical grouping of functionality. Each war represented a web app. An example of the jar's composition:

• a jar for core functionality
• a jar for ejbs
• a jar for our advanced financial math pieces
• a jar for our security pieces
• etc.

Having multiple jars was dictated by the fact that different people developed different pieces so they worked in different Eclipse projects and combined them all as needed.

There are no hard and fast rules, just whatever works for your team and situation.

The official position from Oracle-Sun is

A Java EE application is delivered in an Enterprise Archive (EAR) file, a standard Java Archive (JAR) file with an .ear extension. Using EAR files and modules makes it possible to assemble a number of different Java EE applications using some of the same components. No extra coding is needed; it is only a matter of assembling (or packaging) various Java EE modules into Java EE EAR files.

An EAR file contains Java EE modules and deployment descriptors. A deployment descriptor is an XML document with an .xml extension that describes the deployment settings of an application, a module, or a component. Because deployment descriptor information is declarative, it can be changed without the need to modify the source code. At runtime, the Java EE server reads the deployment descriptor and acts upon the application, module, or component accordingly.

EAR File Structure

There are two types of deployment descriptors: Java EE and runtime. A Java EE deployment descriptor is defined by a Java EE specification and can be used to configure deployment settings on any Java EE-compliant implementation. A runtime deployment descriptor is used to configure Java EE implementation-specific parameters. For example, the Sun Java System Application Server runtime deployment descriptor contains information such as the context root of a web application, the mapping of portable names of an application’s resources to the server’s resources, and Application Server implementation-specific parameters, such as caching directives. The Application Server runtime deployment descriptors are namedsun-moduleType.xml and are located in the same META-INF directory as the Java EE deployment descriptor.

A Java EE module consists of one or more Java EE components for the same container type and one component deployment descriptor of that type. An enterprise bean module deployment descriptor, for example, declares transaction attributes and security authorizations for an enterprise bean. A Java EE module without an application deployment descriptor can be deployed as a stand-alone module.

The four types of Java EE modules are as follows:

• EJB modules, which contain class files for enterprise beans and an EJB deployment descriptor. EJB modules are packaged as JAR files with a .jar extension.

• Web modules, which contain servlet class files, JSP files, supporting class files, GIF and HTML files, and a web application deployment descriptor. Web modules are packaged as JAR files with a .war (Web ARchive) extension.

• Application client modules, which contain class files and an application client deployment descriptor. Application client modules are packaged as JAR files with a .jar extension.

• Resource adapter modules, which contain all Java interfaces, classes, native libraries, and other documentation, along with the resource adapter deployment descriptor. Together, these implement the Connector architecture (see J2EE Connector Architecture) for a particular EIS. Resource adapter modules are packaged as JAR files with an .rar (resource adapter archive) extension.