Easy way to add Methods to Java classes

[joelittlejohn]

Original author: JasonBog...@gmail.com (November 28, 2012 14:46:24)

Using auto-generated code is great, but it's hard to add other methods to the generated classes when they will be overwritten on the next Maven build.

Here's what I suggest:

• Make all the generated classes abstract, so that they must be subclassed to be instantiated.
• Prefix all the generated class names with the underbar ( _ ).
• Generate another set of classes the same name as the first set, but without the underbar.
• Have the second set of classes extend their corresponding abstract class.
• Set the body of these classes blank with a "TODO" statement telling the user to add "additional class methods here".
• Generate the abstract underbar classes -every time- with the just the POJO getter and setter methods like it does now.
• Generate the non-underbar classes only -if they don't exist- on the file system with no class methods.

Examples attached

Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=81

[joelittlejohn]

From JasonBog...@gmail.com on November 28, 2012 14:47:30
This could even be a flag that you set in Maven: if you want to generate them as abstract classes or not.

[joelittlejohn]

From JasonBog...@gmail.com on November 28, 2012 16:54:50
Just would like to mention that this would help me out a lot if we had this functionality, and from looking at the code, it shouldn't been too hard to implement?

Just let me know asap if this is something that can be done quickly and easily so we can figure out how to proceed with our project.

Thanks!

[joelittlejohn]

From joelittl...@gmail.com on November 28, 2012 19:57:01
Jason, thanks for taking the time to raise this and explain these requirements in detail.

To be frank, this is a very specific set of requirements (to accommodate a fairly specific style of development) that I don't see being applicable to many, if any, other users. For this reason, I think it would be best for you to clone the repo and add the features you need.

I'm not sure that I understand why you're so keen to enforce this pattern by creating abstract classes and adding TODOs. Could you not simply take the current output and extend the types (with a subclass) where you need to? The generated types aren't marked final.

I'm happy to give you some pointers if you're interested in implementing this yourself (it should be trivial to build and deploy your own custom jar). As it stands, I don't think there's much value in adding this into the core.

[joelittlejohn]

From JasonBog...@gmail.com on November 29, 2012 20:52:12
I would think almost everyone who uses this code module would need to subclass these methods, even if it is just to add a constructor. Rarely, if ever, will you have a Java object simply hold data. In fact, when trying to figure out how to interface with these generated classes, I believe I even saw someone reference this code module as a pain point for them.

I could just create individual subclasses for them, but using an IDE like Eclipse creates ambiguity as to which class I'm referring to. For example, if I want an address class, I could generate Address.java, but then I need to subclass it as perhaps AddressModel.java or AddressWrapper.java, etc to add an "isValidAddress()" method. It's a decent pattern, but confusing to a new user who is not familiar with the code. Generating them as abstract as a different name and then automatically subclassing them with the desired name reduces ambiguity.

This tool is kind of useless unless it explicitly facilitates subclasses.

[joelittlejohn]

From joelittl...@gmail.com on November 29, 2012 23:18:08
Jason, there are many, many people using this tool without the feature you've described. If you feel the tool is useless, then I think your use-case is probably very different to that of most other users. So as mentioned, I'm not going to pursue adding this to the core.

There's no need to give up on your feature though. Feel free to create a clone and have a go at implementing what you need:

https://code.google.com/p/jsonschema2pojo/source/checkout

If enough people are interested using this kind of feature, then I'll definitely think again about whether this can be added to the core.

Again, thanks for your comments. I find it very useful to understand how people use the tool, even where their requirements currently aren't within the scope or goals of the project.

[githubjul]

Hi @joelittlejohn

I know that this issue is closed, but I wanted to add 2 things :
First of all, thank you for jsonschema2pojo I think it is very useful !!
Then, I've just discovered this issue and wanted to tell that I am using your generator with the same kind of behavior than the one described by Jason.
I am doing some post processing to make the class abstract, add custom methods, ....

So I just wanted to add that he was not alone to want this kind of functionalities.

I'm still learning how to use your code and customize the generation, so maybe I miss some features.

Thanks again !