Home

News: TSS Article: Back End Code Generation Techniques for Java

  1. In this article, Jack Herrington looks at what constitutes a high quality code generator. He compares code generation tools for both traditional and extreme programming approaches such as ModelJ and XDoclet, and gives a synopsis of various MDA generators such as AndroMDA, ArcStyler and OptimalJ. He also provides tips'n'tools on how to build custom generators.

    Read Back End Code Generation Techniques for Java

    Threaded Messages (45)

  2. code that gets information in and out of the database, what Sun likes to call plumbing, is interesting, but itÂ’s not why we got into this business.


    The above statement implies a lack of respect/knowledge for the full power of SQL and its role in a complex enterprise app.

    Although I "love" code generators, and have used them extensively on DB projects, the real problem is not the easy 80% CRUD operations, but the real complex SQL queries using group by, having, etc. that resist any attempt at automation. It is this 20% that will trip up any code generator or O/R mapper.

    The argument should not be whether to generate or not, but rather, how do we cleanly integrate the generated mundane 80% and the custom 20%.

    Some quotes from a very good OTN article "Designing Scehmas":
      http://otn.oracle.com/oramag/oracle/04-jan/o14dev_trends.html

    1. database schema design as a vital part of creating any high-quality application.

    2. The fact is that a machine-generated schema simply can't match the careful design produced by a good data modeler

    3. The fact is that a machine-generated schema simply can't match the careful design produced by a good data modeler

    4. Generated schemas rarely make intelligent use of relational database features, and this can have a huge impact on performance.
  3. 2. The fact is that a machine-generated schema simply can't match the careful design produced by a good data modeler


    If computer generates some code it is not out of the blue sky.
    "careful design produced by a good data modeler" does not necessarily mean hand written DDL code. It could be ERWIN diagram, or hand writen hibernate mapping xml file. And DDL code, generated from these sources is the same quality as manually created DDL.
  4. There is almost always a need for custom code. If a system can be developed almost exclusively by a code generation system with reasonably descriptive input, I'd argue you are much better off. "careful design produced by a good data modeler" often ends up being something not as clever as the "good data modeler" intends it to be - or worse, when that clever code becomes a maintenance nightmare. None the less, there are important uses for custom code, so long as it is only used when necessary.
  5. Man against machine?[ Go to top ]

    Hmm, sounds like its Karpov against Big blue in chess!
  6. Integrating generated and custom code[ Go to top ]

    Not necessarily. However, the 80-20 rule is what drives the popularity of automatic code generators. The days of having to painstakingly write huge DDL files manually are numbered. But a skilled DBA can make optimizations and design decisions that augment autogenerated DDL.
  7. Jaxor uses code generation for persistence. (Although, you can still hand code your objects if you like.) Jaxor does not restrict your use of the database, so you are free to write optimized queries for special circumstances. Jaxor is not constrained to an Object Query Language that may limit your options.

    Mike
  8. Please do not forget Velocity when code generation is talked about.

    It's far better than XSLT for this purpose (easier and more readable syntax, better performance...).

    Mileta
  9. Please do not forget Velocity when code generation is talked about. It's far better than XSLT for this purpose (easier and more readable syntax, better performance...).

    The problem with Velocity and JSP is that they lack an inherent awareness of an (XML) input tree, and so they don't support recursive descent. MDA involves an XMI pipeline, and this begs XSLT or XSP.
  10. Please do not forget Velocity when code generation is talked about. It's far better than XSLT for this purpose (easier and more readable syntax, better performance...).

    >
    > The problem with Velocity and JSP is that they lack an inherent awareness of an (XML) input tree, and so they don't support recursive descent. MDA involves an XMI pipeline, and this begs XSLT or XSP.

    You might want to try FreeMarker, which does know about XML and supports recursive descent. It works well as an XSLT replacement.

    Chris
  11. The problem with Velocity and JSP is that they lack an inherent awareness of an (XML) input tree, and so they don't support recursive descent. MDA involves an XMI pipeline, and this begs XSLT or XSP.

    I want to retract what I said above. I reconsidered it last night, and I now believe that a template should be WYSIWYG, as with Velocity, JSP, etc. XSLT would be great, but only within the context of a WYSIWYG template, such as XSP. I convinced myself that the ergonomic benefit of WYSIWYG exceeds that of XSLT's XML input awareness.

    I also realized that recursive descent isn't suitable for XMI. XSLT is superior at processing an input tree with an arbitrarily recursive schema. But the non-graphical model portion of XMI isn't recursive. XMI's model structures lay out nicely into a WYSIWYG template.

    Well, now that I'm passed that intellectual dead end, I can get back to playing and inventing with my once again favorite MDA generator: AndroMDA. Though the question remains which template language is better: Velocity, JSP, or XSP? I'm also wondering how awesome Groovy scripted templating could be.

    I thought UMT-QVT would be a nifty generator. It appears well honed and offers dual access through either a Java API or XSLT. But it doesn't like the xmi.id's emitted by Poseidon. Of course a custom stylesheet could prepare the XMI, but why is UMT so tempermental?

    Of course the best way to generate code is not to. When can we have an open source UML (or XMI) interpreter, so that we don't need to buy a commercial one?
  12. Whoa, sorry I replied before reading your own reply to your original message. I think you put my feelings about MDA templates best. They should be WYSIWYG, and things like JSP and Velocity seem to work best (to me). I'm sure freemarker would be nice, as well. Personally, I think Velocity is the best at the moment because it seems to do the best job of not obscuring the content of the template. The basic syntax, with #if/#end blocks, seems (IMHO) to do the best job of staying out of the way; <if></if> tags seem overly verbose, and overly verbose means getting in the way and making templates harder to read. Also, you can't do scripting in Velocity, so you're forced to use helper classes to perform sophisticated operations. While it would be nice to be able to do these inline with the template, they would also obscure the template content. It's the same reasoning behind preferring Velocity as an MVC front-end. You keep a clear separation of content from logic. Though there are times when a _little_ scripting would be nice.
  13. Open source XMI parser[ Go to top ]

    <BrianMiller>
    Of course the best way to generate code is not to. When can we have an open source UML (or XMI) interpreter, so that we don't need to buy a commercial one?
    </BrianMiller>

    We have a standard, JMI, for parsing XMI documents into a Java object model. So far, there are two implementations; both are open source.
  14. Wrong, MDA requires a representation of a model. XMI happens to be one representation of that model, which is used not because it is the easiest to work with representation available, but because it is an agreed-upon standard. MDA _may_ use an XMI pipeline, but there is nothing about MDA intrinsically that requires the use of XMI. I would argue (strongly) that an MDA tool should have an object representation of a model to work with, to allow for things far more sophisticated (and easy to write and maintain) than what can be achieved with XSLT. In fact, if I'm not mistaken, MDA best practices require the use of an intermediary model of some sort.

    JSP and velocity may not natively support recursive descent, but for most of the generation done as part of MDA, that's only a small part of the game. Your mda generation tool can use an object representation of the model along with utility transformation classes to perform some pretty sophisticated things that are difficult to do in XSLT, and that aren't easy to understand. Consider the following example:

    public class ${class.name} extends AbstractModelObject
    implements
    #foreach ($dep in $class.id.clientDependency)
    #set ($interface = ${dep.getSupplier().iterator().next()})
    ${transform.findFullyQualifiedName($interface)},
    #end
    I${class.name},
    Cloneable,
    Serializable
    {
    ... (code for class)
    }

    That's a pretty common real-world use of MDA for generating Java model classes, and it's pretty easy to read. This is from an example working with AndroMDA. I'm not sure that the equivalent in XSLT would be as easy to understand, write, or maintain. There are a great many other manipulations of a model that can be done using this approach that I'm sure would send XSLT in a tailspin and cause the brain of anyone trying to read the resultant XSLT templates to bleed.
  15. I've been using code generation pretty extensively for several projects over the past year or so, and it has been a great help. Obviously, it can't do everything. My main judgment of a code generation framework is how it allows you to deal with the exceptions. I don't think that most tools themselves can provide the full framework that allows for the best combination of automation and customization. I think that the developer has to work with the tool to identify best practices and organizational patterns that really make generation a help and not a hindrance.

    Also, in continuing with my history of slagging XSLT, I think that it is ABHORRENT for use in code generation. I've been using velocity with AndroMDA for a while and find it works pretty well, especially with velocity-aware syntax highlighting. I've worked with JSP-style generator template languages and they work pretty well, too, though I think that they introduce a lot more complexity than velocity (compare, for example, if/then constructs in each language; the relative terseness of if blocks in velocity is much better suited to writing a template than the verbose use of tags in JSP-like languages). But I would never dream of using XSLT, despite what people say about it. It is far too complex for dealing with the relatively simple task of inserting information into a template. More importantly, it is far too difficult to use it with custom functions, many of which are necessary for manipulating a model (e.g., converting lower case to upper-case or underscore-case, or iterating through the interfaces that a class is dependent on to use them in "implements" blocks).

    Just my 2 cents.
  16. Slightly tangential to the article but:

    I wish Java had a preprocessor. I miss that from C/C++. A lot of code is written unnecessarily (which increases the liklihood of bugs).

    Consider,

    void f(SomeObject o) thows IllegalArgumentException {
    if{o == null) {
     throw new IllegalArgumentException(SomeObject.class.getName() + " cannot be null.....");
    }

    etc.
    }

    as opposed to
    void f(SomeObject o) thows IllegalArgumentException {
    CHECK_FOR_NULL_ARG(o, "some message")

    etc
    }

    Times untold scores of methods and arguments.

    I can think of several other time savers and bug reducers.

    We all have our dreams.
  17. Slightly tangential to the article but:

    >
    > I wish Java had a preprocessor. I miss that from C/C++. A lot of code is written unnecessarily (which increases the liklihood of bugs).
    >

    There may be valid arguments for MDA-style code generation "in the large", especially when trying to glue together different langauges/platforms, e.g. avoiding repetition between Javabeans and DB schemas. However, preprocessor-style code generation "in the small", when you're dealing with a small piece of code in one language, seems dicier.

    Preprocessors suffer from side effects, like the typical C MAX macro example. You see an expression once, but the macro includes the expression several times. If the expression has side effects (e.g. x++, callFunction()), you have caused them to run several times over when they were probably meant to run once.

    Repetitive code often cries out for some refactoring. In the exception example, a simple step would be to create a method if you really wanted to check for nulls:
     
    void failOnNullArgument(Object possiblyNullArgument) throws IllegalArgumentException {

        if (possiblyNullArgument==null) {
            throw new IllegalArgumentException("null argument was passed");
        }

    }

    I realise that's just one example --- these things needs to be considered on a case-by-case basis. In a more general sense, aspect-oriented frameworks allow a more flexible and robust kind of code generation than preprocessors.
  18. Repetitive code often cries out for some refactoring. In the exception example, a simple step would be to create a method if you really wanted to check for nulls:

    >  
    > void failOnNullArgument(Object possiblyNullArgument) throws IllegalArgumentException {
    >
    >     if (possiblyNullArgument==null) {
    >         throw new IllegalArgumentException("null argument was passed");
    >     }
    >
    > }
    >
    > I realise that's just one example --- these things needs to be considered on a case-by-case basis.

    What is your answer to this case:

    try{
       Database.beginTransaction();

       // code that imlements transaction

       Database.commitTransaction();

    }
    catch(OptimisticLockException e){
       Database.rollbackTransaction();
       return mapping.findForward("optimisticLOCK");
    }
    catch(DeadlockException e){
       Database.rollbackTransaction();
       return mapping.findForward("deadLOCK");
    }
    catch(NotUniqueException e){
       Database.rollbackTransaction();
       errors.add("order",new ActionError("errors.codeNotUnique"));
    }
    catch(ParentKeyNotFoundException e){
       Database.rollbackTransaction();
       errors.add("order",new ActionError("errors.parentKeyNotFound"));
    }
    catch(Exception e){
       Database.rollbackTransaction();
       LOG.error("Unexpected exception",e);
       throw new ServletException(e);
    }



    I whant to be able to define macro myServletActionTransaction:

    myServletActionTransaction("order") {

     // code that imlements transaction

    }

    Nebojsa
  19. try this:

    protected abstract ActionForward doPerform ... ;

    public final void ActionForward perform ...
    {

    try{
       Database.beginTransaction();

        doPerform(request,response);

       Database.commitTransaction();

    }
    catch(OptimisticLockException e){
       Database.rollbackTransaction();
       return mapping.findForward("optimisticLOCK");
    }
    catch(DeadlockException e){
       Database.rollbackTransaction();
       return mapping.findForward("deadLOCK");
    }
    catch(NotUniqueException e){
       Database.rollbackTransaction();
       errors.add("order",new ActionError("errors.codeNotUnique"));
    }
    catch(ParentKeyNotFoundException e){
       Database.rollbackTransaction();
       errors.add("order",new ActionError("errors.parentKeyNotFound"));
    }
    catch(Exception e){
       Database.rollbackTransaction();
       LOG.error("Unexpected exception",e);
       throw new ServletException(e);
    }
    }
  20. try this:

    >
    > protected abstract ActionForward doPerform ... ;
    >
    > public final void ActionForward perform ...
    > {
    > ...

    Try to write how to use your code:

    ActionForward f=(new MyServletActionTransaction() {
        ActionForward doPerform() {
              // code that imlements transaction
        }
    }).perform();
    if(f!=null)
       return f;


    steel mach more compicated then:

    myServletActionTransaction {
      // code that imlements transaction
    }

    Nebojsa
  21. Sorry, I see it was not clear. I use it this way:

    public class MyAction extends TransactionalAction{

       protected ActionForward doPerform( ...
        {
          
           // code that imlements transaction
     
          
        }


    }

    Struts calls "perform", this method is the same for all transactional actons and it is implemented in base class.
    "perform" calls "doPerform" this method is specific for use case, but it is wothout duplicated code.
    It is very trivial to refactor, declare metods like "perform" as "final" and "doPerform" as "abstract", comiler helps to refactor.

    It is mutch better than macro.
    I have wrote a lot of plain C code a few years ago and I found macro is not the best way to reduce code dublication in C too. It was used for performance to inline code (workaround for "old" compilers).
    There is no problems to use C preprocesor for any language, some C compilers do not have it and use external preprocesor too, but I am sure it will not optimize struts actions.
  22. Sorry, I see it was not clear. I use it this way:

    >
    > public class MyAction extends TransactionalAction{
    >    protected ActionForward doPerform( ...
    >  

    But this is not replacement form the fragment of code I have mentioned. You can see missing return at the end of the fragment, so there is some code before and after transaction.

    Then, some my actions will extend TransactionalAction, and some other will not.
    If this is OK, then it is OK that I already have MyApstractAction1,
    MyApstractAction2, etc. Witch class TransactionalAction will extend
    in this case?

    > It is mutch better than macro.
    > I have wrote a lot of plain C code ...

    C macros ARE bad. Take a look on

    http://www.artima.com/weblogs/viewpost.jsp?thread=5246

    Gilad Bracha, the resident Computational Theologist at Sun wrote:

    "Seriously, some formulations of macros are well structured enough to prevent the onerous kinds of abuse that have given macros a dubious reputation in the C culture.Nevertheless, we don't plan on adding a macro facility to Java any time soon. A major objection is that we do not want to encourage the development of a wide variety of user-defined macros as part of the Java culture."

    Macros are general synax extending solution, but in the case we are talking about, we just need cosures in Java:

    http://fishbowl.pastiche.org/2003/05/16/closures_and_java_a_tutorial


    Nebojsa
  23. Macros are general synax extending solution, but in the case we are talking about, we just need cosures in Java:

    >

     I agree closures or lambda is a useful language feature, It can be useful for
    use case like iteration, it is more clear than inner classes.
    For programmic transaction demarcation you can live without unnamed lambda functions or java style inner classes.
     Sping framework users use unnamed classes,
    but I do not think it is a good way too.
     I use "BaseAction" to demarcate transactions in struts applications without any problems and ugly inner classes.
     Probably my example was not clear and buggy, but it is very trivial, it is just a delegation (action doe's a dirty job and delegates to itself)

    servlet.service() ->
                 action.perform() ->
                               this.doPerform()
     
    "perform" and "doPerform" methods have the same parameter types and return type.
    I thin it is more clear than unnamed functions for this use case.
    It was not a good example for lambda usage, it is more useful for resultset
     processing and resource cleanup:

    execute(sql){
        // process resultset
    }

    but it is not a problem to use java way for this use case too.




    > Nebojsa
  24. Transaction management[ Go to top ]

    <juozas>Spring framework users use unnamed classes,
    but I do not think it is a good way too.
    I use "BaseAction" to demarcate transactions in struts applications without any problems and ugly inner classes.
    </juozas>
    Inner class usage is only with the Spring TransactionTemplate mechanism for programmatic transaction management. (They don't have to be anonymous either.) Spring also offers declarative tx mgt.

    If you want to get the transaction management code out of your object model (usually a good idea), Spring lets you do declarative transaction management on any POJO. IMHO this is much better than extending a superclass like your Struts action. It doesn't mess with the inheritance hierarchy of the POJOs, you only have to change configuration, not Java code to use a different underlying tx infrastructure (Spring supports JTA, JDBC, JDO, Hibernate, iBATIS transactions), and it's easy to unit test: no dependence on a transactional superclass.

    I generally prefer to do transaction management in the business object layer, not the MVC layer. Do you do this in the web tier because you need to keep a session open for Hibernate or the like?

    Regards,
    Rod
  25. Transaction management[ Go to top ]

    If you want to get the transaction management code out of your object model (usually a good idea), Spring lets you do declarative transaction management on any POJO. IMHO this is much better than extending a superclass like your Struts action. It doesn't mess with the inheritance hierarchy of the POJOs, you only have to change configuration, not Java code to use a different underlying tx infrastructure (Spring supports JTA, JDBC, JDO, Hibernate, iBATIS transactions), and it's easy to unit test: no dependence on a transactional superclass.

    >
    Yes, I know it. I do not need this kind of features in practice, but it is very trivial to refactor and to use the same TransactionTemplate in base class (call "doPerform" in template) and to reuse spring features too.


    > I generally prefer to do transaction management in the business object layer, not the MVC layer. Do you do this in the web tier because you need to keep a session open for Hibernate or the like?
    >

    I prefer to demercate transactions in the "controler", it makes business object layer more reusable. I think about transaction more as "atomic" use case than persitence, data or object model aspect (the same model can have a lot of use cases).

    > Regards,
    > Rod
  26. Transaction management[ Go to top ]

    I prefer to demercate transactions in the "controler", it makes business object layer more reusable.
    Reusability is why I usually like to externalize transactionality from the middle tier objects themselves where possible and apply it using something like the Spring TransactionProxyFactoryBean. This way (like your way) the business objects don't have any transaction management code, but the business layer (once transaction advice is applied) is complete in itself. For example, it's possible to expose a web service over a business object knowing that the transactionality is already taken care of for all cases. I think it's a bit misleading to have say an addUser() method on a business object accessible by the web tier and for that method to do nothing unless the caller calls it in a transaction.

    One of the things that I like about EJB is that way in which it keeps transactionality out of Java code and in the business layer. I think that's worked well in a lot of applications. Hence we offer the same in Spring, although it's nicer IMHO.

    I guess it depends on what your usage scenarios are. If you call the addUser() method in many different scenarios that are transactionally different it may make sense to pull the transactionality out into the callers.

    Spring declarative transaction management, like EJB CMT, will respect transaction propagation, so callers can always provide their own transaction if they want.

    Regards,
    Rod
  27. Transaction management[ Go to top ]

    One of the things that I like about EJB is that way in which it keeps transactionality out of Java code and in the business layer. I think that's worked well in a lot of applications. Hence we offer the same in Spring, although it's nicer IMHO.

    >
    I think transaction management implementation (XA) is the most usefull part of EJB, but transaction demarcation is a very trivial thing and I am not going to pay something for it. It is possible to use framework for transaction demarcation, but most of my applications are very trivial in practice, transaction per http request or JMS message.
    Filter can be used to demarcate transactions in web application too.
    Transaction per few requests is more complicated thing, but it is not a very big problem in practice too,
    most of PHP + MySQL applications work without transactions and I do not think all JSP + EJB + "Market Leader" applications are better.
  28. Assert[ Go to top ]

    1.4.x has this facility to check preconditions:
    assert boolexp1:exp;
  29. Assert[ Go to top ]

    1.4.x has this facility to check preconditions:

    > assert boolexp1:exp;

    This can be a valid strategy, even if not officially sanctioned. Given that assertions are most often used for argument checking, many developers reasonably assume Java's assert is designed for just that. Unfortunately, such use is explicitly ruled out by the official spec - because assertions may be switched off and the exception type AssertionError will not reflect the problem.

    This leads to bloated methods cluttered with ceremonial "if (opposite of expected) { throw ..}" blocks before the core code. A simple way to deal with preconditions is to do something similar to assert --- use an assertion library like JUnit's Assert class.
  30. "Consider, ... CHECK_FOR_NULL_ARG(0, "some message")"

    Scary! It reminds me of those endless hours searching for strange bugs back in the '80s. After a few hours you realise than someone had passed something into a macro (as above) and it had been expended into something completely different from was was originally intended. Can anyone see anything wrong with the above code (scroll down to see the answer).

    Your posting highlights EXACTLY why macros are dangerous:-

    "if{o == null) {"

    It wouldn't have worked anyway and you'd spent ages looking for the source of the problem because the damn thing's been expanded.

    Anyway, what's wrong with "assert"?

    "I can think of several other time savers and bug reducers."
    Please just keep your thoughts to yourself and save us all time. :-)

    "We all have our dreams."
    I think your dream is my nightmare. :-)

    -John-






    Answer to my question: I've passed a "0" instead of a "o", you will then end up with if( 0 == null ) assuming you correct the other problem first.
  31. Sorry for the bad English, "..realise than someone..." should be "... realise that...", the "from was was originally" should of course be "from what was..." and "spent" should be "spend".

    Something to do with the beer I drunk quite recently.

    -John-
  32. Umm. if( 0 == null ) won't compile. What's the problem?

    "Anyway, what's wrong with "assert"?

    Assert is not meant to be used in production builds. My example is for
    production code.

    What about assert(0 == null) same probelem, n'est pas?

    Go back to sleep.
  33. Umm. if( 0 == null ) won't compile. What's the problem?

    It was an example, there are many things that will compile and you'll spend ages looking for them when they go wrong. A lot was learnt from decades of C and C++, that's why macros were not put into Java. I used them quite a bit in C and C++ in the old days but they definately won't get my vote for Java.

    Assert is not meant to be used in production builds. My example is for
    production code.


    I totally agree but given the choice of asserts and macros...

    Last email on this subject, it's getting boring.
  34. I wish Java had a preprocessor. I miss that from C/C++. A lot of code is written unnecessarily (which increases the liklihood of bugs).

    [...]
    > I can think of several other time savers and bug reducers.
    >
    > We all have our dreams.
    Your dream of a Java preprocessor might soon become true, if:
    - you generally use a text editor to write code;
    - your concept of "source code" is flexible;
    - you prefer to type shortcuts like 1 and 2 to generate code fragments like href="1http://somusar.com/doc/code_gallery/java/tjpp/core/exc/SampleException1.java.txt">1> and 2
    - you are willing to share your thoughts about time savers and bug reducers: these could be turned into preprocessor directives or macros in virtually no time.
  35. Fix typo in my previous posting:
    - you prefer to type shortcuts like 1 and 2 to generate code fragments like 1 and 2
  36. I think this way : If it is possible to draw code, it is possible to execute it too without converting it to java or C++ source code before to convert to machine code. Source code generation is a workaround for tool limitations.
    With text editor you have single step and single source to maintain, so I think text editor is better tool than Mouse Oriented Programming tools ( more productive ).
  37. AOP simmilarities[ Go to top ]

    Hi.
    How do you think? How simmilar AOP and MDA?
    As far as I understood MDA is to replace some constructions (UML, code templates, etc) with another, more verbal (code). Then AOP is addition or replacements (arround advice) of join points with advices (at the end it's just a code).
  38. AOP simmilarities[ Go to top ]

    It is possible to use plain JAVA for all *practical* use cases, it sometimes
    becomes noisy like OOP in plain C, but I try to find better ways to write code
    with JAVA before to use experiments.
  39. They have simmilarities but AOP lacks UML representation, we are going from language to modelling like we did in 80's with OO (from OOP to OOD).

    Nowadays AOP is used to help to organize products totally messed up with tangling concerns and tangling code. So AOP is a good tool to do a partial refactoring and to do customizations that extend the component with properties not declared in the UML model. To build new projects people will prefer MDA (IMHO).

    With a good UML representation for AOP we will be able to generate AOP code from UML diagrams (MDA).
  40. They have simmilarities but AOP lacks UML representation, we are going from language to modelling like we did in 80's with OO (from OOP to OOD).


    Hmmm.. Isn't just MDA a way to drive AOP _or_ OOP by working more in a model than in code. To me, they are completely independent of each other. AOP is about being able to express and apply modular crosscutting concerns. This could be done only in pure code if needed, without any modelling.

    > Nowadays AOP is used to help to organize products totally messed up with tangling concerns and tangling code. So AOP is a good tool to do a partial refactoring and to do customizations that extend the component with properties not declared in the UML model. To build new projects people will prefer MDA (IMHO).

    If you do a new project, you could do OOP for your simple components, and AOP for applying your crosscutting aspects; like time-awareness, versionability, transaction handling, logging, design by contract etc. MDA can't achieve both OOP/AOP today (AFAIK), so you could use it for your OOP part, and handle the aspects in code.
     
    > With a good UML representation for AOP we will be able to generate AOP code from UML diagrams (MDA).

    Yep. There has been some work on that, but so far it looks a bit like hacks on basic UML. There should be a better way...

    The thing about MDA is that there (IMO) has to be intelligent support for customizing the code generation templates; not only on a global level, but sometimes per component.
  41. AOP with standarts[ Go to top ]

    crosscutting aspects; like time-awareness, versionability, transaction handling, logging, design by contract etc.


    AOP look like a toy to a lot of people. AOP it's fun but you don't use in your day by day.
    We have good references to AOP like JBoss, IBM but without a standart is very difficult to convince people from the importance of AOP.

    We need a JCP work in this area the standart Java way to do AOP will put us in a new level.

    Off-topic: Is design by contract a crosscuting concern?
  42. Hi,

    I would like to mention JAG (Java Application Generator) http://jag.sourceforge.net here that can be used as both a code and model generator. I like to call JAG a lightweight MDA generator.
    It uses both Xdoclet and Velocity for codegeneration and UML/XMI for the model.
    You can reverse engineer een existing DB schema from which an UML model can be created. The UML model can be used the generate Java code using Velocity template which can generated the CRUD operation, Container Managed Relations for Foreign Key relation, but also input validations using Struts 1.1 Validations.

    Cheers,

    Rudie Ekkelenkamp
    Finalist IT group.
  43. I'm all for automatic code generation. Anything that means I don't have to write basically the same code for 60% of my career gets double plus good thumbs up.
    The only problem I have with the big solutions so far (such as XDE) is that they tend to require so much work to use you end up spending plenty of time defining your set of rules. Then the rules have to change and your back to square one.

    At the moment I'm using Firestorm from Code Futures, which is dream to use for creating DAO code. Point it at a database, click a button and you got DAOs and a Framework to use them, which can be EJB or not for those who believe that many (not all) of modern web apps can happily live in two Java tiers. (I'm one of those). Database change? No problem, just recreate the code and slot in in behind your hand written stuff. The url is www.codefutures.com
  44. If I take a look to the MDA commited products, i see two major generation products (for me ;-) called Codagen Architect from Codagen and MIA Generation from Sodifrance which exists since more than 3 years and are not even referenced in this article.

    I use MIA Generation for more than 4 years now and i invite you to take a look to this product.

    The strength of such products is that :

    - YOU choose your OWN rules concerning the way you use UML,
    - YOU choose your OWN rules concerning the architecture of your code based on the framework you have choosen,

    Then, and only then, you tell your generation tool the rules to automatically produce your code from your model and these tools fit that very well.

    So that changing the framework doesn't impose you to change the way you use UML and you really have an plateform independant model.


    Richard Lemesle,
    Senior Architect, Ackermann Consulting.
  45. Larger implications of this trend[ Go to top ]

    I see a lot of value in codegen used in the right place, and I have certainly used it myself in the past, but as I read this article, I can't help wondering if it points to an underlying deficiency in the Java language. If there is such a proliferation of tools out there for generating code, doesn't it suggest that Java may not be aimed at the appropriate level of abstraction for the systems these people are developing?

    For example, code generation is often used to automate repetitive code that is almost the same from class to class but not quite. I have done this in the past but it has always left me with the vague feeling that I didn't do a very good job designing the code in the first place to avoid the need for repetition.

    And I have a hard time seeing MDA in the same category as generic code generation tools like XSLT or whatever. To see MDA as mere code generation misses the point entirely, IMHO.

    Finally, why no mention of CGLIB? To me, inline bytecode generation is the most useful form of code generation. Those of us who came from the Lisp world were used to doing this from day one and it was one of the things I have missed the most in Java.
  46. DAO Code Generation[ Go to top ]

    CodeFutures produce code generator for generating data access code.