Java 5 support -- generics, foreach loops, autoboxing, etc

[Nat Pryce]

What do people think about moving Squiggle to Java 5? It would mean
losing compatability with old-skool Java, but make the code simpler
and play better with codebases written in the last few years.

[rjch...@gmail.com]

To be honest, I already upgraded my local version of Squiggle to
use generics. I also use @Override but in general, I prefer (normal)
Interfaces above annotations.

I have lots of other improvements in my local version as well,
so I could contribute a lot if I can become a committer on the
project.

For example I introduced "IS NOT NULL" (combining NOT with
NullCriteria
would produce the faulty "NOT IS NULL"), support for functions like
count(*), support for subqueries (allowing SelectQueries in the
from-clause) etc.

On 2 okt, 00:52, Nat Pryce <nat.pr...@gmail.com> wrote:
> What do people think about moving Squiggle to Java 5?  It would mean

> losing compatability with old-school Java, but make the code simpler

[Nat Pryce]

I've already committed a lot of the same functionality.

You can now use literal values, columns and subselects
interchangeably, where appropriate.

I've introduced interfaces to define what can be matched against, what
can be selected, and what may refer to tables (that will need a join).

I've refactored the internals significantly, so you may not be able to
create patches against the current state.

Null and not-null criteria is useful. I'll add that.

If there are no anti-Java-5 replies, I'll convert it all over to use
generics and foreach loops where appropriate.

--Nat

[Derek Mahar]

Nat:

Do you intend to translate the entire Squiggle code base to Java 1.5
or simply add new code that uses Java 1.5 syntax? How would Squiggle
benefit significantly from a translation from the existing 1.4
implementation to Java 5? Squiggle doesn't use any external libraries
and the generic Java container classes wouldn't make the
implementation any more correct, concise, or simpler than it is
already. The code is not so complex that generics, annotations,
foreach, enumerations, etc., would improve it much. On the contrary,
I think generics would simply add a new element of complexity and
potential source of confusion for programmers who still don't often
use generics (granted, this may now be a minority). Do you see any
specific ways in which Java 1.5 would improve the Squiggle code?

Derek

--
Derek Mahar
1.514.560.4949 Mobile
1.514.670.3631 Home
1.514.228.8800 x4150 Work
http://www.derekmahar.ca
102-1365 René-Lévesque Blvd. East
Montreal QC H2L 2M1
Canada

[Nat Pryce]

Most important I think is where collections are returned from the API.
If using Java 5 or above, this API will cause warnings in client
code, which is annoying.

There are also several places where API methods could be given a
generic parameter to add type safety and convenience. For example, it
should not be possible to use different kinds of object to define a
range for a BetweenCriteria. The constructor could be declared as:

public <T extend Matchable> BetweenCriteria(Matchable matched, T
lower, T upper).

--Nat


2008/10/2 Derek Mahar <derek...@gmail.com>:

[Derek Mahar]

Do these benefits warrant breaking compatibility with the Java 1.4
language? Guess this depends on what language version the majority of
Squiggle users are using.

Derek

[Nat Pryce]

1.4 has been end-of-life'd by Sun, which means that large
organisations are moving to 1.5 or 1.6 (depending on how slow or
conservative they are). JavaEE now only supports 1.5 and above, for
example.

Now that Java has been open-sourced, the Linux distros are now
distributing 1.5 and 1.6 instead of the open-source JVMs that were
based on 1.4.

So I think the number of places that use 1.4 only is very low and shrinking.

--Nat

2008/10/3 Derek Mahar <derek...@gmail.com>: