Skip to main content

integerated query in java like linq

49 replies [Last post]
ramimahdi
Offline
Joined: 2004-05-29
Points: 0

I wonder why the java community is acting oblivious about the new features in C#3 and VP9 namely what is called linq

http://download.microsoft.com/download/5/8/6/5868081c-68aa-40de-9a45-a38...

I guess what linq introduced of the intergerated query into the language will make up the new gerneration of programming language which will make java a whole generation behind.

we write code and loop to do very often stuff like sorting array of objects based on field like sorting studens by grade

or combining two collections or two arrays in one. Or delete some objects from a collection that comply to some constraint.

If you say those operation are not that common then believe me you did not program much

if you say that SQL is not experssive language and not that appropriate for those cases then believe me you are just fool and dont know what you are talking about

see the following examples from linq

IEnumerable expr = from s in names
where s.Length == 5
orderby s
select s.ToUpper();

or imagine writting things like

int [] newArr = select * from arr1 union arr2
or
Student[] st= select s from Student where s.getGrade()=='A' orderBy s.getGPA() DESC.

Every one who used SQL heavily before can understand the potential it can bring to programming language. Plus obtimizers can be written to make this code faster than the original loop. For example a standard fast sort can be used instead of making the user implementing his own. Or better join techniques.

please if you are not sure your mind is big enough to understand the importance of this dont bother to participate in this topic because I started to believe some people around here are just to keep java backward and anti any new thing.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
sjasja
Offline
Joined: 2004-08-15
Points: 0

> String[] names = {"Burke", "Connor", "Frank",
> "Everett", "Albert", "George", "Harris", "David" };
>
> IEnumerable expr = from s in names
> where s.Length == 5
> orderby s
> select s.ToUpper();
>
> --------------------------------
>
> can you imagine how much code u need to implement
> this simple line

[code]
ArrayList list = new ArrayList();
Linq.addAll(list, "Burke", "Connor", "Frank", "Everett", "Albert", "George", "Harris", "David");

Linq.pick(list, new Linq.LengthEquals(5));
Linq.sort(list);
Linq.map(list, new Linq.ToUpper());
[/code]
The implementation of pick() and map() is left as an exercise for the reader :-[i][/i])

Has anyone studied how much of this can be done right now without introducing additional syntax? If most of it can be done with a library of tools for mapping / filtering / grouping / etc, and any bits that can't be done are rare corner cases, we could have a working equivalent without waiting for years and risking the whole language by building a huge stinking lemon right in the middle of it. Are there practical cases that occur often and can't be done easily enough?

Or is it an absolute requirement that whatever happens, new syntax must be introduced, and no library alternative will ever be acceptable?

david_hall
Offline
Joined: 2003-06-12
Points: 0

> [code]
> ArrayList list = new
> new ArrayList();
> Linq.addAll(list, "Burke", "Connor", "Frank",
> nk", "Everett", "Albert", "George", "Harris",
> "David");
>
> Linq.pick(list, new Linq.LengthEquals(5));
> Linq.sort(list);
> Linq.map(list, new Linq.ToUpper());
> [/code]
> The implementation of pick() and map() is left as an
> exercise for the reader :-[i][/i])
>
> Has anyone studied how much of this can be done right
> now without introducing additional syntax? If most of
> it can be done with a library of tools for mapping /
> filtering / grouping / etc, and any bits that can't
> be done are rare corner cases, we could have a
> working equivalent without waiting for years and
> risking the whole language by building a huge
> stinking lemon right in the middle of it. Are there
> practical cases that occur often and can't be done
> easily enough?
>
> Or is it an absolute requirement that whatever
> happens, new syntax must be introduced, and no
> library alternative will ever be acceptable?

Ever look at JGA? A lot of this ground has been covered and what hasn't been should be an easy extension.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

> > [code]
> > ArrayList list = new
> > new ArrayList();
> > Linq.addAll(list, "Burke", "Connor", "Frank",
> > nk", "Everett", "Albert", "George", "Harris",
> > "David");
> >
> > Linq.pick(list, new Linq.LengthEquals(5));
> > Linq.sort(list);
> > Linq.map(list, new Linq.ToUpper());
> > [/code]
> > The implementation of pick() and map() is left as
> an
> > exercise for the reader :-[i][/i])
> >

darline....... you only used the simple example I posted to demonstrate that the LINQ can deal with java application collections or arrays and not just data base and this sample you provided work fine but it wont be as compact in other cases where for exampel you need sort based on the return of a method (like st.getGPA() from array of students objects)............ you will have to implement the commparator method ....... and if in other case you want to sort by (getName() of students) .... I am not sure what you will need to do ....... but u will need to implement otherthing .......... in other word (redunduncy)

so my point is none of your APIs guys do as well as LINQ
nothing can compete with SQL or XQuery when it comes to data or collections manipulation

plus SQL or XQuery are very simple languages and its the most expressive out there ........ very little does alot and it still the most readable

plus ........ other cases need join, union, group operation like (average of getGPA() of students objects)... why should I always be looking for APIs if there would be small set of operator with simple logic that can do it quickly

> Ever look at JGA? A lot of this ground has been
> covered and what hasn't been should be an easy
> extension.

I have looked at it ......... and it is in no way close to LINQ effeciency.......... its two generations backward than LINQ

