Is Quaere truly LINQ for Java?
The LINQ for Java question hit another milestone last week with the arrival of Quaere, although it remains to be seen whether this milestone is significant or not. We've certainly registered some false starts in this space which rightly have been seen as more marketechture than a true innovations on the Java platform.
Lets review some of the feature highlights...
Compared to JLINQ discussed here, this seems like we have alot more meat similar to what is currently being offered in LINQ on the .NET Framework. Certainly the readers of dzone.com seem to feel it has merit, but no one seems to have asked the question: is LINQ on the Java platform actually a necessary innovation? Are there legions of Java programmers who are struggling with data access patterns that don't serve their needs ?
've talked about LINQ on number of posts; for the .NET community LINQ represents a quantum leap that changing the way developers search, sort and generally perform data access. Sure LINQ is not perfect, but it brings to bear many of the things Java developers have enjoyed for many years. One has only to examine the plethora of JDBC driver implementations and gauge the respect the JDBC specifications as the solid foundation for the success of Hibernate, the Spring Framework and many more. With the advent of JPA, I see the problem LINQ seeks to solve is even less acute in Java.
Don't get me wrong, while the effort underway with Quaere is admirable it could just all be an academic exercise. I am of course open to debate on that score...
Lets review some of the feature highlights...
- Ability to perform queries against arrays or data structure implementing the Iterable interface.
- An internal DSL (based on static imports and fluent interfaces) that lets you integrate the query language with
- regular Java code. No preprocessing or code generation steps are required to use the DSL, simply add a reference to the quaere.jar file (and its dependencies).
- A large number of querying operators including restriction, selection, projection, set, partitioning, grouping, ordering, quantification, aggregation and conversion operators.
- Support for lambda expression
- The ability to dynamically define and instantiate anonymous classes.
- Many new “keywords” for Java 1.5 and later.
Compared to JLINQ discussed here, this seems like we have alot more meat similar to what is currently being offered in LINQ on the .NET Framework. Certainly the readers of dzone.com seem to feel it has merit, but no one seems to have asked the question: is LINQ on the Java platform actually a necessary innovation? Are there legions of Java programmers who are struggling with data access patterns that don't serve their needs ?
've talked about LINQ on number of posts; for the .NET community LINQ represents a quantum leap that changing the way developers search, sort and generally perform data access. Sure LINQ is not perfect, but it brings to bear many of the things Java developers have enjoyed for many years. One has only to examine the plethora of JDBC driver implementations and gauge the respect the JDBC specifications as the solid foundation for the success of Hibernate, the Spring Framework and many more. With the advent of JPA, I see the problem LINQ seeks to solve is even less acute in Java.
Don't get me wrong, while the effort underway with Quaere is admirable it could just all be an academic exercise. I am of course open to debate on that score...
posted by Jonathan Bruce at
22:17
2 Comments:
Uhmm... I don't think you understand LINQ even for a .NET developer. ADO.NET is as rich as JDBC, and there are numerous ORM packages available, including several libraries ported from Java, such as NHibernate. So the fact that "LINQ to SQL" and "LINQ to Entities" (I think that's what the other library is currently called) are ORM libraries is really not the interesting bit about LINQ.
No, what's interesting is that the "query" has been brought into the language proper. The biggest part of this is that the queries are now "native" and can be type checked, compiled, etc. While some ORMs allow this, most still use a string based query language.
The second point about the "query" being native that you've totally missed in your analysis is that means the query is independent of the data. MySQL? Sure. Oracle? Sure. XML? Now we're getting more interesting... and sure. Arrays or other in memory data? Even more interesting... and still, sure. Some web service? Sure... there's lots of really interesting providers being developed in this space. Every single one of these uses the same query language, and more interestingly it's possible to query/join across data from various data providers (obviously there's caveats about what specific providers provide, and performance considerations when doing cross provider joins, but it DOES work). This is space in which LINQ is innovative, and not "just another ORM".
I've not used Quaere, but it appears they understood this, and have modeled LINQ fairly well in the Java space. You're missing some of the "sugar" that C# and VB provide, which makes the query language more palatable within the language, instead of just being a chain of function calls, but it's still a very good start. At least they seem to understand what LINQ is... which is NOT an ORM, like JLinq thought, or only applicable to databases, as you seemed to have thought.
By
wekempf, At
September 27, 2007 at 11:00 AM
I'm not quite sure I follow how the maturity of low level access tools like JDBC competes with the higher level of abstraction that DSL's like LINQ enable. If anything, it seems that this only makes LINQ more compelling on the java platform.
I was not familiar with LINQ on the .NET platform before Quaere got me interested. However, I immediately see tons of uses in my applications. Places where I use XPath or manual double indexed maps or tons of one off solutions. This really seems like a great common way to express selection, filtering, ordering and transformation, no matter the data source.
Color me convinced, this would be a nice addition to the java toolchain, as additive, not as a substitute for current technologies.
By
amalter, At
September 27, 2007 at 1:57 PM
Post a Comment
Subscribe to Post Comments [Atom]
<< Home