General

For the following reasons:

• SQL has been hugely successful as a language for querying data. Rather than trying to invent a new wheel (and almost certainly getting it not quite circular) it is more appealing to leverage an obviously successful existing design.
• There is an enormous body of documentation, tutorials, theory and best practices for SQL. This means I don't have to write any of it!
• SQL is (mostly) declarative, which is a big benefit for clear and understandable programming, as well as allowing a lot of freedom in implementation
• Using SQL dramatically lowers the impedance mismatch between JEQL and external data sources (in particular, databases). This provides simpler coding and implementation.
• There are a lot of examples of developing SQL engines, which eases the task of developing a new one.

Comparing JEQL directly to SQL, JEQL implements a large (and growing) subset of SQL. It includes the SQL constructs that are most commonly used for data processing. Of course, there's no such thing as a single "SQL" - there are numerous versions and dialects. The dialect implemented by JEQL cherry-picks some of the better, cleaner features of various existing SQL dialects. JEQL also includes some extensions which make it easier to express complex processing using SELECT statements (such as the ability to define named subexpressions in a selected expression list)

But a direct comparison to SQL isn't really the right question. To run SQL you need an engine which can process SQL statements. This usually means running a database of some kind. Also, you need some sort of programming language to "glue" together SQL statements. Some databases have an embedded programming language, some don't. External languages tend to be verbose and complex to interface to databases (as do some embedded ones!). Finally, data import and export is not a strong point of database systems, so that usually means adding some kind of ETL tool to the mix.

Once you have this set of tools, you have to:

• create one or more tables
• import data into the tables
• write a script or program which uses SQL and probably some procedural logic
• export the results to a destination dataset
• clean up the tables

There are lots of things that the database environment will do which JEQL doesn't do. But for simply performing a small processing task, all the extra overhead and complexity is a burden. Another advantage is that if all processing is specified in a single script, it's much easier to automate the task, archive the code, and share the logic with others.

You might decide to use JEQL rather than a general-purpose programming language for the following reasons:

• JEQL is higher-level than most programming languages, and thus many processes can be expressed more simply and more succinctly
• JEQL is more approachable for non-programmers
• JEQL is declarative, which makes many processes clearer
• JEQL is a convenient way to access many Java APIs and functions

For the following reasons:

• Java is fast to develop code for both the engine, and for language extensions
• Java is highly portable (Write-Once-Run-Anywhere is NOT a myth!)
• Java offers fast performance
• Java provides a huge number of APIs, functions, and libraries which can be used to extend JEQL's core functionality
• One mode of operation for JEQL is embedded in a host system; Java offers a very clean, simple, secure environment for embedding.

Yes, as long as the appropriate Reader/Writer is available. It is intended that JEQL should provide Readers/Writers for a variety of popular database systems.