wake up guys ...... LINQ is the new generation of programming languages ....... finally new level after object oriented programming ....... soon the academy will creat names for it...... like Q&OOP instead of OOP

sjasja
Offline
Joined: 2004-08-15
Points: 0

YYYYYYooooouuuurrrrrrr "." kkkkkkeeeeyyyyyy iiiiisssss ssssttttuuuuccccckkkk........

A mix of SQL queries and procedural logic is not exactly a new invention. If a relational model is the ultimate programming model for you, you might enjoy taking a look at PL/SQL. There are some lessons to be learned there, both positive and negative.

jwenting
Offline
Joined: 2003-12-02
Points: 0

correct. I was using embedded SQL in Cobol and C a decade ago and I was late to the game, others had been using it 20 years before that.

Let's not f*ck up Java more than insane "feature" proposals are doing already.

wtff
Offline
Joined: 2006-02-10
Points: 0

it seems to me that the dislike of LINQ that some people expressed within this thread mostly stems from the fact that LINQ is not only an additional set of operators to be used in expressions/statements to operate on native data structures but at the same time applicable as an embedded query language for persistent data stores.

after the last two posts, ramimahdi could once again try to point out that LINQ is NOT merely an embedded query language for persistent data stores but also works on collections, object graphs and so on, but as this obviously doesn't seem to stick, perhaps it's best to assume for a minute that LINQ was only applicable to native data structures.

In this case, there wouldn't be too much ground to reject LINQ-like operators per se:

Boolean algebras and set algebras have been proven to be isomorphic and both notions are without doubt just as fundamental as arithmetic algebra.

Yet, there is language level support for arithmetic operators ( +, -, *, / ) as well as for boolean operators ( &, | , !) but none for set operators.

Therefore, from a strictly academical point of view, anyone who refuted native support for set-based operators like "union", "intersection" and "complement" would also have to disapprove of native support for boolean operators or arithmetics or otherwise be called arbitrary.

Furthermore, from a programmers point of view, the same induction could be applied:

Whoever opted against native set-based expressions like

set1 union set2

by stating that they could be rewritten as

(new Set(set1)).retainAll(set2)

would also have to admit that boolean expressions like

a | !b

were futile since they could be rewritten as

a.or(b.negate())

or otherwise be called arbitrary.

The least thing that needs to be granted is that there is no native support for set-based operators in java and that this is rather due to the fact that set based data structures were not present in java right from the beginning rather than there being any good reason not to have set-operators.

Now, all those who tend to agree to the above reasoning, will probably only differ in how extensive support for additional operators should be and what the extend of operators should be:

- how many further operators are reasonable?
none? only set-based ones? further support for sorting (which is a mathematical notion if one calls it ordering)?

- how ubiquitious shall the applicability of such operators be?
applicable to primitives and their wrappers only?
further applicable to collection types?
further applicable to object graphs?
further applicable to types representing XML?
further applicable to inquiry of persistent data stores?

So, would it perhaps be valid to say that the more numerous the proposed operators and the broader their proposed applicability, the greater the opposition seems to be and the greater the divide between usefulness and riskiness?

On this ground, it might be interesting to explore how much reception ramimahdi's proposal would get if it had a narrower scope.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

wtff,

I see your point but then why stop there? Why don't we push *all* the operators possible in the world into the language? I mean, what about adding a Jacobian transform operator into the language? :)

I personally feel that the only operators that belong in the language are those which are used *very* frequently. I would even daresay that the bit operators don't belong in the language. Boolean and basic algebra obviously does (because they occur so frequently) but in my many years of programming I have almost never used the set operators.

Maybe this is more a matter of what field you work in. If your programming includes many formulas and other scientific calculations then maybe Fortran and friends is a better language for you. Just like if you do tons of bit manipulation, maybe ASM is better for you. In my personal experience, I rarely need to use the kinds of operators that the advocators of LINQ are pushing for.

I fully appreciate the fact that it must suck to have to translate formulas into Java code and I wish there was some way to simplify it so it is easier to read, but I'm not sure I agree that the LINQ approach is the ideal solution. Perhaps C++ is better suited in that it allows arbitrary operator overloading.

Gili

tompalmer
Offline
Joined: 2006-08-26
Points: 0

After reading mjablonski, never-mind on my comment above about expression types. Well, explicit support might still be nicer than parsing byte code, but the solution is already available, I guess. My bad. (Although I agree that closures and more would make this easier to read and write.)

cowwoc
Offline
Joined: 2003-08-24
Points: 0

There is little doubt in my mind that Native Queries are a great idea. Though the use of those funky arrow operators, property support and others is a different story (I am against them). I support Native Queries for Java as laid out in the whitepaper.

I personally don't feel there is a need to integrate this into the JRE until the technology matures. Give it a few more years to see what sort of performance it results in and for us to understand any corner cases it might introduce.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

it seems many of you guys are the missing the point of what is LINQ about

mapping relational database to classes and using native queries to query the database is only sub-part of LINQ and its called DLINQ

actually its has almost the same way of mapping EJB3 classes to tables but instead of writting EJBQL as string and pass it at the run time ........ DLINQ is alowing to write those queries as native standard .NET code ....... and it will get IDE and compiler support

but the new thing with LINQ that is not available in anything in java or in this native queris you are talking about is that you can deal with run time collections or arrays in your application as database tables of objects

