KOPI
PrevChapter 3. XKJC eXtended kopi Java compilerNext

Java language extensions

Syntactic extensions

Operator overloading

not yet documented, but you can take a look in the oper folder of XKJC sources.

Embedded SQL

By providing an easy way to include SQL statement inside your Java code (not between double quote), XKJC made it more easy to read and maintain. With explicit typing the compiler check that expression are correct and involve the overloading mechanism to execute expression such as:

Connections

By providing explicit connection to SQL statement you are able to work on more than one database at the same time. But since common applications work with only one database, we provide a mechanism of implicit transaction that allows to save time by wrinting:

  #execute{SELECT COUNT(*) FROM Cars INTO count};
	  
instead of:
  #execute[Main.getDatabase().getFreeConnection()] {
    SELECT COUNT(*) FROM Cars INTO count
  };
	  

Cursors

The cursor are the common way to get more than one row of data from the database. It's like ResultSet but it's typed:

SQL SELECT INTO Statement

The only SQL statement in XKJC is the #execute that allow to fetch data from the database with a ``SELECT INTO''. examples:

  1. #execute {
       SELECT String name, Image image, BigDecimal speed 
       FROM   Cars
       WHERE  ID = 1 
       INTO   theName, theImage, theSpeed
     };
	    
 2. #execute {
      SELECT String name 
      FROM   Cars 
      WHERE  ID =:id 
      INTO   names[id]
    };
   
 3. #execute[conn] {
      SELECT COUNT(*) 
      FROM Cars 
      INTO count
    };
	  
The last example use an explicit connection while the others use an implicit connection (ie, the context should inherit from DBContextHandler and its default connection will be used).

SQL Expressions

SQL expression returns an int value that correspond to the number of row modified by the expression. An expression can use a cursor to identifie a row of the database (WHERE CURRENT OF) with fully implemented JDBC drivers. examples:

  1. #update {
       UPDATE Cars 
       WHERE  ID =:id 
       SET    name = :(javaName + '-' + id)
     };
    
 2. #update(cursor) {
      UPDATE Cars 
      SET    name = :(javaName + '-' + id)
    };
	    
 3. #update [conn] { 
      DELETE FROM Cars 
      WHERE :id > 10
   };
	  
The last example use an explicit connection while the others use an implicit connection (ie, the context should inherit from DBContextHandler and its default connection will be used).

Transactions

Every SQL statements should be executed within transaction. This allows to reexcute statements interupted by deadlock (after asking the user if he wants to) or abort a whole transaction if something is wrong (like if a Java exception is thrown). The syntax is:

  #protected([``an optional message'']){
    ... 
    ... // a list of Java and SQL statements
    ...
  };
	  
If an exception is thrown during execution of this block, the current transaction is aborted, else it commited. A way to handle deadlock is provided.

Future improvements

The main thing that is missing here is a program that checks the definition of database types provided by the programmer against the database. This could be realized with the metadata subsystem of JDBC, but this is for a future version. There is also no way to create table or meta data in the database, since XKJC is intended only to DML SQL (Data Manipulation Language).


PrevHomeNext
XKJC eXtended kopi Java compilerUpVisual KOPI