Forum Controls
Spotlight Features

The Rich Engineering Heritage Behind Dependency Injection

Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.

NetBeans 6: Matisse Updates

NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed.

Introduction to Groovy Part 3

In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.

Easier Custom Components with Swing Fuse

Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.

Benchmark Analysis: Guice vs Spring

Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies: 74 - Pages: 5   [ 1 2 3 4 5 | Next ]
  Click to reply to this thread Reply

Language Wars Redux - the imminent approach of LINQ

At 7:44 AM on May 30, 2006, Roger Voss wrote:

Language Wars Redux


Well, here we are in the Java community having gone through many months of absorbing the new language features in Java 5. We've been challenged and then excited by the phenomena of the dynamic scripting languages (and their frameworks) such as Ruby on Rails and even JavaScript in the context of AJAX. At JavaOne we were given a preview of Dolphin where modifications to the JVM will make it more facile to integrate dynamic scripting languages. A strong case was made for potentially integrating XML as a first class type in the Java language. We were wowed by the Groovy scripting language demonstration and excited by the prospect of the ranks of the Java platform numbers swelling as Project Semplice BASIC offers to give VB6 developers a home running code on the JVM.

These have been some exciting and heady times for the Java language and perhaps more especially the JVM platform. (At JavaOne it was clear that Sun has finally come around to fully embracing the notion of the JVM as a universal platform that should do a good job of accommodating other languages besides Java - the marketing position that Microsoft has held toward the .NET platform from day one.)

Alas, there may be some storm clouds appearing on the horizon.

If you haven't heard of it yet, the day will come when we've all heard of Microsoft's LINQ feature for the .NET platform. .NET Language Integrated Query (LINQ) is more fundamentally groundbreaking in language design than, say, a feature such as generics. And its impact on programmers and how they achieve their end goals will be more dramatic than such phenomenon as Hibernate or Ruby on Rails and the revolution of thinking those entailed (ORM/EJB3 db-independent persistence and ActiveRecord dynamic types synthesized on the fly).

There has arisen a mode of thinking in Java land that by embracing dynamic scripting languages we can essentially address shortcomings in Java or bolster Java with exciting new capabilities. The scripting language Groovy is perhaps the ultimate expression to date of this line of thinking. It is an appealing notion - why add new features to Java, such as an intrinsic XML type, when Groovy already has a great markup language feature that makes working in XML very groovy indeed? Attention could instead be focused on making the integration of Groovy more seamless with Java and the JVM - and even making it the flagship scripting language such that it is there out of the box when the JDK/JRE are downloaded (with no additional installation steps required to make Groovy accessible). Given that Groovy scripts can be compiled into .class files it would seem to be the natural vehicle in which to address neat new language capabilities, as it is not limited to just pure scripting such as the likes of a BeanShell approach.

The new challenge: When Microsoft declares C# 3.0 to be production ready, it will have features that essentially leap frog the likes of: EJB3 ORM and its portable query language; many of the features entailed by the dynamic scripting languages - such as the Ruby on Rails ActiveRecord concept; and it will have a very facile ability to work intrinsically with XML. The LINQ feature will essentially unify the representation of query access of data across the domains of relational database, XML DOM, and in-memory collections/object graphs. It will be a language intrinsic capability for universal query. A day will come where it will even be used in every day programming situations - say, query all the fields of a visual form beginning with some name prefix string, and then perform a common operation on all those widgets that the query selected. One of Anders Hejlsberg's favorite demos is illustrating how LINQ can be used to query (and filter with clauses) out of type system reflection information. Thus LINQ is not just for relational database access, nor is it just a replacement for XPath, nor it it just an in-memory database query language. It embraces all of those as it is general purpose - and even facilitates selecting and migrating data between these various domains, i.e., select a data subset from a database while populating it into an XML DOM with trivial effort on the part of the programmer.

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. Alas, with C# 3.0 the use cases for these dynamic scripting languages just shrank a good deal. We're basically left with just the use cases of BeanShell scripting. (Well, there are the first class regular expression features of Groovy as well.)