so u can use all the rich operators of SQL or XQuery to manipulate those collections of objects
1- simple sorting
2- filtering
3- joins
4- union
5- grouping
6- group operations (sum, avg, .........)

here is a simple sample to get all the strings whose length is 5 and sort them too

--------------------------------------
String[] names = {"Burke", "Connor", "Frank", "Everett", "Albert", "George", "Harris", "David" };

IEnumerable expr = from s in names
where s.Length == 5
orderby s
select s.ToUpper();

--------------------------------

can you imagine how much code u need to implement this simple line

plus the same queries syntax standard is used for
- DLINQ to query database
- to quey unstructerd files
- to query xml files
- to query collection of objects

wtff
Offline
Joined: 2006-02-10
Points: 0

considering the popularity that the "native XML" proposal for SE7 is getting and how so many people consider it to be a good idea, I cannot help but think that native support for Lint expressions would be just so much more valuable than that...

... you would not need to have native XML support any more because all the transformations could be done with native Lint in the first place.

It definitely has it's sweetness...

carlrosenberger
Offline
Joined: 2003-12-01
Points: 0

Thanks for the reference, Maik.

Here is a preview how Native Queries will look like with closures:

List students = database.query (
{ Student s => s.getAge() < 20 && s.getName().contains("f"); }
);

--
Carl Rosenberger
http://www.db4o.com

wtff
Offline
Joined: 2006-02-10
Points: 0

hehe, this looks NICE!

together with property support one would yield:

List students = database.query (
{ Student s => s.age < 20 && s.name.contains("f"); }
);

---

One thing that might also be of interest in the context of this discussion is JSR 308 "Annotations on Java Types".

I have to say that I was upset to see this JSR pass the review ballot and I do not like the annotation samples given within the JSR at all.
But be that as it may, it seems that this kind of annotation support is likely to make it into SE 7.
(at least the JSR states SE7 as their target this in section 2.3)

Here's how such annotations might be used to create something similar to Lint's capabilities:

void someMethod()
{
@Sql(" select s from students where s.grade == 'A' ")
List result;

@XPath(" students[@grade='A'] ")
List result;

@Regexp(" \bla\ ")
String match;

...
}

The disadvantage of this is that the expressions are still just strings. Of course, there's a standardized APT processor API which could validate these expressions at compile time and inject bytecode that implements the expressions..
The advantage over Lint would be a greater flexibility. The expression languages supported (regexp, XPath, SQL etc.) and the target domains (object graphs, XML DOM, Strings, persistent datastores) are freely extensible and agnostic to the base java language features.

Assuming APT and JSR 308 as given, what would have to be added to SE7 to be able to cover Lints capabilities completely?

In my opinion, the following might be advisable:

- in SE7 the java.lang.model.** packages should be expanded as described within the following exciting paper: http://bracha.org/mirrors.pdf
This would allow APT processors, java agents (java.lang.instrument.*) or custom classloaders to instrument bytecode without having to resort to third-party tools.

- native support for domain specific language expressions within annotations via predefined grammars so that IDEs could syntax-color and validate expressions at design time.
Today's APT API already has rudimentary support for interacting with IDEs -> javax.annotation.processing.Completion.
Therefore, the idea of of further APT support for IDE-cooperation capabilities might not be completely far fetched.

Of course, the possibilities of bytecode-instrumentation have been mentioned before and any AOP tool can bring in LINT-like features as of today, but my direction of thought is rather centered around standardized java features. Perhaps, as there seem to be so divers opinions/requirements on this topic and as neither Lint nor current java language features seem to be able to make everyone happy, the way to go might be to think of something that is even cooler than Lint. And perhaps, such a thing might not resemble Lint at all.

I just meant to bring in another thought to this discussion. I am NOT basically disinclined towards Lint.

There is one thing I'd like to say in ramimahdi's defense:
I think it's a totally valid point to argue that among the current proposals, there is none that succeeds to embody the original intention of the programmer as well as the Lint expressions do, i.e they are very readable and semantic-preserving to my mind.
This still doesn't mean that Lint integration in Java is desirable, but there's no use in denying any of Lint's pros. If the cons seem to outweigh the pros, why not rather say so, instead of trying to disavow the pros? At least that's the impression I got at some points within this thread but then again, this might have been provoked by things ramimahdi said at the end of his initial post. ;)

sentinel101
Offline
Joined: 2003-08-09
Points: 0

> Properties are also niche-specific.

Why are the discussions about properties in Java so intense when properties are niche-specific. Properties in C# are very elegant, I especially like them in Intellisense because they simply have another icon than methods.

> Closures are nothing but overglorified function pointers (with a bit more functionality but you get the point).

This is a simplification. Take a look at some Ruby code and you will see how closures support elegant programming.

> LINQ like things also has minimal if no positive impact for the majority of Java users.

The future will decide. I would bet some cents that discussion about J-LINQ will start in about two years (perhaps the next EJB-Spec that will then be incorporated into the language).

> Bottom line is you're asking for a lot of "cool features" that:
>
> 1) only benefit a very small part of the community
> 2) already have sufficient workarounds in most cases
> 3) will introduce a lot of complexity if added to the
> language
>

Cool features are great, but they are even greater when they are useful :-)

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

