JCR, LINQ, apples and oranges
At one time I thought the difference between Java and C# (or between Java and .NET) was negligible. Now I believe there’s a fundamental philosophical difference, which I’ve found comparing two similar technologies: the Sun’s JCR and Microsoft’s LINQ.
Microsoft’s LINQ
LINQ is Microsoft’s Language Independent Query extension to their .NET languages. In their overview, Don Box and Anders Hejlsberg introduce it thus:
After two decades, the industry has reached a stable point in the evolution of object-oriented (OO) programming technologies. Programmers now take for granted features like classes, objects, and methods. In looking at the current and next generation of technologies, it has become apparent that the next big challenge in programming technology is to reduce the complexity of accessing and integrating information that is not natively defined using OO technology.
I frankly doubt that claim — it’s not remotely apparent in anything I’ve read that accessing non-OO data is either “the” big challenge (implying there are no others) nor that it is “next” (implying both that OO is sorted out now, thank you, and that no-one has yet addressed this current area). But whatever the reasoning, the telling thing is that Microsoft has chosen to address this issue.
Despite being largely ignorant of .NET, I’ve had a quick read of the above article. I kind of lost my grip on things very quickly, particularly when I read “Lambda expressions are similar to CLR delegates and must adhere to a method signature defined by a delegate type”, a phrase I will commit to memory for entertainment purposes. But I did manage to salvage the following
- LINQ allows SQL-like data access using select, where, orderby, etc.
- The queries can by made using standard OO-syntax, but VB 9.0 and C# 3.0 have been specially extended so that SQL-like statements are first-class statements, allowed directly in the source.
- It has been designed so that the source data is irrelevant — files, relational database tables, XML documents, and more can all be cross-queried in the same statements.
- Support for object arrays, relational database tables and XML is built in.
There’s been a lot of noise around LINQ. Jon Udell expresses his excitement quite snappily, as he explains how he can do “a three-way join across an XML data source and two CLR objects”. But before we go into more detail, let’s move on to what Sun has to offer…
Sun’s JCR
The near-equivalent in the Java world is the JCR, the Java Content Repository. From the spec:
As the number of vendors offering proprietary content repositories has increased, the need for a common programmatic interface to these repositories has become apparent. The aim of the Java Content Repository (JCR) API specification is to provide such an interface and, in doing so, lay the foundations for a true industry-wide content infrastructure.
That’s a pretty lofty aim. But what it boils down to is relatively straightforward:
- It’s a set of Java interfaces to access content, either by drilling down through a hierarchy or accessing data items directly with unique IDs.
- Different data sources are encompassed in a single repository.
- Data can also be queried through the (SQL-like, but rather under-specified) JCR Query Language or XPath, but queries are confined to individual data sources, unlike LINQ.
The JCR has been subject to substantially less hoopla than LINQ, which no doubt is partly a symptom of its genesis through the bureaucratic process behind any Java Specification Request (JSR). It is JSR-170, which means there were 169 requests before it (and plenty more to come).
So what do we learn from all this…?
What LINQ and JCR tell us
Strictly speaking, comparing LINQ and JCR is like comparing apples and oranges. But that’s the point. The telling thing is that the two companies chose to pursue slightly different paths in the same arena.
LINQ demonstrates a very developer-centric view of the world, while JCR demonstrates a very corporate view of the same world. LINQ answers the developer’s question “How can I access this data easily?” while JCR answers the manager’s question “How can I manage my various content repositories efficiently?” LINQ extends the language, while JCR provides a new library.
LINQ seems good at accessing low level objects — XML files, database tables, in-memory objects, etc. But it does not address the issue of enterprise-level data sources — personnel records, document management systems, etc. It allows the developer perform their low-level task with (to put it bluntly) fewer keystrokes. But it doesn’t give their manager the security that their data is being brought under control. I think it’s indicative that not only does LINQ extend the core languages of .NET, but in my travels I discovered yet more C# language extensions, most notably delegates (the equivalent of closures) and the “yield return” statement (a convenience for creating enumerations). Also on the theme of keeping the thinking small, Jon Udell updates his blog entry above noting that LINQ’s XML querying is in-memory only, so it’s not going to handle your enterprise-scale XML database — at least, not yet.
Conversely, JCR is solely aimed at bringing together those enterprise-level data sources, but the developer still has the same day-to-day headaches — code with JCR is no less cumbersome than it was before. The manager can be reassured that their data can now be accessed in a common way, and when buying a new content system they can rely on a new standard to make the integration easier. But for the developer Sun offer no syntactic sugar, and the code snippets indicate that there’s a still a lot of set-up before you can access your data — there are queries and query managers, node types and node type managers, observation managers… And if you want to run cross-queries over your data sources then you still have to do the same heavy lifting you did before.
It’s easy to see how Microsoft and Sun made these separate journeys. Microsoft is famously responsive to its development community, while Sun develops Java through its Java Community Process, which is populated by corporate representatives. Why should Microsoft consider other corporate software vendors? They’re only competition, and if you start developing with a Microsoft platform you know that embracing its competitors at any point is swimming against the tide. Why should Sun put small-scale developers over large software representatives? Sun isn’t in a position to call all the shots and Java’s broad industry support is what has given it the weight it bears today. There isn’t a single JCR implementation, but there is a reference implementation produced not by Sun but by CMS vendor Day, plus an open source version.
Neither of these directions is necessarily wrong, and it’s an easy (and lazy) to say that the “right” approach is a balance of the two. But most interesting is how the two platforms (.NET and Java) differ in philosophy. .NET was originally seen as Java-killer, and was no doubt intended as such, too. But the philosophy of its owner-company is taking it in a direction quite different to that of Java. It’s still very much focused on addressing developer-level issues at the expense of corporate-level issues, while Java is addressing issues at the corporate level and leaving the development community largely untouched.