The LINQ feature draws on language enhancements that were added in C# 2.0 and of course various new additions in C# 3.0. To fully understand LINQ, start by reading the spec doc for C# 2.0 and then move on to the spec doc for C# 3.0 .

In the on-going saga of the Language Wars, Microsoft's new LINQ feature looks poised to kick butt and take names. For in the meantime, over in the Java community, EJB3 persistence and its portable query language syntax will be regarded as the height of Java technology for query. There will still just be XPath for XML, and nothing at all for in-memory object graphs. Tuples? Forget it - will have to bail out to a dynamic scripting language for that kind of thing.

If you came back from JavaOne all pumped up about the state of Java and the JVM as a platform, you've now got yet another anxiety imminently approaching.
1 . At 8:12 AM on May 30, 2006, Ian Griffiths DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: Language Wars Redux - the imminent approach of LINQ

Does that mean that Java is doomed?
What are we going to doooo!?

On a more serious level:

Should we study linquistics and propose new features for Java?

How does LINQ handle security and type safety?

Ian
2 . At 8:50 AM on May 30, 2006, Alex Dolftei DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

You picked the wrong crowd for your preachment

As history shows Java programmers are less likely to accept changes to the Java language.
There was another discussion on Javalobby, not long ago, about the new features in C# 3.0:
http://www.javalobby.org/java/forums/m91952370.html

Java is getting old, and not because the technology is obsolete, but because Java programmers are getting old.

And btw ... yes, there are several scripting languages running on top of Java, but none of the implementations of these languages are mature or stable enough.
Jython and Groovy, the crown jewels of the JVM scripting languages, are currently in a deplorable state ... and it is really troubling that the future of Java depends (even a little) on them.
3 . At 9:13 AM on May 30, 2006, Johannes U. J. wrote:
  Click to reply to this thread Reply

Re: Language Wars Redux - the imminent approach of LINQ

Typesafety is enforced by infering the types. Just as you see in SML, Haskel ect.
4 . At 9:37 AM on May 30, 2006, John Catherino DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

At last: The silver bullet!

And all thanks to Microsoft.

It certainly took them long enough. Let's see with all of their other silver bullet attempts; DDE, NetDDE, OLE, OLE2, COM, COM+, DCOM, ActiveX, .NET; I guess they have really acomplished it, really guys, really.

So we all better scrap what we are doing, and get ready for this great new thing. They finally got it this time, really.

While Java guys have only had one platform for the last ten years, Microsofties got nine! (soon to be ten)
John Catherino; Washington, D.C.
Enjoy free, simple, and powerful distributed computing.
Please visit the cajo project.
5 . At 10:13 AM on May 30, 2006, Andy Tripp DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: Language Wars Redux - the imminent approach of LINQ

> (LINQ) is more
> fundamentally groundbreaking in language design than,
> say, a feature such as generics.

I don't see what's so "groundbreaking" about it. Looks just like embedded SQL to me. Is it groundbreaking that I can access not only a DB but also XML and my own C# data structures via embedded SQL? Why would I even want to do that?

> And its impact on
> programmers and how they achieve their end goals will
> be more dramatic than such phenomenon as Hibernate or
> Ruby on Rails and the revolution of thinking those
> entailed (ORM/EJB3 db-independent persistence and
> ActiveRecord dynamic types synthesized on the fly).

Are you taking bets? :)


> The LINQ feature will essentially unify the
> representation of query access of data across the
> domains of relational database, XML DOM, and
> in-memory collections/object graphs.

Again, why? I don't even like embedded SQL to access a DB. I'll give you 100-to-1 odds against Java programmers replacing their Java code with LINQ for accessing Java objects.

> It will be a
> language intrinsic capability for universal query.

Sounds like it's solving a problem that's not a problem. There's no problem with accessing a DB with SQL, Java objects with Java code, and XML data with a DOM or SAX parser. No need to "unify" these.