>>discussion about J-LINQ will start in about two years
wow ......... two years ..... thats mean it would not be JDK7 .......... at least JDK8

that will be 4 years from now and 5 years after the launch of .NET LINQ

thats disappointing !!!!!!!!!!!!!!!!!!

I think they should modify the language to allow third party tool to add this kind of extention easily still and get compile time support and be easy to deploy to

if you see the saffron project ...... you can see how frustrating it can be at the installation

podlesh
Offline
Joined: 2004-07-26
Points: 0

> I think they should modify the language to allow
> third party tool to add this kind of extention easily
> still and get compile time support and be easy to
> deploy to

They just did - you probably heard about "opensourcing" JDK. That includes compiler.
Go and implement this. Or improve the saffron project. If you make it good, you will have some real argument and show real benefits for Java. You will have real projects using that, not just cool tutorials.

sentinel101
Offline
Joined: 2003-08-09
Points: 0

> > Hi ramimahdi,
> >
> > I also can't understand the sometimes extreme
> > conservatism concerning the Java language. I mean,
> C#
> > greatly benefitted from Java on its invention, but
> > today C# makes the pace (think about generics,
> > foreach-Loop, ...) so I expect that the same
> happens
> > with LINQ.
>
> There are problems with LINQ :
> - SQL/XPath are not C#, they have a different
> semantics
> (nullable, boxing, converstion, operator, etc.),
> LINQ allows to write SQL with the C# AST
> which burden the developer about the semantic
> of a LINQ expression.

LINQ is NOT SQL ! It looks a little bit like SQL but it's just C#-Syntax which is converted by the compiler into method calls on full-blown C# objects, so yeah you definitively have C# semantincs here :-)

> - the return type of a query is an iterator,
> in Java its a RowSet (i.e enhanced list).

Why is this a problem ? You typically use ResultSet for iteration otherwise you suck the whole result set into memory before processing.

> - EJB3 or JDBC4 separates queries declaration from
> their uses which leads to a better reusability.

Old story, isn't it. It's always better to put the queries in a central place for better management of them. I admit that I would do this with LINQ when used with the database. But if I use it for querying collections or XML-Docs I will write my query just in-place. As it's built-in C# you can encapsulate the LINQ-Queries in any C# construct that you can imagine (Singletons, Factory-Methods, ...).

> - Request optimisations by the language seems to
> be a premature optimisation because there is
> no way to declare a transaction in C#.
>

? Don't understand that. Optimisation is the job of the LINQ-Provider, it's not part of the language/compiler (which just produces the AST and hands it over to the provider).

> The only advantages of LINQ is that
> queries are type-checked.
>

I doubt that it's the only advantage. I highly recommend playing with the preview of LINQ, you will see, it rocks.

Mike

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> they are againist everything new to the language
> 1- operator overloading
> 2- multiple values return of a method or ref or
> whatevery that enables you to get more than one value
> out of a method
> 3- properties
> 4- closure
> 5- LINQ like things

ramimahdi,

If all this stuff was so good, you'd think that less people would have moved off C++ to Java and move people would be moving from Java to C#. In fact, this is not the case. Operator overloading is known to be abused when open to the general public. It only has a very small niche where it absolutely makes sense (the scientific community). Properties are also niche-specific. Closures are nothing but overglorified function pointers (with a bit more functionality but you get the point). LINQ like things also has minimal if no positive impact for the majority of Java users. Bottom line is you're asking for a lot of "cool features" that:

1) only benefit a very small part of the community
2) already have sufficient workarounds in most cases
3) will introduce a lot of complexity if added to the language

You're not going to get any feature into the language unless:

1) a very large percentage of the community would benefit by having it added
2) there are no good workarounds
3) it is relatively simple to introduce into the language and/or it is a "solved problem" that simply has to be ported over to Java

There are some exceptions to these rules (such as "marketing wants it") but I don't think this holds true for your request.

Gili

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

>>You're not going to get any feature into the language unless:

>>1) a very large percentage of the community would benefit by having it added
>>2) there are no good workarounds
>>3) it is relatively simple to introduce into the language and/or it is a "solved problem" that simply has to be ported over to Java

these conditions all applys to LINQ like think to java
some survies some time soon will show this to you

I still recommend you to see some tutorials about LINQ

but the thing is why java should be late to have such a feature ............ the java community should have the ability to offer new solutions before its being asked to

sentinel101
Offline
Joined: 2003-08-09
Points: 0

I've also played with LINQ and watched some interesting videos with Anders Hejlsberg (chief designer C#, take a look at http://channel9.msdn.com/showpost.aspx?postid=114680).

I think that extensive language design knowledge went into LINQ, and it's the right step into a more descriptive way of programming. You describe WHAT you want to do with your data instead of explicitly telling everything about the HOW (for loop, comparators, sorters ...).

Don't forget that the same syntax can be used for ALL types of data (collections, XML documents, database tables, whatever). And the framework is extensible so you (basically) have to implement IEnumerable to get the whole infrastructure for integrated queries.

When I look at the discussion about properties, which were part of C# since its beginning, I fear the we will talk about LINQ for Java in a similar way just in one or two years from now.

Sorry for posting such a glaring statement pro LINQ on java.net but it's always good to know the enemy :-)

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

hey thanks sentinel101 for your support

I hope every one will watch the video before he participate here

