Welcome to jMDA

To generate software automatically has been a strong ambition since the early days of software development.

jMDA is a new approach in this area. It streamlines proven, widely known and accepted open source technologies into a most comprehensible and easy to use set of Java libraries that are extremely powerful and flexible at the same time. The main purpose of jMDA is

  • to leverage a comprehensible and easy to use modelling environment,

  • to provide convenient and complete access to modelling information and

  • to make available easy to use software generator facilities.

The introduction will briefly explain the main drivers behind this project, the jMDA book provides more detailed information about the most important concepts and the open source software is available here.

Avoid unnecessary qualified types in generated Java code

A common problem with many Java code generators is to avoid unnecessary qualified names in the generated output. A typical output for field declarations with unnecessary qualified type names looks like this:


  java.lang.String string;
  java.util.Date date1;
  java.sql.Date date2;


Two of these three qualified names are not necessary if there are appropriate import statements. This seems to be of no importance if you look at just these three lines of code. However unnecessary qualified names are annoying if you have plenty of them in your source code. They make code less readable and complicate code maintainability.

With jMDA it is easy to avoid unnecessary qualified names. jmda.gen contains a class called ImportManager helps to identify which type names have to be qualified and which ones can be imported and used with their simple names. ImportManager objects are always related to a particular package. Usually that package is the target for the code that a generator produces. This way it is easy for ImportManager to find out if the generated code uses other types from the target package. If so these types don't need qualified names.

jMDA generators like DefaultClassGenerator for example automatically produce correct import statements if you use ImportManager. The following code fragment illustrates how to use ImportManager:


    ImportManager importManager =
        ImportManagerProvider.demandImportManager("some.target.package");
    
    String type     = importManager.useType("some.target.package.Type");
    String utilDate = importManager.useType(java.util.Date.class);
    String sqlDate  = importManager.useType(java.sql.Date.class);
    String string   = importManager.useType(String.class);

    System.out.println(
        "import statements:\n" + importManager.generateImportStatements());

    System.out.println("type     [" + type     + "]");
    System.out.println("utilDate [" + utilDate + "]");
    System.out.println("sqlDate  [" + sqlDate  + "]");
    System.out.println("string   [" + string   + "]");


The above code produces the following output:

    import statements:
    import java.util.Date;

    type     [Type]
    utilDate [Date]
    sqlDate  [java.sql.Date]
    string   [String]


As you can see ImportManager generated just one import statement which is correct because all other used types are either from "some.target.package" or from "java.lang". Types from both packages can be used with their simple names without explicit import statements.

ImportManager also recognizes that sqlDate needs to be used with its qualified type name. This is because utilDate already uses java.util.Date and has a respective import statement. An additional java.sql.Date import statement would collide with java.util.Date and the compiler will refuse occurances of both import statements in the same compilation unit.

No comments:

Post a Comment