Discussions

News: TSS Article: Does Code Generation matter to Java Developers?

  1. Norman Richards looks at the benefits of code generation in terms of reusability and as a high level language, and describes a real world project that migrated a large business model from hand coded business objects to business objects generated from a UML model.

    Read Does Code Generation matter to Java Developers?

    Threaded Messages (84)

  2. JSR-175 + AOP i[ Go to top ]

    I don't like code generation because it hides a lot details from the user. It is also very easy to grow beyond what a code generator can offer. From a vendor perspective it is also harder to add features when you're dependent on a compiler.

    The author mentions AOP and I think this is the better direction to head in for many many cases. (at least most of the XDoclet cases). This is where I like the marriage of JSR-175 metatags and AOP. JDK 1.5 metadata gives you the ability to define tags that are compiler checked. Add AOP as a consumer and you can easily add behaviors to your application and yet as a vendor, you have these behaviors encapsulated as objects. We're taking this approach with a few of the aspects we're shipping with JBoss AOP (transactions, security, and asynchronous communication).

    Bill
  3. AOP[ Go to top ]

    I don't like code generation because it hides a lot details from the user.
    AOP hides them much deeper!
    It is also very easy to grow beyond what a code generator can offer.
    True, but code generation serve very well in many cases and does not cause many problems (near zero with XDoclet) till we have to have develop-compile-deploy cycle.
  4. AOP[ Go to top ]

    I don't like code generation because it hides a lot details from the user.
    AOP hides them much deeper!
    It is also very easy to grow beyond what a code generator can offer.
    True, but code generation serve very well in many cases and does not cause many problems (near zero with XDoclet) till we have to have develop-compile-deploy cycle.
    Totally agree - while tags in the EJB class clearly indicate that XDoclet will generate "the rest" (which add no new functionality at all), I personally find AOP completely opaque - the class code does not give away what magic might be performed though AOP on entering and leaving methods.
  5. JSR-175 + AOP i[ Go to top ]

    It is also very easy to grow beyond what a code generator can offer.
    This depends on the code generation approach taken. If you control the source to the code generator then you can grow the code generator with your requirements. This often saves time over hand-coding, especially if the requirements change in a way that would require you to revisit hundreds of classes e.g. a change in persistence tier or web framework.

    The approach we took when designing the FireStorm/DAO code generation product was to implement the code generation framework using Java code rather than using a template file-based approach (which can run into limitations quite quickly).
    This is where I like the marriage of JSR-175 metatags and AOP.
    I think JSR-175 does open up some interesting possibilities for code generation but only where the input is Java code. Code generation often uses some other model as an input (database schema, XML schema, or a proprietary markup to model the requirements).

    Andy Grove
    Code Futures, Ltd.
  6. code generator + AOP[ Go to top ]

    It is also very easy to grow beyond what a code generator can offer.
    This depends on the code generation approach taken. If you control the source to the code generator then you can grow the code generator with your requirements. This often saves time over hand-coding, especially if the requirements change in a way that would require you to revisit hundreds of classes e.g. a change in persistence tier or web framework.
    Yup. Agree fully. This is what I am doing with my own home grown code generator of more than 2 years. I also make sure the code that it generates are as good as my own hand coded codes, thus giving me with no problem understanding all those generated code. This is very important as I use AOP together with the generated codes a lot.
  7. perfect for specific tasks[ Go to top ]

    I've used Firstorm.

    Its much easier to generate a Data Access Object than hand coding it. Why would anybody prefer to spend weeks writing a DAO for say 50 database table rather than generate it in a few minutes?

    The key problem with MDA is that you generally can not customize the code generation to suit your exact requirements. Firestorm allows you to do that so that each time the code is generated its done how you want it.

    Firestorm is perfect for rapid prototyping - you just point at the database schema and generate the DAO.
  8. perfect for specific tasks[ Go to top ]

    The key problem with MDA is that you generally can not customize the code generation to suit your exact requirements.
    That's a myth. MDA tools allow the user to satisfy arbitrary requirements by creating new templates or modifying existing ones.
  9. isn't code generation everywhere ?[ Go to top ]

    Isn't an application server all about code-generation ? I thought it was generating quite a lot behind the scenes :-)
    I don't like code generation because it hides a lot details from the user.
    -- Wouter
  10. indeed[ Go to top ]

    while certainly an oversimplification, i view compilers as very smart code generators. to your point, the code supporting the "bilities" is generated by the given j2ee container.
  11. Code generators create code. That code then needs to be maintained. After a few round trips of generation, modification, reverse engineering discrepancies creep in. And gosh forbid you ever want to replace the code generator you were using with a different one.

    So no thank you to code generators.

    I'm all for functionality generators though. Something which adds functionality to your app without the 'code'. Declarative comments in Java code (e.g. XDoclets) and even the J2EE application descriptors reach towards this goal.

    - Peter
    RimuHosting - JBoss and Tomcat Hosting
  12. Code generators create code. That code then needs to be maintained. After a few round trips of generation, modification, reverse engineering discrepancies creep in.
    Only if you do it wrong. If you're going to go through the trouble for more than a one-way operation, you need to make a commitment to not overwrite customized code with generated code. There are many techniques that can help achieve this. You can, for example, generate your code as abstract classes, and deal with custom implementations, which may or may not override functionality from the generated classes. All of your customization goes in the concrete classes, and your generated classes are free to change implementations as your framework(s) get updated and fixed. Changes that break interfaces will be caught by the compiler.

    Code gen without a commitment to keep the generation alive is not a good idea. But then, doing boiler-plate code by hand, so you can't quickly deal with framework updates or improvements across the board, is just as bad. No thanks to a complete lack of code generation.
  13. Anybody for Feature Generators?[ Go to top ]

    Code generators create code. That code then needs to be maintained. After a few round trips of generation, modification, reverse engineering discrepancies creep in.
    Only if you do it wrong. No thanks to a complete lack of code generation.

    If you can get to delivering featores on a running app faster, if you can maintain it better, and if the generator just generates code, you needn't worry about "what happens if the generator gets hit by the bus".

    I find it silly that people worry about "what do we do when the code generator rusts out" when they never seem to care if the code they write is maintainable. Go figure.
  14. It's not a good idea to overwrite the codes that the code generator creates. Using a non intrusive way to add additional functionality such as using AOP is, IMHO, the way to go.
  15. AOP -- symptom or a cure?[ Go to top ]

    Speaking not from experience, just gut reaction... I'm not sure that AOP is anything short of yet another "kludge" to get code generated where it belongs.

    Conversely, I like to think of OptimalJ's "Pragmatic MDA" as AOP "in the large."
  16. Aren't we all part of the "Code Generation"?
  17. Metaprogramming[ Go to top ]

    The point was made by someone that Java was not designed for code generation tools. In fact, I would have to say this is one of the most blatantly wrong statements I have ever seen. Code generation is nothing new. Anyone who has worked on a sufficiently large C project knows the nightmare of macros all over the place. The fact is as developers, we do not yet have the expressive language we need to take decomposition as far as it needs to go. Every generation of languages gets closer but we're still a long way off and that was absolutely a concern when Java was on the drawing boards.

    Curretly we're using DynAOP and FireStorm extensively and they have saved hundreds of hours for our team just this year alone. If there is a bug in the code we run through DynAOP we can update it in one place and instantly have our project fixed everywhere. In the past, we'd often forget a few of the hundred places the bug might be manifested. Likewise, FireStorm handles all of our database interaction. If we need to change the way we interact with our database, add persistence, etc, we do it at a single place - the point of code generation.

    I challenge anyone not using code generation to so effortlessly change from non-persistent to persistent data access. Hibernate probably comes to mind.. talk about code generation!
  18. Done right, done wrong[ Go to top ]

    I'm split on this one, although I do prefer to use a code generator when I can. Technically, macros and LiveTemplates in Intellj IDEA are code generators as is the constructor & getter/setter generators. Those work VERY well.

    However tools like xdoclet tend to not work well for me. First, the end results can be a little confusing as the documentation is kinda poor. Second it's almost as much work to learn/use xdoclet as it would be to just do it by hand. Thrid, it never seems to get JBoss many-to-many relationships right in the JBosscmp-jdbc.xml.

    I'm not trying to beat on xdoclet per se, I'm just using a real world example of how it can "not work". So the answer for me is "yes", but useable ones are slow to come to market.
  19. Done right, done wrong[ Go to top ]

    I'm split on this one, although I do prefer to use a code generator when I can. Technically, macros and LiveTemplates in Intellj IDEA are code generators as is the constructor & getter/setter generators. Those work VERY well.
    This is a very common antipattern I faced. Sometimes developers want to make universal generators that would do the entire job for the project. This decision has several huge drawbacks:
    1) The result code of your generator-tool may contain bugs that would be difficult to fix for developers who found them (They should understand the way your generator works and change the generator's algorithm).
    2) If requirements change for some part of generated code, you should update your generator thus making it more complex.
    However tools like xdoclet tend to not work well for me. First, the end results can be a little confusing as the documentation is kinda poor. Second it's almost as much work to learn/use xdoclet as it would be to just do it by hand. Thrid, it never seems to get JBoss many-to-many relationships right in the JBosscmp-jdbc.xml.I'm not trying to beat on xdoclet per se, I'm just using a real world example of how it can "not work". So the answer for me is "yes", but useable ones are slow to come to market.
    Partially agreed. xDoclet is not very useful for CMP2.0 beans generation (and especially migration between containers), but it fits well for Session Beans and BMP. Using wide spread generators like xDoclet for code and xml descriptors generation is a good practice.

    Best Regards,
    Theodore V. Kupolov
  20. Done right, done wrong[ Go to top ]

    I think there is something wrong in framework or in application architecture if
    it needs workarounds like MDA. Programming languages like JAVA are not designed for code generation tools. If tool is done right then it must be possible to execute program without diagram and generated code mix.
    I do not remember names, but this kind of code drawing tools exist too.
  21. XDoclet and CMP[ Go to top ]

    xDoclet is not very useful for CMP2.0 beans generation (and especially migration between containers), but it fits well for Session Beans and BMP.
    I couldn't disagree more. Entity beans, especially CMP ones, is where XDoclet really shines. With CMP beans you need to specify all your mapping details, relationships, EJB-QL for your finders, etc... XDoclet also can generate very nice value objects. (one of the greatest time savers in XDoclet) XDoclet does more for CMP beans than for any other type of bean.
  22. XDoclet and CMP[ Go to top ]

    I couldn't disagree more. Entity beans, especially CMP ones, is where XDoclet really shines. With CMP beans you need to specify all your mapping details, relationships, EJB-QL for your finders, etc... XDoclet also can generate very nice value objects. (one of the greatest time savers in XDoclet) XDoclet does more for CMP beans than for any other type of bean.
    Try to to describe a many-to-many relationship in container-independant way. JBoss and Weblogic (for example) has its own relationship mapping. So if you want to port your CMP layer to another container (it's one of the main reasons to use CMP) you should update xDoclet tags for this container. I don't tell that it's an xDoclet problem, cause it's an EJB spec design flaw. But there are more elegant solutions for CMP generation, e.g. universal CMP model that would describe CMP fields, relationships, mappings etc. in detail, so this description could be mapped to any container. JBuilder generates CMP beans following this way, that's the only reason I use this IDE for;)
    My idea is similar to the following http://www.theserverside.com/news/thread.tss?thread_id=8429 . But I don't know what has happened to that project (looking at vendor site I supposed they started XXX-generator project :)

    Regards,
    Theodore
  23. EJBGen and CMP[ Go to top ]

    Try to to describe a many-to-many relationship in container-independant way. JBoss and Weblogic (for example) has its own relationship mapping. So if you want to port your CMP layer to another container (it's one of the main reasons to use CMP) you should update xDoclet tags for this container.
    This limitation has nothing to do with the tool you are using (and I hope that if you are running WebLogic, you are using EJBGen :-)) and if you think it's hard to do with annotation processors, try to do it in raw XML...

    I agree with Norman, EJBGen/XDoclet absolutely shine for CMP beans. Entity beans are very complex to define, compared to Session and Message-Driven beans.

    Take a look here if you're not convinced...
    I don't tell that it's an xDoclet problem, cause it's an EJB spec design flaw.
    Ah, we agree then :-)
    But there are more elegant solutions for CMP generation, e.g. universal CMP model that would describe CMP fields, relationships, mappings etc. in detail, so this description could be mapped to any container.
    In an ideal world, everything would be standard and we would all be using the same tools and technologies.

    What a boring world that would be, uh?

    Seriously, O/R mapping isn't part of the EJB specification because it's a very hard problem and tackling it would have pushed the specification by probably several years (and it most likely won't be part of EJB 3.0 for that same reason).

    --
    Cedric
  24. EJBGen and CMP[ Go to top ]

    This limitation has nothing to do with the tool you are using (and I hope that if you are running WebLogic, you are using EJBGen :-)) and if you think it's hard to do with annotation processors, try to do it in raw XML...I agree with Norman, EJBGen/XDoclet absolutely shine for CMP beans. Entity beans are very complex to define, compared to Session and Message-Driven beans.
    At first let's suppose that we do NOT need business logic in CMP layer (only fields and CMR)
    Please tell me what is easier:
    1) to describe each relationship using xDoclet and if you want to port your app to another container you have to add extra tags
    2) Start JBuilder and model your CMP layer in 10 - 30 minutes (importing existing DB schema or generating your own). And porting your layer to another container needs only changing AppServer combobox in preferences.
    JBuilder use XML as an underlying storage describing the O/R mappings and all the information to generate the code and descriptors.
    I'm NOT JBuilder fan (or promoter) I just want to say that this idea has rights to exist...
    As for me - the 2nd way is much more attractive;)
    I don't understand why there is no such project (with open XML model generating code using XSLT (just an example)) only for CMP beans...
    And again - xDoclet is a brilliant tool for Java - thanks to Rickard Oberg;).
    But it's not a panacea for everything.

    Theodore
  25. In addition to the generators in IntelliJ's IDEA, I routinely use Excel formulas to construct paste-ready Java code.

    Recently, I needed to write a method to replace all "special characters" in a text string with their HTML entity equivalents. After locating a comprehensive list on the web (120 HTML entities!), I pasted the whole table into Excel. Below the descriptive headings, starting at row 2, the symbols appeared on the left in column A, with the entities on the right in column B.

    In columns C and D, I wrote a couple of text manipulation formulas =C1&IF(A2="""","\","")&A2 and =IF(ISBLANK(D1),"",D1&",")&""""&B2&"""" to add the given symbol or entity to those listed above. By copying these formulas down their respective columns, I built the crux of my symbols string and entities array constants. At the bottom ="String symbols="""&C121&""";" and ="String[] entity={"&D121&"};" rendered my completed Java statements, ready for pasting into my code.

    Looping through the symbols, I do a replace-all (using a regular expression), if the symbol is found anywhere in the string.

    Now, not only did I avoid typos, but I actually included obscure symbols that I don't know how to type (nor what their exact ASCII code is)!
    I'm split on this one, although I do prefer to use a code generator when I can. Technically, macros and LiveTemplates in Intellj IDEA are code generators as is the constructor & getter/setter generators. Those work VERY well.However tools like xdoclet tend to not work well for me. First, the end results can be a little confusing as the documentation is kinda poor. Second it's almost as much work to learn/use xdoclet as it would be to just do it by hand. Thrid, it never seems to get JBoss many-to-many relationships right in the JBosscmp-jdbc.xml.I'm not trying to beat on xdoclet per se, I'm just using a real world example of how it can "not work". So the answer for me is "yes", but useable ones are slow to come to market.
  26. Done right, done wrong[ Go to top ]

    Second it's almost as much work to learn/use xdoclet as it would be to just do it by hand.
    This is only valid for the first time you use it.
    Thrid, it never seems to get JBoss many-to-many relationships right in the JBosscmp-jdbc.xml.
    I am sure there are generators which can do this - especially when you can control and change the templates of your own. One you can use to do so is innoQ's iQgen.
  27. Split the difference[ Go to top ]

    In my experience, the sweet spot for code generation is between the extremes mentioned in the article. Code generation from a picture (MDA) is getting a lot of hype lately, but I'm not sure I buy into it. It seems that the higher the abstraction that you're generating from, the harder it is to unwire that abstraction and plug in your own code when you find a problem that's too tough for the code generator to crack.

    On the other hand, hand-coding everything from end to end gives you unlimited customization, but little ability to automate trivial, repetitive tasks. There is clearly some measure of efficiency to be added to the process.

    We use XDoclet. There's probably a better tool out there to do the same thing, but it meets our needs at the moment. We use it primarily in our data access layer. It saves time on the mundane data access code, the repetitive typing of column names into CRUD queries. Does it do everything for us? No, but no tool will. The advantage is that coupled with Hibernate, it's easy to get under the covers and write your own code as well. It's not hidden from the developer as it may be with AOP. It's visible, handles the easy stuff, and lets you switch to hand-coding where needed.
  28. Split the difference[ Go to top ]

    Code generation from a picture (MDA) is getting a lot of hype lately, but I'm not sure I buy into it. It seems that the higher the abstraction that you're generating from, the harder it is to unwire that abstraction and plug in your own code when you find a problem that's too tough for the code generator to crack.
    I used model compilation professionally for nearly two years, and yet I haven't a clue what you're referring to. Presumably you encountered such a case and could summarize it here? Or is your criticism merely academic and perhaps lacking foundation?
  29. I love to use it when its the first time a file is written mostly for getter/setters etc. When it comes to business logic and some details of a component, i would never use a code generator as i wont be able to change the code that easily as i would change my own code. Its just a fact of life - well atleast for me. When i see some errors in my application , i know where exaclty whats going wrong. When its the code generator - even if i kind of know the file causing trouble, i m not so sure as i didnt actually write the code.
         Anyway - Everyone has their way of getting things done. So its one of those - EJB vs NO EJB OR Open Source vs. Paid Service kind of issue in which there are both sides of story which are good and bad.

    Happy coding..
  30. When it comes to business logic and some details of a component, i would never use a code generator as i wont be able to change the code that easily as i would change my own code.
    Which CASE tool did you use? Did it suck?
    When i see some errors in my application , i know where exaclty whats going wrong. When its the code generator - even if i kind of know the file causing trouble, i m not so sure as i didnt actually write the code.
    That's a fair criticism of dynamic bytecode generation, as with AOP. Anyway, modern applications include many black boxes. I'd like to hear a real example of model compilation hindering debugging.
  31. When i see some errors in my application , i know where exaclty whats going wrong.

    Wow! Most dev treams take a while to track back from some errors to exactly where they were derived from.

    With pragmatic mda style of codegen, you can create 1000 errors in one fell swoop, or fix 'em in one shot. You can tweak your application(s)'s architecture, logging, security also in one fell swoop.

    Tools are silver bullets.
  32. Split the difference[ Go to top ]

    Code generation from a picture (MDA) is getting a lot of hype lately, but I'm not sure I buy into it. It seems that the higher the abstraction that you're generating from, the harder it is to unwire that abstraction and plug in your own code when you find a problem that's too tough for the code generator to crack.
    I used model compilation professionally for nearly two years, and yet I haven't a clue what you're referring to. Presumably you encountered such a case and could summarize it here? Or is your criticism merely academic and perhaps lacking foundation?
    Not at all an academic cheap shot. Pretty much every picture-based code generation tool I've seen has limitations as to the complexity, business logic, or implementation it can create. One particular vendor that shall remain nameless, but is a major player, tells you that they generate the code, and there are certain areas of that generated code that you're allowed to tinker with. If you modify code outside of these areas, it's overwritten the next time you generate code from the model. If you want to repeatedly generate that custom code, their recommendation is that you assign a senior developer to write an extension for their tool that will allow it to generate the code that you want.
  33. Split the difference[ Go to top ]

    If you want to repeatedly generate that custom code, their recommendation is that you assign a senior developer to write an extension for their tool that will allow it to generate the code that you want.
    This doesn't jive with my experience using BridgePoint to compile behavioral models. It was easy to invoke hand code from within a process model. I *never* had to modify generated code (except to add print statements in the field). I also occassionally customized the scripted templates or created new ones. Special cases weren't a problem. Anyway, if templates only handled 80% of the cases, then hand coding is still slashed to a fifth of what your monkeys would otherwise be stuck doing.

    BTW, it's silly to criticize a tool and withold its name. That's FUD.
  34. Split the difference[ Go to top ]

    This doesn't jive with my experience using BridgePoint to compile behavioral models. It was easy to invoke hand code from within a process model. I *never* had to modify generated code (except to add print statements in the field). I also occassionally customized the scripted templates or created new ones. Special cases weren't a problem. Anyway, if templates only handled 80% of the cases, then hand coding is still slashed to a fifth of what your monkeys would otherwise be stuck doing.BTW, it's silly to criticize a tool and withold its name. That's FUD.
    I choose not to mention the name because honestly, I've publicly griped about them enough. The vendor still comes in on sales visits, so I'd rather not strain that relationship by publicly bashing them every time the topic comes up.

    The tools I've seen do just enough to create simple apps, much like Sun's Java Studio Creator. For complicated apps, you end up gutting the thing to put in caching, complex validation, and in some cases, an architecture that can perform under heavy load. Perhaps there are tools out there that are well suited to generating highly complex apps from pictures - I've neither seen nor heard of them. And if the templates generate 80% of the app, but make the development of the other 20% a living nightmare, trying to work around the limitations of the tool, it's time to take a step back and see if there's any real benefit.

    I'm not opposed to code generation tools. I'm opposed to the false notion that vendors sell, saying that you can have a monkey draw UML diagrams, push a button, and have an application pop out the other side. You still have the toughest 20% of the code that you need to write by hand, and the other 80% of boilerplate could be written by a competent developer in a small amount of time either by hand or using a simple, free code generation tool.
  35. Split the difference[ Go to top ]

    And if the templates generate 80% of the app, but make the development of the other 20% a living nightmare...
    This is more FUD. Have you ever experienced this?
    I'm opposed to the false notion that vendors sell, saying that you can have a monkey draw UML diagrams, push a button, and have an application pop out the other side.
    Still more FUD. Now your accusing (again unnamed) CASE vendors of false advertising. You're beginning to sound a bit clueless.
  36. Split the difference[ Go to top ]

    And you are sounding like you are
    A) not listening, and therefore just pushing your own agenda
    B) getting overly aggressive. Have consideration for others views

    I for one don't feel that it is at all necessary to name names. The concept that he is talking about is very clear without a vendor label. Address his points rather than attacking him with this boorish 'FUD' and 'clueless' label. And an apology would be in order as well.

    -Mark
  37. I for one don't feel that it is at all necessary to name names. The concept that he is talking about is very clear without a vendor label.
    So if I were to say that J2EE vendors make false claims, you wouldn't expect me to actually name some vendors?!

    If you and Rob weren't spreading FUD, it would be easy for either of you to name a deceptive vendor. Instead you both just say "vendor" and expect everyone to accept your FUD as gospel. The CASE market has real vendors. If you can't associate one with your complaint, then don't make the complaint. FUD doesn't get a free ride here.
  38. MDA issues[ Go to top ]

    (please note I am using a custom framework that uses Rational Rose as its modelling tool)

    My problem with MDA is sometimes it is hard to perform incremental development because any change to the model tend to force a regenerate of the classes it uses instead of just the changes. I find it quite annoying that adjusting the layout so I can view the classes in a different fashion also registers as a change which forces a regenerate.

    Also tracking changes to the model is a very painful experience especially when there is a version conflict between developers.

    I prefer XDoclet (whenever it works and does not get in my way) as it does incremental regenerates and I can easily track changes to the files.

    What I would prefer is a tool that takes my existing classes plus an XML file containing the layout of the classes + other UML diagrams such as use cases or sequence diagrams and then I would like MDA. This tool should also be able to reverse engineer existing java code and also provide a way for it to visually track changes between UML diagrams using xmldiff.
  39. Has anybody tried CA's Advantage Gen product?

    http://www3.ca.com/Solutions/ProductOption.asp?ID=4537
  40. Case study[ Go to top ]

    I think this article has some valid points.
    But the "case study" on it is useless.
    What classes are created ? It codes the bussines objects ? Get them from sequence diagrams ?
    How the data is defined on UML ? What diagrams it uses ? Examples?
    Some tool used ? AndroMDA ?
    And many other questions.
  41. Case study[ Go to top ]

    It codes the bussines objects ? Get them from sequence diagrams ?
    Sequence diagrams are a poor source of behavioral information. CASE tools that take behavior seriously are biased towards supporting state machines. This is because lifecycle is so fundamental to an object's operating. State machine operations are merely actions, a concept Struts hackers know well. MDA could automate Struts nicely.
  42. J2EE 1.4 Case study[ Go to top ]

    Talking about case studies, I [sorry for the plug] happened to encounter an interesting J2EE 1.4 code generation case study, described in this article on ONJava.com.
  43. J2EE 1.4 Case study[ Go to top ]

    Talking about case studies, I [sorry for the plug] happened to encounter an interesting J2EE 1.4 code generation case study, described in this article on ONJava.com.
    The gist of the article seems to be that generated code has higher quality (fewer defects) than hand code. Hmmm...
  44. generated code has higher quality[ Go to top ]

    Talking about case studies, I [sorry for the plug] happened to encounter an interesting J2EE 1.4 code generation case study, described in this article on ONJava.com.
    The gist of the article seems to be that generated code has higher quality (fewer defects) than hand code. Hmmm...
    Generated code quality can easily be better than hand code. People make mistakes and the person who has to write the boring repetative "easy" code tend to make the most mistakes of all.

    Code generators produce the same code every time. If you find a bug in it you fix the template and run it again. Put another way the quality of a code generators generated code is most likely to increase.

    Hand written code is only as good as the next hiree's ability to get it right or is a mixture of fixes improperly applied to only part of the code.

    Certainly that has been my experience.
  45. generated code has higher quality[ Go to top ]

    Put another way the quality of a code generators generated code is most likely to increase.
    This is absolutely true. About ten years ago the saying was that "When generated code leaks, it leaks like a sieve." The point being that a template bug gets instantiated in dozens of generated classes, and this ensures that the bug will be noticed sooner.
  46. generated code has higher quality[ Go to top ]

    I have used code generation in an EJB based project and overall it provided more benefits than harm. The generators took a considerable amount of time to get mature but afterwards, they paid back. Employing Code generation standardised every layer of our architecture, helped us to focus only on the business delegate tier. New developers were able to catch up because of the consistency of the generated code(from Value Object conventions, Entity and Session Beans, Fast Lane Readers to descriptors, etc.). For handling special cases, we didnt overwrite generated code, infact derived separate classes for such purpose. This was however rare so didnt prove any big deal.

    The only short coming we realized is that code generation demands extreme clarity of the application overall and a finalized database, which is often not at such desirable levels in many projects.

    Edwin Yaqub
    IPL
  47. Except for the GUI programming I dont see much value addition from a Code Generator. For business logic anyway one need to put in the manual effort and as someone has pointed out earlier too that debugging a self written code is far more easier than the generated code. I disagree that the generated code is of the high quality as one keeps te default java standards in mind while coding.
  48. J2EE 1.4 Case study[ Go to top ]

    The gist of the article seems to be that generated code has higher quality (fewer defects) than hand code. Hmmm...
    The purpose of the J2EE proof-of-concept (POC) was to verify that the generator prototype is flexible enough to "learn" the best practices of Sun's J2EE 1.4 blueprint developers, and produce Java code at the same quality level. To our own surprise, the POC revealed that there were harmless bugs in the blueprint sample application. In fact, it took us a while to realize that the bugs were not in the generator, as we believed in the first place.

    The POC was thus successful from our perspective ("We Generate Your Software"), as the generated code in that specific case was even better than the hand-written code. The other files (database schema in SQL, a few POJOs) generated so far from the same textual metadata are at the same quality level as the hand code. I believe, along with several people from the Code Generation Network that code generation improves productivity and consistency, and provides a higher level of abstraction, while fully respecting hand-written code.

    To wrap up, the POC story seemed interesting enough to write an article about it. Therefore that article on ONJava.com is (so to speak) a side-effect of the POC.

    [PS: I suspect this is becoming too much of a plug. Feel free to email me at 'fap AT iol DOT it' to continue the thread offline]
  49. [PS: I suspect this is becoming too much of a plug. Feel free to email me at 'fap AT iol DOT it' to continue the thread offline]That's OK for the plug. Hopefully some doubters with download your product.

    The problem with this thread is that it's mixing up the complex, fairly poor tools provided by certain MDA vendors with simply Java code generation tools provided by the likes of Francesco and Codefutures.

    I suggest visiting the Code Generation Network http://www.codegeneration.net and trying out a tool I've found to be useful for DAO code gneration: FireStorm/DAO. http://www.codefutures.com/products/firestorm/
  50. The problem with this thread is that it's mixing up the complex, fairly poor tools provided by certain MDA vendors...
    That's FUD. You should only say "certain MDA vendors" if you have at least two specific vendors in mind and are prepared to share their identities. Nameless vague implications get us nowhere. It also reveals an agenda on your part and a conflict of interest against open discussion. MDA is an interesting new technology. Vagueries make it harder for an outsider to assess the readiness of MDA, thus increasing the hesitancy of an unfamiliar architect to risk time evaluating it. Someone who opposes MDA would want to foster this uncertainty.
  51. That's FUD. Can you stop characterizing anyone that has tried MDA and did not like some who spreads FUD?It also reveals an agenda on your part and a conflict of interest What are YOU so sensitive to MDA comments?

    From my experience:

    The simply matter is that MDA vendors tend to go over the heads of coders and aim for development managers with a sales pitch. That annoys some people for some reason...

    Also, certain MDA vendors are relunctant to supply the source code for their generation templates - which means the code generation customization options are limited.

    Some MDA tools are really amazing.

    Some MDA place restrictions on what coders can do after the code has been generated - and have poor roundtriping capabilities regarding customizations.

    I prefer simple code generations tools that fit in well with existing development processes.
  52. Can you stop characterizing anyone that has tried MDA and did not like some who spreads FUD?
    You're over-generalizing the discussion. Nobody here has grumbled about others not liking MDA. My complaints regarded trolls using disparaging vagueries such as "certain MDA vendors" accompanied by a stubborn refusal to clarify. This hurts a collective attempt at understanding the material and discourages the audience from further investigation of MDA. It seems deliberate to me.
  53. Can you stop characterizing anyone that has tried MDA and did not like some who spreads FUD?
    You're over-generalizing the discussion. Nobody here has grumbled about others not liking MDA. My complaints regarded trolls using disparaging vagueries such as "certain MDA vendors" accompanied by a stubborn refusal to clarify. This hurts a collective attempt at understanding the material and discourages the audience from further investigation of MDA. It seems deliberate to me.
  54. Can you stop characterizing anyone that has tried MDA and did not like some who spreads FUD?
    You're over-generalizing the discussion. Nobody here has grumbled about others not liking MDA. My complaints regarded trolls using disparaging vagueries such as "certain MDA vendors" accompanied by a stubborn refusal to clarify. This hurts a collective attempt at understanding the material and discourages the audience from further investigation of MDA. It seems deliberate to me.
    You didn't answer the key question: why are you so sensitive to negative comments about negative comments about MDA? Look up the discussion - you jump in with a "that's FUD" several times.

    I think code generation is the obvious way forward - it's pretty much a no-brainer really. I don't like MDA - but that's just a subset of code generation that has been badly sold by certain vendors (and I don't name the vendors because it's only my opinion).

    Anyone that is interested in code generation should check out the simple code generation tools out that (and I expect many will then move onto MDA if they like it).
  55. MDA - demystified[ Go to top ]

    Steph, To put another spin on your statements.....

    1). Since when do developers have any purchasing power within a company? Typically they do not!! They only make recommendations. That is the reason vendors go to the decision makers..the people who control the $$.

    2). If I understand you correctly...why would you be interested in the source code for the generation engine. I think what you mean to say in MDA speak....you want to look at the Platform Specific Model PSM that generates the architecture. Although..its probably useless to you without the engine, you can look at the metaprogram to get a feel for the level of customization.

    Sounds like you had a bad sales rep...ask for a different sales rep. Most reps have problems just articulating what MDA is...much less sell it to an org.

    3). Roundtrip is not a requirement and should not be used for MDA projects. A seasoned MDA Practioner will never endorse a roundtripping methodology.
    -----------------------------------------------------------------------------
    It's really a sad commentary on the religion war between hand-development vs. source-code generation. The people who will endorse hand-development have countless hours put into 'their' frameworks.....which can be altered in a MDA tool and customized to the targeted arcitecture.

    The justification for MDA has nothing to do with technology. The justification for MDA is economic. When I can deploy a team build a system from the ground up through design models...which I should do design anyway...I don't have to depend on a package solution vendor, because the cost of ownership is 6X the price of the deployment of the MDA approach. That is not even including the cost of deployment and integration....which is what MDA solves as well. If you were a VP/CIO/CTO...which one are you going to pick.

    Earlier on this thread, someone mentioned they don't have time to do design....I have consulted with many organizations to adopt MDA...that is because of history with our culture. Because of the disjointed process between design and code construction...in general, developers with less that 15 years of experience have not been mandated to produce system documentation. Older developers do...just ask a mainframer. That's because of the speed of business. !!!NOW!!!...you actually have a workable bridge where the design actually matchs the system. So the design is going to take more important part of the process.

    MDA is not a silver bullet. I have found MDA doesn't do very well in a portal strategy. Its cheaper and more cost effective to go out a buy the product.
    MDA does really well with transactional-based systems.

    More later............
  56. Spinner? Declare your interest[ Go to top ]

    Steph, To put another spin on your statements.....
    Do you accept then, that a lot of what you say is spin?

    Steph's comments were restrained - not naming any MDA vendors because he felt it would be unfair since it's just an opinion.
    It's really a sad commentary on the religion war between hand-development vs. source-code generation.
    Actually, most comments in this thread are in favour of code generators. They just want to use more straightforward code generators like DynAOP and FireStorm and Sumusar.
    I have consulted with many organizations to adopt MDA....More later............
    Since you admit that your spinning answers, do you want to declare if you work for an MDA vendor? Andy Grove and Francesco Aliverti-Piuri were up front about their code generation tools.


    It's the agressive approach of people associated with MDA that causes a lot of problems. Does anyone honestly believe that developers will be hand coding in 20 years time? Of course not. A good way to approach the whole code generation area is to start with simple tools. Once you're convinced, then take a look at some MDA tools. One step at a time. In a 5-10 year timeframe, MDA tools will be so advanced ....
  57. Not assoicated with a vendor...Don't work for a vendor....sorry to disappoint you!!
    Actually I would call myself an Executive Management Consultant....more independent than someone who works for a company!!

    15+ years in IT buz...so I have a lot of blood around my feet with managing projects.

    If you want to find out more about me...go to these links!!!
    http://www.standishgroup.com/chaos/class_finalists.php
    http://www.omg.org/mda/mda_files/NationalServicesIndustries.htm

    -------------------
    you wrote:
    Actually, most comments in this thread are in favour of code generators. They just want to use more straightforward code generators like DynAOP and FireStorm and Sumusar.

    then you wrote:
    It's the agressive approach of people associated with MDA that causes a lot of problems. Does anyone honestly believe that developers will be hand coding in 20 years time? Of course not. A good way to approach the whole code generation area is to start with simple tools. Once you're convinced, then take a look at some MDA tools.

    -------------------
    So what your really saying is DynAOP and FireStorm and Sumusar are not aggressive approaches....that MDA is. An approach is an approach regardless of technology. MDA happens to be more mature because the products have been around since 1991!! A lot of folks believe all the tools are relatively new and untested. I have found that not to be the case in my investigation of vendors. What I have found..is some vendors are better than others. A lot of vendors sell vaporware...which in the early days of Oracle, Microsoft, SAP...it was!!
    So

    I don't think its going to take 5-10 years for MDA to catch on with the masses. My best guess would be 2 years tops. There is too many positive business drivers that the software companies will be selling to end-user companies at the executive level.

    The overall message should be as with ANY technology....hiring a good practioner to guide the IT team through a process of adaption helps the company SUSTAIN a repeatable successful process.

    -----------------
    Philip..do you work for a software organization? I'm curious to know your experience with MDA. Its always good to know industry experts in this business.
  58. So what your really saying is DynAOP and FireStorm and Sumusar are not aggressive approaches....that MDA is. An approach is an approach regardless of technology
    I meant an agressive commercial approach going over the heads of the developers and then having it imposed. It happens a few times and the news speads ....


    It would be good to thing that code generation will take off in a couple of years - but as you can see from this thread there's a lot of resistance.

    Using simple code generation tools is the best way forward for now. Once the benefits can be seen .... the damage will be repaired ...
    Philip..do you work for a software organization? I'm curious to know your experience with MDA. Its always good to know industry experts in this business.
    I work for a document delivery software vendor called Esker. Code generation, like on demand computing, is just one of those things that I see as going to happen anyway, but is damaged by certain vendors.

    I suspect that some other (more negative) champions of MDA in this thread do have connections past or present with MDA vendors.
  59. As the British say..."your spot on". That is one of the reasons why I advocate having an experienced MDA practioner help with the integration with the development. I have a detailed methodology for this approach. Its quite complete and has been tested with companies. Needless to say, there are always nuisances to the approach pending the business model and the strategic direction of the company. So I have the team do a lot of development work as well as process modeling.

    When I stated being dragged down in the religious war...that the path of resistence with developers. Yes..it's true that 'generated code' is a little slower than 'hand-cranked' code (only 10%), or 'it takes away from my creativity' statements...aka...license to hack at code. Instead of working at the source level. Developers need to think about putting their creativity and industry experience into design models. Use the creativity at the design level, independent of architecture deployment. In the short and long term, you build more value for the company by being able to understand the business, and raise the level of operational awareness, rather than maintaining legacy J2EE code by hand.

    Its important to understand, that in our industry, new technologies are often opposed by so-called experts. I worked for a "huge" software provider, where I was in charge for all product development web software tools back in the mid 90's when the web was considered a joke. I had to go around the world to evantigize web development because I was the only one who could communicate the business value. I remember so-called industry experts telling me the web 'wasn't going to go anywhere' or 'Bill Gates says the web is only a fad, heavy client-server VB apps are here to stay'. What an idiot!!!! The point is technical people are paid for what they know, and general stay in a comfort zone. A tangent from their 'approach' is outside their comfort zone, therefore preceived as a threat. Which is what you have here....only its buried in technology. The approach and management is paramont in this situation.

    That is not to say MDA is the 'silver-bullet'...it still has a little ways to go from my prespective. Next year there could be a new technology approach called 'YoMaMa'....and its hailed as the best thing to slice bread. As you stated, Gen Code with MDA is here to stay and it will be that way from here on out. It just so happens that there is a governing body (www.omg.org) that administrates over the technology...good or bad. But none the less, its a standard...and companies like standards, its a security blanket. Vendors will continue to penetrate accounts at the executive level because MDA is a conceptual sell to an organization.

    Good to meet with you...if you find anything good information please post it. I believe research and finding better ways to do tasks adds value to a career and an organization.
  60. Its important to understand, that in our industry, new technologies are often opposed by so-called experts.
    Self-evident in this thread.
    That is not to say MDA is the 'silver-bullet'...it still has a little ways to go from my prespective.
    For me the only gaping hole remaining is action semantics. The other new MDA RFPs (QVT, etc) are much less essential.
    As you stated, Gen Code with MDA is here to stay and it will be that way from here on out.
    Obviously.
  61. Contact[ Go to top ]

    Brian to see you on the post....hope things are going well.

    Sometimes you have to state the obvious to get the message across.
  62. underlying problems...[ Go to top ]

    Will developers still be hand coding in 20 years? Yep
    Will developers still be hand coding in 50 years? Yep

    The merits of code generation from models, etc. has been out in the industry for over 15+ years now, at least. I think my dad could pull up some quotes from 35 years ago saying that developers will never write a lick of code in 10 years. Maybe today's quotes are more on target, but I doubt it. Almost every project I have been on, and much to my dismay, requirements are the two-headed step child. They almost always are incomplete, and rarely viewed as the critical portion of the project. It is astounding to me, but frankly, it has become the norm on almost every project I know about or talk to friends about. I would argue that this is probably worse today than 20-30 years ago. Everything is cheaper and faster, and we just need to get our code done quicker, hmmmm, so what can we cut out or how can we move quicker to coding.

    With this mindset, developers will be hand coding for many years to come. How can someone create a model with any certainty of its accuracy, given that the business problem has not been properly defined. And as long as this is the case, I cannot forsee managers ponying up the cash for large modeling / code generation tools that tie to business requirements. There will be some, but it just won't be across the board. I certainly see the benefits to code generation, etc., just not sure headway as an industry can be made without some fundamental changes.

    I don't think this is a decision that the developer can make. Sure, they can do things to make their job easier, and it is my belief that is where many of the comments are coming from. However, for broad changes, it needs to be more than developer convenience.

    Just my two cents.
  63. underlying problems...[ Go to top ]

    How can someone create a model with any certainty of its accuracy, given that the business problem has not been properly defined. And as long as this is the case, I cannot forsee managers ponying up the cash for large modeling / code generation tools that tie to business requirements.
    Congratualations. You just identified one of the most compelling reasons to use MDA. With tradional hand coding, unstable requirements cause significant loss of implementation work -- the infamous 'moving target'. Model compilation mostly avoids this waste. So good at reducing the implementation labor associated with unstable requirements is model compilation that it can also be used as an exploratory tool to speculatively implement novel features that likely will be later thrown away without significant cost. By inexpensively enabling feature exploration, model compilation fundamentally raises the bar for application evolution.
  64. underlying problems...[ Go to top ]

    Brian,

    I am all behind using modeling and code generation. However, I think it will be unable to gain traction in environments where "just get coding" is the mode. Unfortunately, that has and continues to be the major problem with software development, and there is only so much that developers can do to change that. Software development continues to be viewed as an application of technology, rather than the means for solving business problems. For instance, how many projects main goal is to "web-ify" some client server programs, and how many before then were meant to "client server" the legacy apps. And so on and so on. The same bugs, the same shortcomings continue to exist in software development, and the problems are not addressed by understanding the business, but rather the application of "new technologies". If the application of "new technologies" continues to be the mode for improving software, then I don't see much hope for tools or processes that truly improve a business. It seems counter-intuitive that businesses do not want to improve their processes, but somehow it is the case for much of what I have seen. We can only continue to sing the same tune and hopefully things will change and not revert back to old ways.

    Maybe this is not the right forum, but my feeling was that many of the posts were aimed at why to use this, and why not, etc. However, the root problem for me is why have these products not become the norm already?
  65. MDA - demystified[ Go to top ]

    A seasoned MDA Practioner will never endorse a roundtripping methodology.
    Good point. Rarely one might have to add a print statement to generated code, and these I wouldn't want imported into my model permenantly. You imply that round-tripping is unnecessary, and I hadn't considered that. But I see that in two years of model compiling, I never had to pull hand coded changes back into the model. Some folks loudly insist here that MDA falls apart without round-tripping. They're mistaken.
  66. MDA - demystified[ Go to top ]

    3). Roundtrip is not a requirement and should not be used for MDA projects. A seasoned MDA Practioner will never endorse a roundtripping methodology.
    Can you explain what you mean by this?

    Why isn't roundtrip important for MDA projects? Do you mean that roundtrip isn't important in a general sense? Do you mean that MDA is only appropriate for projects that wouldn't need roundtrip engineering? Something else?

    How do you use MDA for projects using an iterative development approach? In your mind, does using MDA require a certain development approach?
  67. MDA and Round Tripping[ Go to top ]

    3). Roundtrip is not a requirement and should not be used for MDA projects. A seasoned MDA Practioner will never endorse a roundtripping methodology.
    Can you explain what you mean by this?
    I think the problem is terminology - not unusual in this field.

    Round-tripping is an absolute requirement in MDA i.e. being able to iteratively re-generate code as the requirements change (e.g. changes to processes, data schemas, etc.)

    I assume the above quote was referring to round-tripping in the sense of a developer generating code and then modifying the generated code by hand. That is always a bad idea when using MDA or code generation.

    If the generated classes don't do what you want then you should either change the code generator logic or create a subclass of the generated class.
  68. MDA and Round Tripping[ Go to top ]

    I forgot to mention that round-trip support was actually the most-requested feature in FireStorm/DAO 2.1
  69. MDA and Round Tripping[ Go to top ]

    I think the problem is terminology - not unusual in this field. Round-tripping is an absolute requirement in MDA i.e. being able to iteratively re-generate code as the requirements change (e.g. changes to processes, data schemas, etc.)
    You've confused regeneration and round-tripping. They're two different things. Round-tripping is reverse engineering, and it isn't part of MDA's unidirectional production pipeline.
  70. MDA and Round Tripping[ Go to top ]

    You've confused regeneration and round-tripping. They're two different things. Round-tripping is reverse engineering, and it isn't part of MDA's unidirectional production pipeline.
    I'm not sure I agree with the distinction. Borland, for instance, define round-tripping as "the synchronization between code and models". The OMG may have defined things differently in their MDA standards but most developers would share this understanding of round-trip engineering, hence the confusion earlier in the thread.

    Cheers,

    Andy.
  71. MDA and Round Tripping[ Go to top ]

    You've confused regeneration and round-tripping. They're two different things. Round-tripping is reverse engineering, and it isn't part of MDA's unidirectional production pipeline.
    I'm not sure I agree with the distinction. Borland, for instance, define round-tripping as "the synchronization between code and models". The OMG may have defined things differently in their MDA standards but most developers would share this understanding of round-trip engineering, hence the confusion earlier in the thread.Cheers,Andy.
    Don't worry Andy - your definition was sound - Certain people seems to get upset if anyone says something negative - even indirectly - about MDA. Look at all the FUDs in this thread.

    In your case, you pointed out how useful round trip engineering is for code generation. How offensive!

    ps the new product release is great.... surprised you have time for TSS today!
  72. MDA and Round Tripping[ Go to top ]

    Borland, for instance, define round-tripping as "the synchronization between code and models".
    Google has no hits for that phrase on borland.com. Let's see what industry experts say:

    "Definition 1 (Simple definition of Round-trip Engineering). Let D be the design of the product P, let r be a reverse engineering procedure such that r(P) = D and let g be a product generation procedure such that g(D) = P. Iff g(r(P)) ≡ P (and thus r(g(D)) ≡ D) then hg, ri is a round-trip engineering system."
    -- A Definition of Round-trip Engineering

    IBM's red book: "Round-trip engineering with Rational XDE ... Click OK to start the reverse engineering process."
  73. MDA and Round Tripping[ Go to top ]

    I think the problem is terminology - not unusual in this field. Round-tripping is an absolute requirement in MDA i.e. being able to iteratively re-generate code as the requirements change (e.g. changes to processes, data schemas, etc.)
    You've confused regeneration and round-tripping. They're two different things. Round-tripping is reverse engineering, and it isn't part of MDA's unidirectional production pipeline.
    I don't agree with your definition of round-tripping. If I add a new method to a Java class in TogetherJ that method immediately shows up in the UML model. The tool keeps the model and the code in sync regardless of whether or not you update the code or the model.

    If you're relying on your MDA tool to generate ALL your code you have to live with any shortcomings of UML as a language. Right now, there is a significant gap between the expressiveness of java as a language and the expressiveness of UML as a language.

    If you're building simple applications with screens that do simple CRUD operations against a database MDA sounds like the way to go. However, if you're working in a business domain with any complexity whatsoever, and you're building a rich, object-oriented domain model in order to model that complexity I don't see how MDA is really going to help you all that much.

    If MDA is meant to be unidirectional by design, it will always be limited by the expressiveness of the modeling language.
  74. MDA and Round Tripping[ Go to top ]

    If you're relying on your MDA tool to generate ALL your code you have to live with any shortcomings of UML as a language.
    The complexity of Java is a pending feature of UML 2, known as 'action semantics'. My hope is that action semantics given as XMI could be bidirectionally translated into Java procedures and also as flow diagrams for showing process models. That would encourage round tripping, which could be a good thing. Unfortunately OMG hasn't finished the specification for this yet.

    The model compiler I used didn't have process model diagrams, but could generate C++ method definitions from proprietary model scripting dialect based on SQL. A modern process model compiler could use any procedural language, including Java as its simplified process scripting language. The important thing, the thing that saves labor, is that a framework somehow make it easier for process models to orchestrate other modeled objects. That's what matters most in a process model, such as with BPEL. So a model compilation framework exposes either a visual or textual API that ideally abstracts object lifecycle and as much other custom business processing as possible.

    Occassionally the model compiler was unable to accomodate a business behavior. I found it trivial to invoke hand code from the process model whenever it couldn't be avoided. In the end I had working business objects that behaved better than POJOs. They were endowed with Eiffel-like behavioral invariants that EJB hackers would find too tedious to bother implementing. Because models are usually more constrained (ie, abstract) than hand code, they can be compiled into code that has a better contract than POJOs. An MDA runtime engine is good example of IoC.
    If MDA is meant to be unidirectional by design, it will always be limited by the expressiveness of the modeling language.
    I only skimmed the OMG specification of MDA. What does it say about reverse engineering?
  75. MDA and Round Tripping[ Go to top ]

    The model compiler I used didn't have process model diagrams, but could generate C++ method definitions from proprietary model scripting dialect based on SQL. A modern process model compiler could use any procedural language, including Java as its simplified process scripting language. The important thing, the thing that saves labor, is that a framework somehow make it easier for process models to orchestrate other modeled objects. That's what matters most in a process model, such as with BPEL.
    But BPEL only addresses the messages visible to both parties participating in the process, correct? It doesn't address the internal behavior of either party. So, where does the internal behavior (the real guts of what's happening) get defined?

    Also, I don't treat Java as a "procedural" language. I treat it as an "object-oriented" language. I'm not sure, but it sounds like you're talking about some objects acting like data structures with other objects containing procedural code acting on the data structures. This is certainly one approach (and there are a lot of people building EJB applications with this approach) but it's not an approach I would ever use or advocate. Maybe we're just talking semantics here? and I'll acknowledge that I may have totally missed your point.

    I'm open to the idea of MDA and it's probably time for me to pick up a book or two and start playing with one of the tools to get a better handle on it. We definitely need to find ways of being more productive in our industry and I'm all in favor of code generation where it's truly useful. However, after taking a look at AndroMDA and considering how it could be used to develop OO applications I still have a hard time thinking it would be useful for anything other than creating a first pass at your objects, database DLL, and persistence mappings. If you lose all hand-tweaked code when you regenerate code from the model that's a showstopper.

    Thanks for answering my questions, Brian. I'm sure this topic will continue to be discussed on these boards.
  76. MDA and Round Tripping[ Go to top ]

    However, after taking a look at AndroMDA and considering how it could be used to develop OO applications I still have a hard time thinking it would be useful for anything other than creating a first pass at your objects, database DLL, and persistence mappings.
    Section 2.3.5 of the OMG's MDA Technical Perspective mentions four ways to translate a model, enumerated in order of increasing automation. AndroMDA implements the third way, in which a programer must add hand code to an automaticly generated skeleton. The fourth way includes the notion of an executable model, for which there's much less need to hand code in the implementation language. BridgePoint and PathMATE are very mature examples of such tools in the embedded space. And there are such tools for Java web servers, such as Intelliun VE, and if you insist on a freeware one, there's JAG on SourceForge. AndroMDA doesn't offer MDA's more advanced abilities, such as process modeling or model execution.
    If you lose all hand-tweaked code when you regenerate code from the model that's a showstopper.
    I believe you're mistaken to assume this is a limitation of AndroMDA. Eg, AndroMDA can be told to emit abstract base classes. Any hand coded subclasses survive regeneration.
  77. MDA and Round Tripping[ Go to top ]

    Brian wrote:
    The important thing, the thing that saves labor, is that a framework somehow make it easier for process models to orchestrate other modeled objects. That's what matters most in a process model, such as with BPEL.
    Dion wrote:
    But BPEL only addresses the messages visible to both parties participating in the process, correct? It doesn't address the internal behavior of either party. So, where does the internal behavior (the real guts of what's happening) get defined?
    I ain't advocating BPEL for this, but you've generally overlooked an important aspect of process modeling. Internal processing is merely an object's orchestration of itself and neighbors. If an orchestration language is expressive enough, then it should readily apply to self orchestration and be capable of expressing detailed algorithm. Ie, general purpose logic. Admittedly BPEL doesn't attempt this, but I personally suspect that the distinction between orchestration and internal processing will eventually be exposed as a false dichotomy.
  78. case study[ Go to top ]

    The technical details weren't relevant here, but obviously you have to have a system that let's the users plug in business logic. Some systems give you editable code blocks, but on the project in question, they decided to generate abstract classes that would be extended by the developers to add in the business logic. In an inheritance chain, the developers owned every other class, essentially. It sounds messy, but it solved our problems really well. The only real pain point with the system was that the model was kept in Rational Rose. The code generator also ran in the tool, meaning that it couldn't be part of the nightly build. That was definitely a bad idea, but at the time none of us knew quite how bad it was.
  79. Thank you for the article[ Go to top ]

    I just read your article "Does Code Generation matter to Java developers?" and I just wanted to say that I strongly agree with your position that having my computer write code when it's practical is a great time-saver.

    I'm currently writing a simple proof-of-concept type web app that will contain well over a dozen different screens, each using data from a different table in a relational database. If the proof-of-concept application is a success, the final version of will most likely contain over thirty different screens. From my perspective, having even some of the basic components for this application generated would be a big help in meeting my time constraints for completing this task.

    I'll be doing a lot of custom coding to get this application running, but thanks to a code generator I recently found written by a company called CodeFutures (www.codefutures.com), I believe I've saved at least a week in the time it would normally take me to write and test my data access layer. It even generated a simple web app that uses the generated DAO code which makes it very easy to verify it works. As a result, I'm well on my to completing this application sooner than I originally expected.

    It's good to see there's others out there that also consider these kinds of tools valuable. I look forward to hearing about other tools (perhaps on this thread) that also offer ways to make coding efforts faster, more consistent and less buggy.
  80. I think, generate business code from UML or whatever is useless.

    What we need, is generate "instruments", that we can easy use as cubics to build our business logic. Generators that generaet something "generic" is a piece of ...

    For example of good generated "instruments", one is Bea's XML beans - generate very quick code to work with XL that confirm XML schema, another is EJB containers, generation of implementation of interfaces. You know many other good things.

    They generate tons if java code, but those tons are specific, somehow "hidden" and no need maintained, just to regenerate.
  81. it matters to developers at all[ Go to top ]

    Code generation does not add any value above its source. Instead of generating code, you could better build a runtime, that interpretes your source.

    Holger
  82. java is a very expressive language, well suited to model logic in terms of algorithms, functions objects, components, ...

    maybe there are things that can be better expressed with other languages or even a graphical notation. If we agree on this, my proposal is to directly generate byte code from those languages / notations / whatever.

    Holger Engels
  83. Every coin has two sides!![ Go to top ]

    Hello friends,
    I Code Generation definitely helps when you are working with Struts. Take an example of StrutsBuilder tool. With few inputs and clicks, you get several files generated in your directory. How much time would it take to write those manually? Also consider an example of GUI design with JBuilder, would not it give you much flexibility to drag and drop the components instead of manually setting the x and y coordinates?

    Whether you teach the tool through certain configuration files to generate the code (like YACC for C) or you use these tools for creating the quick Java code output is one and the same - You get quick, consistent, proven, neat and commented code as output.


    The other side of the coin is Developers dont find enough confidence when they face any bug in the auto generated code...

    Thanks
    -Swarraj.
  84. Do anyone know Apyon?[ Go to top ]

    The Apyon is a code generator and prototyping tool where the developer specify the system and the functional application is generated that obey the architectural and coding standards defined by templates.
    After that, the developers modify and/or complement the code with business rules, using your prefered IDEs, and then the modified code is loaded into the Apyon for the next generation.
    In resume, it generates using templates and understand every modification made in generated code.

    For more details visit: www.apyon.com
  85. Castor rocks for XSD derived XML beans[ Go to top ]

    I use Castor to generate 100's of bean classes (*) from a complex W3C XML Schema (XSD), it would not have been practical to write all this code by hand, it has allowed me to frequently regenerated the classes after schema updates, with only minor changes to the client code. I also note that the castor classes can load/validate huge XML files, which DOM based XML engines chock on e.g. XMLSPY, DOM4J.

    * Castor also generates Schema validation code for each XML bean, something which is missed by some other tools e.g. Java classes generate from an XSD by XMLSPY.

    Infrnz