> A
> day will come where it will even be used in every day
> programming situations - say, query all the fields of
> a visual form beginning with some name prefix string,
> and then perform a common operation on all those
> widgets that the query selected.

...and why would someone want to do that? I want to add the string XYZ to all fields on a form who's variable name starts with "ABC"? Why?


> One of Anders
> Hejlsberg's favorite demos is illustrating how LINQ
> can be used to query (and filter with clauses) out of
> type system reflection information.

And how does that compare with the equivalent Java code? Not only is the equivalent Java code simpler, it's more readable, requires knowledge of only one language.

> Thus LINQ is not
> just for relational database access, nor is it just a
> replacement for XPath, nor it it just an in-memory
> database query language. It embraces all of those as
> it is general purpose - and even facilitates
> selecting and migrating data between these various
> domains, i.e., select a data subset from a database
> while populating it into an XML DOM with trivial
> effort on the part of the programmer.

You're doing the same thing as the article: assuming that people want to have a unified way of accessing DB, XML, and Java/C# objects.

>
> 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.

We Java fans weren't buying the "strong type checking gets in the way" argument from the Ruby crowd in the first place.

>
> In the on-going saga of the Language Wars,
> Microsoft's new LINQ feature looks poised to kick
> butt and take names. For in the meantime, over in the
> Java community, EJB3 persistence and its portable
> query language syntax will be regarded as the height
> of Java technology for query. There will still just
> be XPath for XML, and nothing at all for in-memory
> object graphs. Tuples? Forget it - will have to bail
> out to a dynamic scripting language for that kind of
> thing.

You may have a point with EJB3, I don't know. But for XML and in-memory, I'm not convinced that there's even a need for a separate "query language".

>
> If you came back from JavaOne all pumped up about the
> state of Java and the JVM as a platform, you've now
> got yet another anxiety imminently approaching.

Competition's a good thing. If LINQ (or any C# technology) gets popular and turns out to be useful, then Java will get it too. Sure, it will probably be years later, but that's better than the alternative - getting lots of not-so-useful features thrown in right away.
Andy Tripp, CTO and Founder Jazillian - Legacy to 'natural' Java.
6 . At 10:16 AM on May 30, 2006, James wrote:
  Click to reply to this thread Reply

Re: Language Wars Redux - the imminent approach of LINQ

What Miscrosoft is doing is really interesting.
It is nice that it challenges [indirectly] other developers to do better, if that is possible.

Nice features like that may attract some developpers to their platform but personnally, as long as .NET is not fully cross platform like Java (with Swing) it is not an option: I need to deploy applications on serveral platforms: Windows, Linux and Mac OS X.

Unfortunately Microsoft is not interested in porting and maintaining .Net (with the graphic part) on the platformS I need to support. It will never happen.

For now I'm very happy to write Java code!
7 . At 10:58 AM on May 30, 2006, Denis Robert wrote:
  Click to reply to this thread Reply

Re: Language Wars Redux - the imminent approach of LINQ

1. Embedding SQL in Java has existed for some time, and has been used by very few. There's a reason for that: SQL just shouldn't be in code. iBatis does a much better job at managing hand-coded SQL when an ORM doesn't fit the job.

2. There are a number of libraries to query object trees. There's no need to encumber the language to gain that facility.

3. Universal Query Language? There are fundamental differences between XML, OO systems and RDMBS at the core data model level, which means that any attempt at a universal query language which covers all three equally will either be impossibly complex, or pretty incomplete. I simply don't believe it.

LINQ? don't care...
8 . At 11:00 AM on May 30, 2006, Richard Lowe DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: Language Wars Redux - the imminent approach of LINQ

Well said. Why is it that people on this site just assume that multi-language is the way to go? it will lead to
nothing but trouble IMHO. Microsoft is pandering to users of other languages to get them on board, it's a pure marketing ploy no technical merit to it. I think a lot of people who go the Multi-language route will curse the day they did it. If Java is patient we can pick up the scattered pieces that are .NET programs.
9 . At 11:01 AM on May 30, 2006, Catalin Merfu wrote:
  Click to reply to this thread Reply

