Processor [1] is a *source* generator, not bytecode generator. Here is a good example showing what it can do [2]. So I am thinking of generating .java via this API in response to annotations present in the handcoded files.I suspect there will be more then a few things we can do with this. We need to explore our options. But already it sounds like cgen on steroids :)
Andrus [1] https://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/Processor.html [2] http://hannesdorfmann.com/annotation-processing/annotationprocessing101 > On Mar 2, 2016, at 12:57 PM, Aristedes Maniatis <[email protected]> wrote: > > Ah, I missed reading the subject of your email. You mean something to take > Hibernate style @ManyToOne, etc annotations and turn them into an XML model > for Cayenne? > > Or to interpret them at runtime and be able to run without an XML model at > all, instead calculating the model on the fly? That would require something > like ASM instrumentation to add the Cayenne superclass and even then might > not be possible. > > If you mean the first one: just to spit out an XML model from the annotated > Hibernate source, then another option is to use the Javadoc processing system > within the JDK. I did something very similar to write a custom groovy/java > processor to look at annotations and use them in creating docbook output. > Since we don't need to support groovy, it becomes even simpler. I read in > @Nullable, @NotNull and other annotations to make the output quite nice. > > > Have I got your suggestion right now? > > Ari > > > On 2/03/2016 3:38pm, Andrus Adamchik wrote: >> I used Lombock as an example what we can do with built-in JDK features. Not >> suggesting we actually use Lombock. >> >>> On Mar 2, 2016, at 1:28 AM, Aristedes Maniatis <[email protected]> wrote: >>> >>> On 1/03/2016 10:55pm, Andrus Adamchik wrote: >>>> Maybe it is time to start using compile annotation processors in Cayenne? >>>> E.g. see this video: >>>> >>>> https://projectlombok.org/ >>> >>> My concern is that since it is a hack that uses undocumented bits of the >>> JDK, moving to new releases of Java may be significantly delayed. >>> >>> I'd love to see the JDK adopt many Lombok features (or even many of the >>> similar features in Groovy with implicit getters and setters), but I'd be >>> worried about us *requiring* Lombok as something that many developers will >>> have a strong opinion about. >>> >>> I'm also not really sure what problem is solves for us. All the boilerplate >>> is neatly tucked away in the superclasses, so why do we care? >>> >>> Ari >>> >>> >>> >>> >>> -- >>> --------------------------> >>> Aristedes Maniatis >>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >> > > -- > --------------------------> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