http://channel9.msdn.com/showpost.aspx?postid=114680

I know what you are talking about

I still too dont understand the psychology going around in the java community

they are againist everything new to the language
1- operator overloading
2- multiple values return of a method or ref or whatevery that enables you to get more than one value out of a method
3- properties
4- closure
5- LINQ like things

and what surprise me more is that whenever I get into a .NET forums they have completely the opposite attitude

I read in one article about the difference between java and .NET is that sun takes in consideration the initial react of its audiance toward everything seriously while microsoft makes rigorous studies independent of what its audience think ....... becuase human nature hates change while change in fact could be a great step that wont be recognized unless after some time

sentinel101
Offline
Joined: 2003-08-09
Points: 0

Hi ramimahdi,

I also can't understand the sometimes extreme conservatism concerning the Java language. I mean, C# greatly benefitted from Java on its invention, but today C# makes the pace (think about generics, foreach-Loop, ...) so I expect that the same happens with LINQ.

I know that it's easier for C# to evolve faster than Java because it's Microsoft's own language. But in the field of ORM, it's interesting to know that Microsoft had something like Hibernate nearly production-ready two years ago (it was called Object-Spaces) but they dropped the whole thing in favor of returning back to the start and ask some more fundamental questions. The result of this process is LINQ which integrates the concept of queries deeply in the language.

forax
Offline
Joined: 2004-10-07
Points: 0

> Hi ramimahdi,
>
> I also can't understand the sometimes extreme
> conservatism concerning the Java language. I mean, C#
> greatly benefitted from Java on its invention, but
> today C# makes the pace (think about generics,
> foreach-Loop, ...) so I expect that the same happens
> with LINQ.

There are problems with LINQ :
- SQL/XPath are not C#, they have a different semantics
(nullable, boxing, converstion, operator, etc.),
LINQ allows to write SQL with the C# AST
which burden the developer about the semantic
of a LINQ expression.
- the return type of a query is an iterator,
in Java its a RowSet (i.e enhanced list).
- EJB3 or JDBC4 separates queries declaration from
their uses which leads to a better reusability.
- Request optimisations by the language seems to
be a premature optimisation because there is
no way to declare a transaction in C#.

The only advantages of LINQ is that
queries are type-checked.

>
> I know that it's easier for C# to evolve faster than
> Java because it's Microsoft's own language. But in
> the field of ORM, it's interesting to know that
> Microsoft had something like Hibernate nearly
> production-ready two years ago (it was called
> Object-Spaces) but they dropped the whole thing in
> favor of returning back to the start and ask some
> more fundamental questions. The result of this
> process is LINQ which integrates the concept of
> queries deeply in the language.

Rémi Forax

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

>> SQL/XPath are not C#, they have a different semantics

where is the problem with this ....... plus you would not expect the current java syntax to still be effecient after 20 years from now ...... it need to evolve dude for the new ideas

>>EJB3 or JDBC4 separates queries declaration from their uses which leads to a better reusability

the thing in LINQ is not just for database queries. This is only sub-part of it called DLINQ ......... its also to perform queries on collection types or arrays of objects that are within you runtime application and not just backend database and this is the new thing

plus we already write EJBQL which is not java syntax and you only can get the errors in these statements only in the run time and not the compile time like LINQ

plus LINQ offers very effecient way to query XML files without the need to write seperate scripting files like groovy or whatever

if you dont know much about LINQ ....... I'd recommend you to read more ......... I am not knowledgable at it but I know what can do for a programmer

podlesh
Offline
Joined: 2004-07-26
Points: 0

> podlesh,
> Sorry but I don't understand what you are referring to.

I was referring to the original post. How did you came to conclusion that I was arguing with you?? Actually, I have similar opinions.

> I'm not saying that anyone who disagrees with me is
> is wrong.
Ramimahdi did.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

podlesh,

Thanks for the clarification :) Have a good day!

Gili

andreou
Offline
Joined: 2005-12-21
Points: 0

Linq is excellent for reporting. Joins, aggregations, etc. Such things are also useful with in-memory data, not just databases. Hand coding such stuff is way too sub-optimal.

Imagine replacing XPath (or XQuery) programming by equivalent DOM programming. If someone doesn't understand the difference between these two, then it seems unprobable to understand the difference between declarative queries and imperative code in case of Linq or similar projects.

JXPath also tries to deliver similar functionality, but it is string-based (error prone, not type-safe). Saffron looks promising, but with no language or tool support, whatever productivity gains are probably going to be lost on the way as well.

gafter
Offline
Joined: 2003-08-29
Points: 0

The C# LINQ facility is composed of a number of language features that work together. The most obvious of these are closures and extensions methods. In the design of the Java closures language proposal, the authors explicitly looked at use cases that correspond to the kind of things supported by LINQ (and its predecessors in other languages) to ensure that Java closures will be able to support the same kinds of things. Closures alone are not sufficient to get the full expressiveness, but they are a critical component.

The closures proposal does not discuss in full detail the APIs you would be able to (and likely would want to) add to the JDK along with (or after) the addition of closures.

tompalmer
Offline
Joined: 2006-08-26
Points: 0

Are you also looking at expression AST objects (like in LINQ)? That would be needed for some kinds of remote query execution (like reformatting to SQL or whatever). I'm not familiar with all the details, but I dug at least far enough to get some of that idea.

