I guess we may get into annotation processors by creating one for cgen. It will be relatively easy to implement feature (since cgen is there already and its functionality is predefined) and may provide us with cleaner IDE integration, in a cross-IDE manner.
BTW here is another popular annotations-processor based technology - Dagger 2 (http://google.github.io/dagger/ ). It is a de facto DI standard for Android. (I am looking at it as a potential lightweight replacement for Guice in Bootique). Andrus > On Mar 2, 2016, at 3:11 PM, Andrus Adamchik <[email protected]> wrote: > > 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 >
