Will this replace the need for the JAX-RS module?


Alright, starting this off as this is the first thing I thought of when I saw the server sub-topic. There is currently a JAX-RS code generator module… it seems to me that if the code-gen module can handle generating client and server code, we should look to unify ALL code generation in to one place, and do it the same way for all of them. If the use of Handlebars.js (as is used in this code-gen project) can truly be used to generate client and server code for any language, then we should not only unify the process so all code generation is done this way, but really beef up the documentation and tutorials… possibly even under the Documentation tab of RAML add a Tutorial section and below that something like how to write code generator for your favorite language.

As I am hopefully going to be working on a Java SDK generator with some others, it may be a decent one to use as part of a tutorial.


I would personally -1 on generating Java code with templates: there are libraries for that matter, including CodeModel and JavaPoet.


I share your concern @ddossot however I also like the idea of a single template language, if it can handle it without huge complications, to generate any sort of sdk or cli or server side implementation. It makes it easier in my opinion to support documentation, tutorials and the likes around adding more sdks and such than trying to get each and every language written in their respective languages using specific libraries. Even if it means a bit more work and learning to pick up on Handlebars.js, to me the end result is far better unity and community support around that path vs each language path… finding developers competent in those languages, spending the time to write the generators, supporting those generators with bug fixes and so forth.


Fair points about the interest of unifying code generation for all clients, although I don’t think the bulk of the complexity for generators lie in the code generation method but in what’s actually generated. So I’m unsure about the actual net benefit in bypassing codegen tools when they exist for a rawer approach.


The more I mull about this, the more I appreciate the idea here. All codegen tools implement a fair amount of duplicated logic on top of the raw RAML parser they use.

So something that would sit between the RAML parser and the codegen logic, maybe something that provides callbacks with a resolved context object (complete with suggested method name, etc…) would surely be cool. In these callbacks, each codegen could use whatever technique they want to output code (heavy languages like Java benefit from using a real codegen lib because the lib takes care of things like outputting import statements automatically, something that would be tedious by hand).

But this means that all codegen tools would need to be written in the same language or that the intermediate layer would have to be written in a lot of different languages…


I think you’re on the right path here @ddossot! I too was thinking about how this tool uses handlebars.js to template out different languages and if that’s the right choice. In fact, oddly enough while filling up my coffee a few minutes ago, I was thinking this could be a pretty cool article that shows how a tool used for one thing can be repuprosed for something else entirely… in this case, I would have never thought of using a JS template library as a tool to produce client/server code in different languages. So to @blakeembrey and @christian_vogel (not sure which of you or both of you came up with it), fantastic idea. I believe there is a good article in there somewhere that would promote handlebar.js as well.

But I do agree also, and @blakeembrey said there is a way to do this in node, that there will possibly need to be a callout of some sort, most likely to the command line to run language specific tools. My concern though, assuming we had to go that route and could not use handlebar.js completely for the task at hand, would be the dependency list this project would eventually need to handle multiple languages. I suppose we could use Maven or something to try to manage that (not a fan of Maven myself).

Honestly if handlebar.js can do the entire thing, even if it means templates with more lines in it for java imports and such, I’d be fine with that. It reduces the dependencies and complexity of the tool keeping it all within the project and simply adding language templates.


I’m sure it’s possible to generate what the JAX-RS generator does with a templating technology like Handlebars or Mustache, except of course for POJOs coming from XML or JSON schemas.

Many languages run on the JVM, including JavaScript, so I guess one approach could be to mandate JS as the language for writing codegens and the JVM as the platform for running them, providing enough hooks so language specific generators (like JSONSchema2Pojo) could be hooked in, and enough contextual information so that a templated approach could work.

For example, to output a JAX-RS resource with a templating engine, you would need a list of all the POJOs consumed and produced by the resource in the context so you can generate input statements on the top of the class. You could also just import <your_pojo_package.*> all the time to simplify things (it would be unfortunate for those, like me, who think generated could should be as neat as possible, but that would sure work). But you would still need to know, at each method level, what are the class names of the generated consumed/produced POJOs.


@ddossot, you have said exactly what I am wondering myself. How do you take a RAML file that refers to json/xsd schemas, and incorporate the json/xsd schema generated language specific classes into the generated SDK code as well? If it requires that a strict naming policy be followed in the RAML file and Json/Xsd schemas such that each schema type has an identical name to the RAML resource (if that is even possible), I think that makes it too dependent on the generator… not good. If there is some way to call out to language specific generators, have the objects created, then some how import those file names and also somehow know where each class maps in to the RAML document… well that seems pretty complex to get working correctly. We do not want to rely on knowing ahead of time the generated schema class names either…

So it does make me wonder how a code generator written entirely handlebars.js can be written. @christian_vogel @blakeembrey any thoughts on this?