mjablonski
Offline
Joined: 2007-01-18
Points: 0

There's an very interesting concept called "Native Queries" (see paper by William Cook and Carl Rosenberger -
http://www.odbms.org/experts.html#article2), which seems to be a more OO-like "Howto-build-a-query-syntax-into-Java"-solution than LINQ.

You'll use "plain old Java" to express your query and a query-optimizer analyses the byte-code of the expression at runtime and builds up an approriate query against your database.

So you can simply code a query like this (and the Native Query Parser translates this at runtime into your low-level-query language of choice):

List students = database.query (
new Predicate () {
public boolean match(Student student){
return student.getAge() < 20
&& student.getName().contains("f");
}
});

This concept is 100% type-safe & refactorable and works out of the box with any IDE on the market.

And the biggest benefit: You can use the language of your choice (Java) to express your queries. No more need to learn another obscure query-language...

The object persistence solution db4o (see http://www.db4o.com) has already built a Native Query Parser. It eases the development of database-driven applications a lot.

Cheers, Maik

manjuka
Offline
Joined: 2004-07-17
Points: 0

I personally think this is missing the point of LINQ. The idea is to use an SQL-like query language. Building the query using predicate objects is nothing new, and was available in C++ (RogueWave library) 10 years ago.

Comparing your code to "where age < 20" should make it clear why LINQ is useful.

io
Offline
Joined: 2007-01-13
Points: 0

Check it out JoSQL.sf.net

Anyway, I really hope that Java will support SQL like syntax in querying collections and database.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

>> Check it out JoSQL.sf.net

still the queries are in string format and compiler and IDE is of no help

plus no compile time optimization could be performed

you cannot go to this shift in your coding unless you are sure its fully adapted over the long term

podlesh
Offline
Joined: 2004-07-26
Points: 0

That's very nice arguments you have: everyone who does not agree with you is fool/small-minded/incompetent/etc
Unfortunately, these arguments can be used against you, too.

I can see what are they trying to solve. After all, simplifying cumbersome data manipulation was solved many times before in different languages. Look at some functional languages or Smalltalk to see that it is solvable without making crossbreed language.

The only novel approach is that this new syntax is "magic" - it just works and I don't need to care about the details. But simple magic things does not always work, and very often they have to be broken and replaced by more complex thing to get full control. Typical application using simple magic system ends up as a big mess of ugly hacks. You surely know that, if you program as much as you claim.

Authors of this C#3 proposal actually know that. In fact, it is not simple magic: it is quite complex one. It may look simple in simple examples, but complicated data manipulation will be complicated again - and complicated in some special, non-Java/C# syntax.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

podlesh,

Sorry but I don't understand what you are referring to.

I'm not saying that anyone who disagrees with me is wrong. I am simply pointing out a problem with the above proposal and an alternative design that would achieve the same thing with reduced complexity.

My point is, look at something like HTML. Originally we had simple HTML editors, then JSP came along and said "well, you could just embed JSP directly into HTML code". Next thing you know you had IDEs falling over themselves trying to support HTML editors that recognized which part of the code was HTML and which part was JSP and generally speaking the editor experience got a heck of a lot worse.

On the other hand, if you take something like Wicket, your HTML remains HTML and your Java code remains Java code and each has its own IDE and everyone is happy.

Specifically for your SQL example, you could have all your SQL in external *.sql files where each SQL file contains something like this:

Query1 = select ...
Query2 = select ...

And in your Java code you'd have something like:

Query query1 = queryFactory.get("Query1");
Query query2 = queryFactory.get("Query2");

This is basically what we have today, except that currently most frameworks store the SQL in some ugly XML syntax. What they forget is that before Java came along, no one naturally stored and edited SQL code inside XML files, rather they used .sql files. They should use whatever format is native for SQL so that whatever editors you have in the SQL domain can be reused and that would simplify the model beyond what we have today.

Just my 2 cents.

Gili

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

having the sql queries in seperate queries is not practical because the code will be less readable

many times you will have to write small queries that doesnt desever putting in seperate files

I am not talking about integerated sql to query the database
I am talking about sql to query collections and arrays of objects in your application as if they were databases tables

sql is very rich syntax and the logic that needs multiple lines of code in java could be written in one SQL statement and still look more readable than the java code

consider the sample

Student [] allStudents ..
.....
Student[] aStudents= select s from allStudents where s.getGrade()=='A' orderBy s.getGPA() DESC;

imagine how many lines of code you need to write in java to do this single line
and compare the readability of both approaches

I hope somebody here will do me a favour and try to write it in java to compare

actually if this approach is well adapted with good performance then I am sure in the next years the code we are writting will look so much different
there will be no more complex loops and redunduncy in operations

its a hell of a very experissive syntax

plus most developer know SQL very well

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> I am not talking about integerated sql to query the
> database
> I am talking about sql to query collections and
> arrays of objects in your application as if they were
> databases tables

Okay, I understand your proposal now and I am even more dead-set against it. Have you tried playing around with ORM frameworks before? Do you realize what kind of a nightmare it is to map objects to relational databases and back? Why would you want to introduce this kind of huge hole into the Java language? ORMs are *full* of corner cases, complexity and problems. Why don't you use OO syntax to interact with objects and relational logic to interact with relational entities? You'll end up with much cleaner, shorter and more readable code.

> Student [] allStudents ..
> .....
> Student[] aStudents= select s from allStudents where
> s.getGrade()=='A' orderBy s.getGPA() DESC;
>
> imagine how many lines of code you need to write in
> java to do this single line
> and compare the readability of both approaches

I'm not the best developer in the world but here is my Java implementation off the top of my head (someone else can probably write it better):

[code]
Collection students = ...;
Collection result = new TreeSet(new Comparator()
{
public int compare(Student first, Student second)
{
/* Sort by decreasing GPA */
return second.getGPA() - first.getGPA();
}
});
for (Student s: students)
if (!s.getGrade().equals("A"))
result.add(s);
[/code]

That's the long-way of doing it. If you Student implements Comparable then you can cut out the entire Comparator section and the resulting code is very small and readable. At least with Java code you get compile-time errors if you make a mistake. With SQL you get nothing. If you want compile-time errors for your SQL syntax you're going to have to build a SQL compiler directly into javac which is, again, a horrible idea because the complexity of javac and IDE goes way up with minimal benefit. You could achieve *exactly* what you are asking for by adding more Collection helper classes to do the kind of searches you are asking for with less keystrokes and doing so is much cheaper than changing the underlying language.

> plus most developer know SQL very well

I disagree with this as well. Most developers know how to write extremely simple basic selects, nothing beyond that. Not to mention the insanity of trying to understand nested queries and all the other corner cases that are very easy to implement in Java but hard to implement in SQL. Bottom line is that SQL is easier to do some things with and Java is better at doing other things with. You will be hard-pressed to argue that it is easier to use SQL syntax to query Java objects than it is to use native Java mechanisms.

Just because the built-in API doesn't have helper classes for your specific needs doesn't mean you can't write them yourself. If they are so useful, you can be sure they'll eventually make it into the Java API.

Gil

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

your coding is really a surprise for me
its so compact to do the same functionality but still cannot you see the difference

the sql statement is still far simpler plus its only one line while yours is at least five lines of code

if you show the two solution for someone who doesnt know what is the problem the sql one surely will be easier to know what its doing

plus you did the compare method but where is the call for sort

this is only simple example
imagine more complex scenarios of joins, unions or grouping by statement

plus good programming practices is about stopping redunduncy ........ why should I always implement the compare method to be able to use some other helping APIs to sort for me

why should I always create loops if there is possible ways of not doing it

its always about redunduncy of coding and readability

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> your coding is really a surprise for me
> its so compact to do the same functionality but still
> cannot you see the difference
>
> plus good programming practices is about stopping
> redunduncy ........ why should I always implement the
> compare method to be able to use some other helping
> APIs to sort for me

I agree with you that "less is more" and generally speaking if you can express the same thing using less code it tends to be more readable. Note I said generally speaking. If you take your line of reasoning too far, I could argue that Perl code is always more readable than Java code simply because you can always express the same thing in much less code using Perl. The fact of the matter is that most developers would agree that Perl code is far uglier and less maintainable than Java code. Good programmers always have to compromise between readability and compactness of code. I'm sure we can find a compromise that will please both of us.

If you're willing to drop compile-time checking you could simplify your problem to almost a one liner. I'll give you an example:

[code]
/* The following code is defined once in a 3rd party library */

public class CompareByProperty extends Comparator

{ private String getterName; public CompareByProperty(String getterName) { this.getterName = getterName; } public int compareTo(Object first, Object second) { Method getterMethod = first.getClass().getMethod(getterName, new Class[0]); Comparable firstValue = (Comparable) getter.invoke(first, new Object[0]); Comparable secondValue = (Comparable) getter.invoke(first, new Object[0]); return firstValue.compareTo(secondValue); } } public class Matcher { private finally Class clazz; public Matcher() { clazz = new Object().getClass(); } public static Collection getMatches(Collection collection, String methodName, Object value) { Collection result = new List(); Method method = clazz.getMethod(methodName, new Class[0]); for (T candidate: collection) if (method.invoke(candidate, new Object[0]).equals(value)) result.add(candidate); return result; } } /* The following code is defined in your user code */ public static void main(String[] args) { Collection students = ...; Collection result = new TreeSet(new CompareByProperty("getGPA")); result.addAll(Matcher.getMatches(students, "getGrade", "A")); } [/code] Let's just say I'm not a big fan of this code (Generics kills readability) but it is shorter as you requested and it is easy to reuse CompareByProperty and Matcher across many calls to do the kinds of things you mentioned. Personally I found my original source-code a heck of a lot more readable :) A final point: you will never kill the loop checking for grade.equals("A"). Just because you don't see a loop in your SQL query doesn't mean someone isn't doing it in the background :) > plus you did the compare method but where is the call > for sort Read the Javadoc for TreeSet, the sorting logic is built into the definition of what a TreeSet is. > this is only simple example > imagine more complex scenarios of joins, unions or > grouping by statement The Collections API can do all of this and more in a very compact and readable manner. I suggest you familiarize yourself with it for a few minutes. You'll find a lot of very cool stuff in there that will help you do most of the things you're asking for. Gili
ramimahdi
Offline
Joined: 2004-05-29
Points: 0

