Full list of in-depth articles - Feedback and questions - Request demo -

1 - Public demo of J2EE generator at Java Conference 2004

A SoProMach-based J2EE generator has been successfully introduced and demonstrated at the Italian Java Conference 2004 held in Milan on June 8, 2004.

The public demo was presented in session "Platform and Tools for IT Architects" during a 30-minutes speech held by Somusar's Co-Founder and CEO, Francesco Aliverti-Piuri. Title of the speech was "Prevenire difetti mediante generatori di codice: un caso di studio J2EE 1.4" ("Bug prevention using code generators: a J2EE 1.4 case study").

The demo showed how SoProMach allows to easily extend business entities in a textual component-oriented model, and rapidly re-generate high-quality (blueprint-level) application code, producing several consistent source code changes scattered across different files.

2 - Presentation contents

The presentation slides in Italian are available as PDF on the session page of the Java Conference 2004 site. A translation to English is available here (jconf04-eng.pdf, 337453 bytes).

2.1 - State of current code generation

The presentation opened with a quick introduction to the main concept of code generation and related recent news, most notably two books on code generation (Jack Herrington's "Code Generation in Action" and Kathleen Dollard's "Code Generation in Microsoft .NET"), followed by a very short discussion of OMG's Model-driven Architecture.

2.2 - Case study: generating parts of the Java Adventure Builder Demo

The presentation introduced Somusar's SoProMach code generation system and the related Generator Building[sm] service, that delivers efficient custom code generators to replicate the skills and expertise of experienced developers (as a "skill recorder" would do).

A significant case study followed, discussing the most recent blueprint application for the J2EE 1.4 platform from Sun Microsystems, an application called "Java Adventure Builder Demo" (JABD).

The JABD application provides a rich set of practical examples and guidelines on how to use the features available in version 1.4 of the J2EE platform.

From a code generation point of view, this application allows to show how several parts of comparatively repetitive source code files can automatically get built starting from a combination of declarative component descriptions (entity files) and procedural code-generation templates (software molds). In the JABD case, this concept applies to Data Access Objects (DAOs), Plain Old Java Objects (POJOs), and to the SQL script used to create the database schema.

Even more interestingly, the machine-made source code allowed to discover some harmless and self-neutralizing bugs in the original hand-writtem application code, as described in a related article published on O'Reilly Network. These bugs have now been fixed in version 1.0.1 of the Java Adventure Builder Reference application.

3 - Live Demo

The 15-minutes demo went through the following steps:

• Overview of generatable code (DAO, POJO, SQL);

• Short description of two entity files ("account.ef" and "contact_information.ef"), showing the multitier structure of the component-oriented declarative language called Sisendel;

• Overview of the POJO generation mold (see picture below): a software mold is a set of templates, grouped in a well-defined structure (header, generatable blocks, trailer). The templates are written in a special code-generation-oriented language, Tefigel;

|
| This file copyright (c) 2004 SO.MUS.AR. s.a.s.
| Subject to the license published at
|    http://www.somusar.com/contact/poc_request
|

contact_information "Contact information"

|
| This entity features a logic-tier class.
|
string 	e_mail[80] 		"E-mail"
string 	given_name[80] 		"Given name"
string 	family_name[80]		"Family name"
address address			"Address"
string 	cellphone[80]		"Cell. phone"
string 	telephone[80]		"Telephone"

--- DEFS ------------------------------------------------------------------
| No particular definitions required for this entity

--- DB --------------------------------------------------------------------
|
| Define the field set for the database tables that embed
| this entity, and define its primary key.
|
table:
   e_mail, given_name, family_name, address, cellphone, telephone

pkey:
   e_mail

|
| Define the list of fields to be returned by a select query
|
query:
   e_mail, given_name, family_name, address, cellphone, telephone

--- LOGIC -----------------------------------------------------------------
|
| Define the list of properties for the logic tier class
|
properties:
   e_mail, given_name, family_name, address, cellphone, telephone

|
| For some reason the sequence of parameters in the constructor
| is required to be different than the list of properties:
| hence override the default constructor sequence with an
| ad-hoc sequence.
|
constructor:
   family_name, given_name, cellphone, telephone, e_mail, address

--- UI --------------------------------------------------------------------
| No usage interface for this entity, yet

--- ADJUST ----------------------------------------------------------------
| Do not generate any SQL "create table" for this entity.
DB.make_table = "false"

| For some reason, some field names are renamed in the realm of the database
DB.column_map = \
     "email=e_mail;first_name=given_name;last_name=family_name;phone=telephone"

| Override default "protected" attribute for the class members
LOGIC.properties.private = "true"

---------------------------------------------------------------------------
diff -r poc_demo/j2ee/project/DB/db_schema.sql
               /tmp/prev_j2ee/DB/db_schema.sql
---------------------------------------------------------------------------

128d127
< cellphone varchar(80) not null,

---------------------------------------------------------------------------
diff -r poc_demo/j2ee/project/customer/LOGIC/ContactInformation.java
               /tmp/prev_j2ee/customer/LOGIC/ContactInformation.java
---------------------------------------------------------------------------

55d54
< private String cellphone;
63d61
<         String cellphone,
73d70
<     this.cellphone = cellphone;
93,96d89
< public String getCellphone() {
<     return cellphone;
< }
< 
107d99
<                 "cellphone="             + cellphone              + ", " +

---------------------------------------------------------------------------
diff -r poc_demo/j2ee/project/customer/LOGIC/PointbaseAccountDAO.java
               /tmp/prev_j2ee/customer/LOGIC/PointbaseAccountDAO.java
---------------------------------------------------------------------------

79c79
<         "cellphone, phone)" +
---
>         "phone)" +
81c81
<         "(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)";
---
>         "(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)";
92c92
<         "cellphone, phone" +
---
>         "phone" +
159,160c159
<         stmt.setString(11,    contactInformation.getCellphone().trim()  );
<         stmt.setString(12,    contactInformation.getTelephone().trim()  );
---
>         stmt.setString(11,    contactInformation.getTelephone().trim()  );
196d194
<         || (contactInformation.getCellphone()   == null)
269d266
<         String    cellphone   = result.getString(i++);
272c269
<                           familyName, givenName, cellphone, telephone, eMail, address);
---
>                           familyName, givenName, telephone, eMail, address);

This type of changes can easily lead to typing errors, resulting in unexpected behavior at run time, difficult to debug. For instance, forgetting to add the necessary question mark would not be detected at compile time, thus possibly leaving an incomplete assignment when moving data between tiers.

4 - Try it yourself

For a free trial package of this J2EE generator please read the proof-of-concept description, then download the package.

5 - Conclusion

The SoProMach demo provided the audience with a concrete example of model-driven code generation, featuring the following benefits:

• Quality: the generated code helped find bugs in the original hand-written code;

• Consistency: the second generator run resulted in consistent changes across several Java files and one SQL file;

• Productivity: the two generator runs required about 15 seconds each on a comparatively slow notebook, delivering about 2,000 lines of code per run;

• Abstraction: extending the model of entity "Contact Information" was performed in a technology-independent fashion, regardless of the target language and platform for the application.