Discussions

News: Getting Code Generation Right for Java and Spring

  1. The recent release of Spring Roo has brought a renewed focus on the benefits of code generation and its impact on Java developer productivity. But, what characteristics are enterprise Java developers looking for in a good code generator? Skyway Software Founder and CTO, Jared Rodriguez, weighs in on this topic and discusses the fundamentals of Skyway Builder, an open source Spring code generator that's no newcomer to code generation space. http://www.skywayperspectives.org/blog/?p=647

    Threaded Messages (28)

  2. This is not really an article for TSS community but its more of a selling their stuff by a company. Thats a nice way to avoid advertising cost and get traffic to your website.
  3. Re: sales article from skyway ?[ Go to top ]

    This is not really an article for TSS community but its more of a selling their stuff by a company.
    Thats a nice way to avoid advertising cost and get traffic to your website.
    Yes. Very smart of them. How dare anyone do this.
  4. My perspective[ Go to top ]

    When a user of a framework or library can (greatly) benefit or be more productive using a code generation tool, I suspect that the poor match of the framework or library or underlying language is the cause. Improvements in Java and EJB3 have made those generator tools for EJB2, like XDoclet, mostly obsolete. Other tools, like for generating Java source out of WSDL, should probably be part of a formal build process and not run from Eclipse. For UML, you end up having to maintain two code bases. Generator tools at some point have you violating the DRY (don't repeat yourself) principle, which I'm not comfortable with. And regarding Spring: If Spring is so productive, then why might a code generator tool be beneficial?
  5. Re: My perspective[ Go to top ]

    When a user of a framework or library can (greatly) benefit or be more productive using a code generation tool, I suspect that the poor match of the framework or library or underlying language is the cause.

    Improvements in Java and EJB3 have made those generator tools for EJB2, like XDoclet, mostly obsolete.

    Other tools, like for generating Java source out of WSDL, should probably be part of a formal build process and not run from Eclipse.

    For UML, you end up having to maintain two code bases. Generator tools at some point have you violating the DRY (don't repeat yourself) principle, which I'm not comfortable with.

    And regarding Spring: If Spring is so productive, then why might a code generator tool be beneficial?
    Actually code generation is a very useful tool to apply decorative functionality. As an example, if I have a business code in Plain Java and I want to deploy it to an ejb2 ecosystem. I dont want to have write all the home and remote interfaces when I can generate it. Another example would be if I want to deploy it on something like WebMethods where all entry points to Java code has to have specific signature with WebMethods specific classes as parameters. I wouldnt want to pollute my Plain Java business code with vendor specific imports. In fact I don't even want to spend time writing hook in classes to call my Plain Java code when I can code generate it. Of course if its just a handful, I might not want to bother writing a code gen. Code gen has its uses. Not everyone gets to choose and on a whim replace the entire enterprise framework because you feel your new projects should use this uber cutting edge new technology and the rest of the enterprise ecosystem is expandable.
  6. Re: My perspective[ Go to top ]

    When a user of a framework or library can (greatly) benefit or be more productive using a code generation tool, I suspect that the poor match of the framework or library or underlying language is the cause.
    You mean like Rails?


    Improvements in Java and EJB3 have made those generator tools for EJB2, like XDoclet, mostly obsolete.
    Maybe like those. But not all.
    Other tools, like for generating Java source out of WSDL, should probably be part of a formal build process and not run from Eclipse.
    Why? This is a one time thing, typically.
    For UML, you end up having to maintain two code bases.
    I'd generally agree with you on this.
    Generator tools at some point have you violating the DRY
    Possibly
    And regarding Spring: If Spring is so productive, then why might a code generator tool be beneficial?
    Because it doesn't do everything.
  7. Re: My perspective[ Go to top ]

    When a user of a framework or library can (greatly) benefit or be more productive using a code generation tool, I suspect that the poor match of the framework or library or underlying language is the cause.

    Improvements in Java and EJB3 have made those generator tools for EJB2, like XDoclet, mostly obsolete.

    Other tools, like for generating Java source out of WSDL, should probably be part of a formal build process and not run from Eclipse.

    For UML, you end up having to maintain two code bases. Generator tools at some point have you violating the DRY (don't repeat yourself) principle, which I'm not comfortable with.

    And regarding Spring: If Spring is so productive, then why might a code generator tool be beneficial?
    IMO,use of a code generator is neither an indictment of or proof of productivity. An example...at one of my jobs, we had very similar projects. That is, fundamental characteristics were the same across just about every project. Because of this, I was able to create a basic framework and approach based on Tomcat, Spring, Hibernate, Struts(then GWT), and a slew of open source tools - Quartz, OSCache, etc... We also had in-house tools that wrapped some external systems that were also part of our projects. I was able to reuse vast amounts of code, build files, directory structures, configuration files, etc because of the standardization that emerged. I also had basic CRUD and finders provided thanks to Hibernate, the Criteria API, a naming convention for DAOs, and a little reflection. So, if basic code was the same, basic project structure was the same, naming conventions emerged, configuration files were the same, would it not make sense to generate the basic, functional app out of a generator? Yes. And that was the direction that I was heading in - spit out a working app, that allowed for log-in, caching, security, basic CRUD, some finders, etc all from some simple information that could be captured in a file to drive the whole thing. I didn't get to see this through, but I can tell you that it would have been useful in our business. And this all was due to how our business operated, not because of Spring. In fact, I tended to start each new project from the bones of its immediate predecessors. After all, that gave me the idea projects, config files, directory structure, etc. I just copied the project, renames some stuff, pruned out project specific stuff, and had a compilable, deployable app with user authentication, good bones,but no relevant business logic or DAOs. Now, just add the project specific stuff. And this was before even having requirements because I *knew* from previous experience that each project had to do the same fundamental 20 things. I started each project a couple of weeks ahead. Code generation would have made it even easier.
  8. Re: My perspective[ Go to top ]

    And regarding Spring: If Spring is so productive, then why might a code generator tool be beneficial?
    I'd put it a different way. Spring is a tool that sits on top of Java and supposedly removes boilerplate and otherwise makes things easier. Now we have tools to generate Spring 'code', ostensibly to eliminate boilerplate and make things easier. In a few years will we see tools to generate Spring code generation configurations? I just wonder where it ends. How many more layers do we need?
  9. Re: My perspective[ Go to top ]

    And regarding Spring: If Spring is so productive, then why might a code generator tool be beneficial?


    I'd put it a different way. Spring is a tool that sits on top of Java and supposedly removes boilerplate and otherwise makes things easier.

    Now we have tools to generate Spring 'code', ostensibly to eliminate boilerplate and make things easier.

    In a few years will we see tools to generate Spring code generation configurations? I just wonder where it ends. How many more layers do we need?
    I just don't see this as layer. If you are doing the same thing, time and time again, why not automate it? Doesn't doesn't mean a layer is added? Just automated repetitive tasks.
  10. Re: My perspective[ Go to top ]

    I just don't see this as layer. If you are doing the same thing, time and time again, why not automate it?

    Doesn't doesn't mean a layer is added? Just automated repetitive tasks.
    All programming languages are in effect code generation tools. All compilers generate some sort of code. In the case of Java it's byte code in the case of other compilers, it might be machine code. Code generation clearly has benefits when you are forced to code repetitive tasks. I have written code generators rather than do rote coding. But factually, speaking, if you can write a code generator to do something, it's possible for a language to solve the same problem. At a high-level, there's no meaningful distinction between a programming language and a code generation tool. I just don't really understand why so much focus is put on code generation instead of improving the languages, APIs and tools that we use to eliminate the need for repetitive coding. In every case I've ever needed code generation, it's been because of a poor design, either that of what I was working on or the tools I was using.
  11. Re: My perspective[ Go to top ]

    I just don't really understand why so much focus is put on code generation instead of improving the languages, APIs and tools that we use to eliminate the need for repetitive coding. In every case I've ever needed code generation, it's been because of a poor design, either that of what I was working on or the tools I was using.
    One of the nice things about the Spring family of projects is that we can put the right solution in the right place. Within SpringSource we're lucky to have Spring Framework whenever we want to improve an API, SpringSource Tool Suite whenever we want to enhance an IDE, plus AspectJ whenever we want to statically supplement the Java language. When designing and building Roo I routinely asked my SpringSource colleagues to make subtle improvements in these projects so we could keep Roo as focused as possible on solving a problem that is most gracefully addressed at development time. As Rod noted, there are many existing standards and existing technologies that most Java developers prefer to use. Take JSP. We could have trivially eliminated Roo's JSP creation services in exchange for a dynamic template builder. Spring's ViewResolver and View abstractions enabled me to do that in 2004 using a dynamic FreeMarker template. But what about when people want to edit their view? They generally want a JSP, so that's why Roo outputs a JSP (instead of just arranging Spring to ship my 2004-vintage DynamicFreemarkerTemplateCreatingView, which we could have easily done). Similarly, what about when people want to do some JPA? They reach for persistence.xml. Naturally we could have worked around this by automatically producing one via Spring's ResourceLoader abstraction at application context startup time, but I feel sorry for people trying to understand what's actually going on or edit it. A further example is when users want to deploy their app to a servlet container, they usually need a web.xml and a WAR-compliant directory layout. Or when they want to have a CI server build their project, they'll often reach for a mainstream build tool so the CI server can integrate with their project easily (such as Maven). Naturally all of these are very commonly required when wanting to hire developers or set corporate standards. In other words, Java developers generally expect that certain common standards and conventions are reflected. It's pretty simple to build a "big bang" solution that is probably productive but doesn't comply very much with the existing norms, conventions, expectations, standards and skills of Java developers. You don't have to look very far for examples of such approaches, and you'll also see they never really took off. One reason is they fail to allow the flexibility and customization that people expect and achieve via the mature, mainstream technologies mentioned above. Plus they often have an unacceptably high conceptual weight because they discard the developer's existing knowledge, skills and experience in those mainstream technologies. We believe that most Java developers prefer to incrementally improve on what is already proven to work, which is why Roo exists. Roo automatically takes care of all the tasks associated with building a typical enterprise Spring-centric Java application. This enables the developer to ignore most tasks unless they actually wish to fine-tune something. When a developer is fine-tuning, all of their existing knowledge, skills and experience in mainstream Java technology is completely applicable and they are not in any way constrained by the use of Roo. It's not just that Roo can initially create some files for you, but it maintains them long-term and does so in a round-trip considerate way. For example, you can edit your web.xml by hand whenever you need to, but when you "install security" Roo will adjust the needed parts automatically. Or you can use Roo with an existing project - you don't need to start a brand new one. Plus you can remove Roo at any time and everything keeps working. It's perhaps worth also noting that Roo not only helps with Java source, but also with XML, JSP and properties files. Do you remember the full structure of a "basic" web.xml or log4j.properties? Or how to use Spring MVC's tag libraries in JSPs in a best practice RESTful manner? Or how to properly add Spring Security to your application? Don't worry about it: Roo will do it for you. As such Roo is much wider in scope than a "code" generator - it's really more like a round-trip aware project generator. I just want to close by clarifying that Roo is not a "code generator" in the traditional sense of the term. I'm going to blog about the fundamental deficiencies of most code generators in the future, but suffice to say we designed Roo with these in mind and definitely do not seek to promote any myth that generating copious amounts of code is ever a good idea. Roo is a delicate project generator that adopts a very careful, fine-grained approach. There isn't a single line of code generated that you wouldn't have written (or copied) yourself or had your IDE build for you automatically if you're engineering a Spring-based Java application. The fact that Roo frees you of this burden whilst still thoughtfully and gracefully ensuring you can easily write the specific parts that make most sense to you is its real promise. It's challenging to understand how it does this by textual description, but the soon-to-be-published videos will make it a lot clearer how this is achieved via Roo. I invite you to watch some of those videos to more easily gain an appreciation of how Roo is quite different from "generators" you've likely encountered before. Cheers Ben Alex Project lead, Spring Roo Principal Software Engineer, SpringSource
  12. Re: My perspective[ Go to top ]

    We believe that most Java developers prefer to incrementally improve on what is already proven to work, which is why Roo exists.
    I think you are right and may you find success in that environment. I'm not really challenging that value of what you are doing but rather the attitude that creates this environment. Few developers these days understand how the computer works at its core. I know lot's of "Java" developers who can't write a standalone "Hello World" java app. My real problem with piling abstraction upon abstraction upon abstraction is that the middle steps become redundant and that developers become so removed from the lower layers they have no idea whether what they are doing is necessary or not. We also end up with a lot of baggage and funny ideas about how things must be done. It's illuminating to talk to COBOL developers about what can and cannot be done because often what we do regularly in Java is considered impossible or too difficult by people with strong procedural backgrounds. To give a good Java-based example, a lot of code generation is eliminated if you stop requiring everything to be a bean and allow for map/dictionary structures. Often the bean approach makes sense but just as often, it's pure boilerplate. No person will actually need to work with that bean. Bean are the "way things are done" and no rational reason for using them is required.
  13. Re: My perspective[ Go to top ]

    I know lot's of "Java" developers who can't write a standalone "Hello World" java app. My real problem with piling abstraction upon abstraction upon abstraction is that the middle steps become redundant and that developers become so removed from the lower layers they have no idea whether what they are doing is necessary or not.
    Good point. It reminds me of an article I read a while back. http://www.joelonsoftware.com/articles/LeakyAbstractions.html
  14. RE: My Perspective[ Go to top ]

    That is an interesting distinction you are drawing between a "code generator" and a "project generator." By your definition, Grails, Skyway, Springfuse and others are not "code generators" either, since all do most or more of what you outlined as a "project generator." Granted, Grails is far more than even a project generator. What you defined around round tripping, robust code generation (even when files are changed by hand), XML generation / manipulation, etc, have all been part and parcel of code generators for a few years now. And as I pointed out in my original blog, having code that looks like what developers would hand code and can manipulate themselves, because they ALWAYS will, is a critically essential component. I will avidly await your blog to understand how you draw a distinction. From playing with Roo and being actively involved in code generators of all sorts for the last 7 years, it sure looks like a “code generator” to me. Jared
  15. Re: RE: My Perspective[ Go to top ]

    I will avidly await your blog to understand how you draw a distinction. From playing with Roo and being actively involved in code generators of all sorts for the last 7 years, it sure looks like a “code generator” to me.
    It's popular in IT management to buy tools that "don't require code". So by calling it something else like 'configuration' or 'mapping' or 'defining' you can immediately attract a larger number of customers. These distinctions have meaning at a very low level but they become meaningless at higher levels. Especially when you blindly favor one over the other.
  16. Re: My perspective[ Go to top ]

    And regarding Spring: If Spring is so productive, then why might a code generator tool be beneficial?
    Sure, it's not too hard to write Spring apps by hand, and plenty of people do so successfully every day, unlike with previous generations of enterprise Java technology. So it's not a question of covering up a design smell as with EJB2, where the need for XDoclet clearly showed something was wrong. But there is a whole lot of boilerplate involved in creating a Java app (and extending an app) that goes beyond what Spring addresses by itself. For example, build scripts; JSPs; JPA mapping files; JPA or validation annotations; use of tag libraries... Although the architecture of a Roo-generated app is based on Spring, there isn't much Spring-specific code or config required, as it uses annotation scanning extensively. No need to write or generate Spring bean elements, unless you choose to customize or do something you can't do in annotations. So the code generation isn't covering up complexity introduced by Spring. Consider the work involved in writing a new web Controller or request handling method in a Roo-generated app (or generally in a best practices app with Spring 2.5 or above). No need for any configuration. Just write a class, annotate it and the handler methods. In other words, virtually nothing to do on account of Spring, which is making the whole thing easy. However, you still need JSPs, and generating them makes sense. Remember that Ruby on Rails does extensive code generation. Whatever its other flaws, I don't think it's often accused of excessive complexity. Spring apps can benefit from the same work being done for them as RoR does. Rgds Rod
  17. Re: My perspective[ Go to top ]

    And regarding Spring: If Spring is so productive, then why might a code generator tool be beneficial?

    Sure, it's not too hard to write Spring apps by hand, and plenty of people do so successfully every day, unlike with previous generations of enterprise Java technology. So it's not a question of covering up a design smell as with EJB2, where the need for XDoclet clearly showed something was wrong.

    But there is a whole lot of boilerplate involved in creating a Java app (and extending an app) that goes beyond what Spring addresses by itself. For example, build scripts; JSPs; JPA mapping files; JPA or validation annotations; use of tag libraries...

    Although the architecture of a Roo-generated app is based on Spring, there isn't much Spring-specific code or config required, as it uses annotation scanning extensively. No need to write or generate Spring bean elements, unless you choose to customize or do something you can't do in annotations. So the code generation isn't covering up complexity introduced by Spring.

    Consider the work involved in writing a new web Controller or request handling method in a Roo-generated app (or generally in a best practices app with Spring 2.5 or above). No need for any configuration. Just write a class, annotate it and the handler methods. In other words, virtually nothing to do on account of Spring, which is making the whole thing easy. However, you still need JSPs, and generating them makes sense.

    Remember that Ruby on Rails does extensive code generation. Whatever its other flaws, I don't think it's often accused of excessive complexity. Spring apps can benefit from the same work being done for them as RoR does.

    Rgds
    Rod
    Exactly. As I said in an earlier post, I would start a new project by copying the old. This includes not only code and config files, but IDE project files. I would just open my Idea project files, do a global search and replace changing "projectX" to "projectY" and BAM! I have a new Idea project - libraries already in place(after all, a similar project would probably use similar libraries) directory structure, etc. Strip out a few project specific items and I had a buildable web app that could be deployed, and logged onto, and does very little. But its ready to roll.
  18. Use of Spring with Dreamsource ORM can boost your productivity. You can find some examples in http://www.leeonsoft.com/examples.jsp. Jim
  19. Re: My perspective[ Go to top ]

    Roo looks really interesting and I think it can be a great supplement for MDSD approaches as well as standalone. I'm wondering what parts of the generated code can be changed by hand and not lost later on?
    For UML, you end up having to maintain two code bases. Generator tools at some point have you violating the DRY (don't repeat yourself) principle, which I'm not comfortable with.
    I agree with you, if you tend to do onetime code generations or if you hand edit the generated code and have to do it over and over again. In general I prefer to use (UML) models and code generation for what they're good at, visualizing relationships and flows. I have with great success introduced this on several projects where we've modeled both the internal domain models (which typically end up in a JPA model) and webservice interfaces (generate the WSDL's, XSD's, etc.) using UML and generated the code using our internal MDSD tool (TigerMDSD). For this to work out you have to make the model the king and the generated code the slave. Changes are made to the model and the code is regenerated. If you want to expand on the code generated it will have to be either through aspects or something more simple like partial classes in C# or 3 level inheritance in Java. For me it's all about raising the level of abstraction and improving communication. When you raise the level of abstraction (moving closer to the meta level) you have a lot of freedom to get smarter with time without having to change a lot of code by hand. It takes experience and at times some pain, but the reward is huge for the parts of a project where visual models are suitable: - For instance the ability to create an automated HTML document which in text documents what have changed between two different model version is of great communicative value on large teams. - Or being abel to generate full DB integration tests, which will test your generated JPA model against a given database is something that typically will take a long time by hand and which you will be reluctant to changing the model too often, simply because the work involved would be too big. Doing it using code generation is incredibly simple, fast and valuable. I've just uploaded a presentation from earlier this year on this subject. You you're interested you can find it here on my personal blog: http://www.cramon.dk/Cramon/Blog/Entries/2009/5/7_Presentation_on_Model_Driven_Software_Development.html /Jeppe TigerTeam
  20. Uh, er... pricing? At least a pricing model: per seat, per developer? Per year?
  21. Uh, er... pricing? At least a pricing model: per seat, per developer? Per year?
    Skyway Builder Community Edition (CE) is free and open source and available for download at: http://www.skywayperspectives.org/portal/web/guest/downloads/overview
  22. Skyway Builder Community Edition (CE) is free and open source and available for download
    I know that - it's clearly stated on their site. I was asking about Enterprise Edition pricing
  23. Skyway Builder Community Edition (CE) is free and open source and available for download
    I know that - it's clearly stated on their site. I was asking about Enterprise Edition pricing
    Skyway Builder Enterprise Edition (EE) is available as either perpetual or subscription pricing. For one developer seat, the yearly subscription price is $2400, including Silver Level developer support. For one perpetual license, the price is $4800, which also includes Silver Level developer support. Discounts are available for quantities greater than one. You can request a Test Drive of EE here.
  24. Skyway Builder Community Edition (CE) is free and open source and available for download
    I know that - it's clearly stated on their site. I was asking about Enterprise Edition pricing


    Skyway Builder Enterprise Edition (EE) is available as either perpetual or subscription pricing.

    For one developer seat, the yearly subscription price is $2400, including Silver Level developer support. For one perpetual license, the price is $4800, which also includes Silver Level developer support. Discounts are available for quantities greater than one.

    You can request a Test Drive of EE here.
    I realize this is an old thread, but we have recently restructured the Skyway Builder product and pricing model. Skyway Builder Enterprise Edition (EE) has been modularized into 4 editions, and subscription-based pricing starts at $199/user. You can find out more here.
  25. Is there a comparison of these stuff to appfuse?
  26. Comparison to Appfuse[ Go to top ]

    There's a high-level comparison of Skyway Builder and Appfuse on the Skyway Community Forums: http://www.skywayperspectives.org/portal/web/guest/174/message_boards/message/45044
  27. Spring Roo[ Go to top ]

    Given that's it referenced here, but without any links, here are some links to Spring Roo information to help folk make up their own minds. - Blog by Ben Alex, Roo's creator. Ben will be continuing this series of blogs to describe Roo in detail. - Spring Roo project page. Download link is here. Rgds Rod
  28. Spring feature request[ Go to top ]

    Rod, How do I make Spring feature requests? On the official Spring site, I can not find any links to do that. Jim Xie
  29. Re: Spring feature request[ Go to top ]

    Jim
    How do I make Spring feature requests? On the official Spring site, I can not find any links to do that.
    Please use the issue tracker. Or follow the "Issue Tracker" link in the Community dropdown on the top left hand side of the .org web site. Rgds Rod