I guess we are in the same side but at different levels

the code you provided is just amazing
but do u expect that the developers should emplement this technique to enjoy such functionality

this is sort of advanced programming and needs good expertize to get it bug free backend

why it is not being standarized to be used in sort of SQL or whatever else pattern that would be compact and quick and still so readable

and still SQL syntax looks much more readable than the last two lines you provided

>>you will never kill the loop checking for grade.equals
>>("A"). Just because you don't see a loop in your SQL
>>query doesn't mean someone isn't doing it in the background

this is the whole point ...... lets write a minimum and let the compiler do all the redunduncy or whatever loops are needed at at the backend

Plus I am not saying loops are bad or we should not use them
I am only saying if there are chances to not do loops and have quicker ways then why not ........... lets save code

cowwoc
Offline
Joined: 2003-08-24
Points: 0

If you want this sort of functionality I would personally support it in the form of a 3rd party library. There is nothing wrong with such a thing. Too many people seem to get obsessed (myself included in the past) with the functionality having to ship with the JRE.

You are better off developing a great library which other people will use and if it becomes popular enough you can be sure it'll get folded into the JRE. Folding new technology into the JRE too soon is problematic because once it's shipped you cannot modify it due to backwards compatibility concerns.

I understand your need to abstract away all this information and "just let the compiler take care of this" but unfortunately it's not that simple. It is true that if the compiler took care of this you could come up with more elegant syntax than if you wrote an library to do the same thing. Still, I bet when you compare the syntax if you build this as a library vs at the compiler-level you will find that the difference isn't that big and in the meantime the complexity of adding this at the compiler-level will be very high.