Re: Language Wars Redux - the imminent approach of LINQ

It's good. Make Java "the efficient way to build software" by inventing technologies that are 10x slower and consume 5x the memory.

I'm tired of fighting C programmers as I got tired 15 years ago fighting assembler programmers. I want to be in the fast side of the fence by continuing to develop in Java.
10 . At 11:38 AM on May 30, 2006, Alex Dolftei DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: At last: The silver bullet!

> It certainly took them long enough. Let's see with all of
> their other silver bullet attempts; DDE, NetDDE, OLE,
> OLE2, COM, COM+, DCOM, ActiveX, .NET; I guess they have
> really acomplished it, really guys, really.

So, you are comparing an operating system with Java ?
Nice way to show some skills.

> While Java guys have only had one platform for the last
> ten years, Microsofties got nine! (soon to be ten)

I never realized that LINQ is a platform.
But if you say so.
11 . At 11:46 AM on May 30, 2006, Alex Dolftei DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

You picked the wrong crowd for your preachment ... part 2

As I said in my previous reply ... Java programmers are old-school, incapable of comprehending and understanding new things, incapable of moving out of their confort zone.
(at least the ones that spend their time on Javalobby and TheServerSide)


LINQ will be a hit, if only because it introduces declarative capabilities to an imperative language.
LINQ-like capabilities have been available for years in functional languages, and it is really great to see such a great evolution in the mainstream language that is C#.


I am not saying that Java should get something like LINQ, I am only suggesting that improvments to the language and the platform are sometimes good.
Open your eyes guys ;)
12 . At 11:58 AM on May 30, 2006, Jilles van Gurp DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

don't worry

Don't worry, LINQ is not a silver bullet. Just like RAILS isn't a silver bullet, just like C# 1.0 and 2.0 were not silver bullets.

The thing with silver bullet technologies is that they always fail to deliver on their original promises and sometimes deliver something new to the field. LINQ might be in the latter category. If so, ideas will quickly be picked up and integrated into Java. But yet another query language does not really sound exciting to me. A few years of experience has taught me that databases are best done by those who actually understand them. The last thing you want is some jerk writing insert queries and breaking the datamodel from some ui class. n-tier architectures are actually quite nice when working with junior developers in the top tiers.

XML integration does sound more interesting. That remains an unsolved problem. IMHO most of the xml libraries for Java are crap and based on the misguided notion of xml schemas which are hideously complicated ways of specifying syntax rules for really simple data structures (something that is trivial in plain java). The fact that that is not a simple thing to do is the problem. Annotations partially solve the problem but annotations are really compensating for the lack of native language constructs. They're still cumbersome and still require external tooling which is generally difficult to work with and at this point not really standardized. Linq seems to have a solution for that.
13 . At 12:14 PM on May 30, 2006, John Catherino DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: At last: The silver bullet!

> So, you are comparing an operating system with Java? Nice way to show some skills.

Yes. The Java Runtime Environment was in fact developed specifically to abstract away specific operating system APIs; to allow developers to create code that runs unmodified, on multiple operating systems. The Sun JRE is currently supported on Windows, several Unix variants, and Mac OSX.

You must be new to Java, welcome.
John Catherino; Washington, D.C.
Enjoy free, simple, and powerful distributed computing.
Please visit the cajo project.
14 . At 12:22 PM on May 30, 2006, Alex Dolftei DeveloperZone Top 100 wrote:
  Click to reply to this thread Reply

Re: At last: The silver bullet!

> Yes. The Java Runtime Environment was in fact developed
> specifically to abstract away specific
> operating system APIs

Yes, Java rulz ! :) I know.

But still, you are comparing an operating system with Java.
And Java is no operating system, and it will never be, no matter how much abstraction from the underlying operating system it contains.

How many platforms does UNIX (Linux in particular) have ?
What about Mac OS ?
Why won't you count those and compare to the ones in Windows ?

How about comparing apples to apples for a change ?

thread.rss_message