cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: JPA to Cayenne entity compiler?
Date Wed, 23 Mar 2016 12:15:53 GMT
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 <andrus@objectstyle.org> 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 <ari@maniatis.org> 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 <ari@maniatis.org> 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
> 


Mime
View raw message