Even if you want this built at the compiler level you will need to write a library for it which the compiler will invoke. So first step first: write this library. Once you have that you can move forward.

Gili

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

are you kedding

such an engine needs tremendous work to be done

plus hey the Linq solution offered for .NET has two formats ....... one is just sql like or actaully XQuey like and the other is OOP like but still also SQL like

anyway
I have seen the SAFFRON project (an extension to java) and it sound neat but I cannot use that because the installation of their libraries is complex and before you use such a thing you need to make sure the java community is committed to it

what surprise me most is whenever I get to .NET forums they talk very possitively about the LINQ features
and whenever I get to Java forum they are too opposing to these new ideas

tompalmer
Offline
Joined: 2006-08-26
Points: 0

The only way to do this in Java is with criteria APIs or putting queries in Strings. Neither is quite as convenient as the expression (AST-like) types in LINQ. But I'm not sure how you define semantics for everything since you can't necessarily just pass all your object and method definitions out to the DB with your query. I don't have direct experience with LINQ so I'm not sure how they address this.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

>> to do this in Java is with criteria APIs or putting queries in Strings

this is not good and will have alot of bugs
the same way we had those run time errors when passing SQL to database from java

whats good about LINQ is that programming language syntax ....... so the compiler will find the errors early plus intellisence features of the developement tool help you with writting the query

Saffron extension for java is almost the same as LINQ but more deeper analysis and long term adoption is needed plus development tools should support it to be effecient.

language is not sufficient by itself anymore
language + IDE = the power tool

tompalmer
Offline
Joined: 2006-08-26
Points: 0

Criteria APIs (such as http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Criteria.html) are supported in IDEs but not as easy to read or write as for LINQ or Saffron (which I hadn't heard of until now - thanks for the pointer).

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

the APIs you provided is cool but still LINQ is like two or three generations a head of it

such APIs should be supported at the core level, compiler level and the IDE level

passing the conditions, attribute names, methods names as string parameters is big source of run time errors.... if you change your class attributes names then ... u can imagine

plus native support like LINQ could open wide gates for optimization for queries at the compile time ... meaning better performance

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Not to be mean, but I don't like the C# approach.

I understand to be able to better integrate Java with other languages such as SQL, Perl regular expressions, C/C++ and ASM but I am not convince that the C# syntax is the one I'd use. In fact, I am fairly strongly against embedding code from a separate language directly into the same file as the Java source-code. I like the JNI approach of having your C/C++ in one file and Java in another and binding the two. That way you can use your favorite IDE for each language. Furthermore it simplifies the Java compiler logic (and Java IDEs) a heck of a lot; can you imagine how much slower and more complex javac or Java IDEs would have to be to support embedded language constructs?

It would sure be nice to be able to use things like regular expressions "natively" outside of Java strings because for example if I want this regular expression:

\\abc\\

which means "please match a slash followed by abc followed by a slash"

then in Java this would read: "\\\\abc\\\\" which is just out of this world ugly. I can only imagine how ugly it gets if you want to embed more complex language directly into Java.

Look, I don't have a solution for this problem but I just wanted to say that:

1) I don't like the C# syntax
2) If you introduce something like this into Java it should ideally be similar to JNI. From Java's point of view it is 100% normal Java code, from C/C++'s point of view it is 100% normal C/C++ code, and there is clean binding between the two.

If you came up with that something that fits the bill I'd definitely consider voting for it.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

hey I just found this link about a java project that is trying creat something similar in java

http://sourceforge.net/projects/saffron/X

but this extention is not trivial to install and deploy plus it needs to be a standard and committed to

hope to see more post

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

and even this code is very readable

plus most programmers already know sql

if you write the following statement
Student[] st= select s from Student where s.getGrade()=='A' orderBy s.getGPA() DESC.

in traditional it will look much less readable that it looks now

please somebody helps me here