Assume @AutoProperty when no annotations are found.

[irobertson]

Currently, if a class attempts to use pojomatic, does not have any Pojomatic annotations, pojomatic will throw an exception.

It has been my experience that by far the most common way to deal with this has been to place an @AutoProperty annotation on the class. This ends up being boilerplate, and often is initially forgotten.

I would like to propose that when pojomatic finds no pojomatic annotations on a class or any of its superclasses, that it assume the presence of @AutoProperty on each class in the inheritance hierarchy.

Strictly speaking, this would be an incompatible change, but only in the sense that pojomatic would actually do something useful where it currently throws an exception. https://xkcd.com/1172/ not withstanding, this is a cost I'm willing to accept.

[hansenc]

:+1: Sounds good to me

On Mar 21, 2016, at 3:27 PM, Ian Robertson notifications@github.com wrote:

Currently, if a class attempts to use pojomatic, does not have any Pojomatic annotations, pojomatic will throw an exception.

It has been my experience that by far the most common way to deal with this has been to place an @AutoProperty annotation on the class. This ends up being boilerplate, and often is initially forgotten.

I would like to propose that when pojomatic finds no pojomatic annotations on a class or any of its superclasses, that it assume the presence of @AutoProperty on each class in the inheritance hierarchy.

Strictly speaking, this would be an incompatible change, but only in the sense that pojomatic would actually do something useful where it currently throws an exception. https://xkcd.com/1172/ not withstanding, this is a cost I'm willing to accept.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[irobertson]

There are a few interesting challenges here.

One is that currently, Pojomatic only attempts to access the byte code for a class if the class has properties. Now that any class likely has them, it can ask for things like the byte code for the String class, which unfortunately may not be accessible (at least, not the way we currently try to get at it). We can certainly rule out classes from the system class loader, but that makes things... weird.

A second issue is around the question of class hierarchy. My original thinking was that, absent any pojomatic annotations, we should act as if all classes in the hierarchy had @AutoProperty. However, this means that one can no longer just drop @AutoProperty from a class and get expected results - if the class extends another class, that class's properties might now get pulled in as well.

A final concern is this - it becomes a way to use Pojomatic to peek inside objects of classes that would prefer to keep their internals private. Pojomatic currently needs certain security manager holes opened for it to work; I'd rather not abuse that power. It would not be good if one could call Pojomatic.pojomator(opaqueClass).toString(opaqueInstance) and get the internals dumped out. As such, if we do this, there needs to be a way of determining if the caller of Pojomatic.pojomator is (directly or indirectly) the class in question. (This would in turn break Pojomatic.diff, unless we could turn this restriction off in absence of a security manager).