Commons Digester
  1. Commons Digester
  2. DIGESTER-158

Use Java6 annotation processing to generate RulesModule instances at compile-time

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.2
    • Fix Version/s: 3.3
    • Labels:
      None

      Description

      Implement a http://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/Processor.html to process Digester annotations rules and generate RulesModule instances at compile time.

        Activity

        Hide
        Simone Tripodi added a comment -

        urgh, looks like I didn't pay attention to the fact it is not possible to express more than one RetentionPolicy in annotations, and actually is set to RetentionPolicy.RUNTIME.
        An idea could be writing a "compiler" that has nothing to do with the APT...

        Show
        Simone Tripodi added a comment - urgh, looks like I didn't pay attention to the fact it is not possible to express more than one RetentionPolicy in annotations, and actually is set to RetentionPolicy.RUNTIME . An idea could be writing a "compiler" that has nothing to do with the APT...
        Hide
        Matt Benson added a comment -

        If it would indeed be a problem to have a precompiled RulesModule for which there are available corresponding Digester annotations at runtime, can you get around it with a wrapper annotation? i.e., is there a class-level annotation required to trigger the runtime behavior? If so, couldn't you make that annotation an element of a compile-time-retention annotation, thus preventing the "trigger" annotation's runtime availability?

        Show
        Matt Benson added a comment - If it would indeed be a problem to have a precompiled RulesModule for which there are available corresponding Digester annotations at runtime, can you get around it with a wrapper annotation? i.e., is there a class-level annotation required to trigger the runtime behavior? If so, couldn't you make that annotation an element of a compile-time-retention annotation, thus preventing the "trigger" annotation's runtime availability?
        Hide
        Simone Tripodi added a comment -

        Thanks for the feedbacks Matt!
        What it is still not clear to me about APT is that RetentionPolicy.RUNTIME annotation are visible to apt tool.
        I wouldn't worry they are available at runtime as well since they are not processed unless users explicitly require loading them via the appropriate module.
        As you understand, I'm an apt newbie...

        Show
        Simone Tripodi added a comment - Thanks for the feedbacks Matt! What it is still not clear to me about APT is that RetentionPolicy.RUNTIME annotation are visible to apt tool. I wouldn't worry they are available at runtime as well since they are not processed unless users explicitly require loading them via the appropriate module. As you understand, I'm an apt newbie...
        Hide
        Matt Benson added a comment -

        I've only used the APT a tiny bit as well... not sure I've even tried to use the code I wrote, TBH. That said, I still don't think there's any reason the processor wouldn't be able to see the RT-retention annotations if that's all you're worried about.

        Show
        Matt Benson added a comment - I've only used the APT a tiny bit as well... not sure I've even tried to use the code I wrote, TBH. That said, I still don't think there's any reason the processor wouldn't be able to see the RT-retention annotations if that's all you're worried about.
        Hide
        Simone Tripodi added a comment -

        As far as you know, does the apt have a tool to generate Java sources or users have to use a 3rd part template engine, such as Velocity?
        Many thanks in advance!

        Show
        Simone Tripodi added a comment - As far as you know, does the apt have a tool to generate Java sources or users have to use a 3rd part template engine, such as Velocity ? Many thanks in advance!
        Hide
        Matt Benson added a comment -

        No, not that I've heard. There is the com.sun.codemodel that more than one person has used; this is what my (again, untested) code uses.

        Show
        Matt Benson added a comment - No, not that I've heard. There is the com.sun.codemodel that more than one person has used; this is what my (again, untested) code uses.
        Hide
        Simone Tripodi added a comment -

        Thanks a lot Matt, much more than appreciated!! I'll give a serious deep try as soon as I get the chance, if it won't be useful for the Digester at least I'll learn something new!

        Show
        Simone Tripodi added a comment - Thanks a lot Matt, much more than appreciated!! I'll give a serious deep try as soon as I get the chance, if it won't be useful for the Digester at least I'll learn something new!
        Hide
        Paul Benedict added a comment - - edited

        APT is being removed from Oracle's JDK 8: http://blogs.oracle.com/darcy/entry/apt_ending. Does that matter?

        Show
        Paul Benedict added a comment - - edited APT is being removed from Oracle's JDK 8: http://blogs.oracle.com/darcy/entry/apt_ending . Does that matter?
        Hide
        Simone Tripodi added a comment -

        AFAIK JDK 8 is not on production systems yet, I would postpone the problem and provide a "temporary" solution for today's technology.
        that makes me smile anyway - please don't get me wrong! - because in the dev@ ML people are still worried about maintaining JDK3...

        Show
        Simone Tripodi added a comment - AFAIK JDK 8 is not on production systems yet, I would postpone the problem and provide a "temporary" solution for today's technology. that makes me smile anyway - please don't get me wrong! - because in the dev@ ML people are still worried about maintaining JDK3...
        Hide
        Matt Benson added a comment -

        I think the problem here is that Simo and I are both such n00bs wrt annotation processing that we erroneously referred to the newer, Java 6-based facilities as APT.

        Show
        Matt Benson added a comment - I think the problem here is that Simo and I are both such n00bs wrt annotation processing that we erroneously referred to the newer, Java 6-based facilities as APT.
        Hide
        Simone Tripodi added a comment -

        yes, definitively

        Show
        Simone Tripodi added a comment - yes, definitively
        Hide
        Matt Benson added a comment -

        This was left as a problem: Simo's initial implementation of this was done against Java 5 APT. [digester] currently supports Java 5, but its CI systems (Continuum in particular) are using a Java 6 installation. To be forward-looking and use the Java 6 Processor, etc. APIs, is it reasonable to say:

        • [digester]'s runtime code uses only Java 5 APIs
        • [digester] includes a Java 6 Processor that "precompiles" [digester] annotations into configured {{RulesModule}}s.
        • [digester]'s build is configured with source 1.6, target 1.5

        ?

        Is this a workable approach, or does the Processor stuff break down on the third point? If so, would it be simpler to convert [digester] to a multimodule project and provide the precompilation Processor as an independent module that depends on 1.6 even though the core does not? I feel favorable towards this approach because it makes enabling the precompilation a very explicit act, and gives the user the opportunity to exclude the Processor from his runtime deployment.

        Matt

        P.S. the com.sun.codemodel code I mentioned before is in fact working now

        Show
        Matt Benson added a comment - This was left as a problem: Simo's initial implementation of this was done against Java 5 APT. [digester] currently supports Java 5, but its CI systems (Continuum in particular) are using a Java 6 installation. To be forward-looking and use the Java 6 Processor , etc. APIs, is it reasonable to say: [digester] 's runtime code uses only Java 5 APIs [digester] includes a Java 6 Processor that "precompiles" [digester] annotations into configured {{RulesModule}}s. [digester] 's build is configured with source 1.6, target 1.5 ? Is this a workable approach, or does the Processor stuff break down on the third point? If so, would it be simpler to convert [digester] to a multimodule project and provide the precompilation Processor as an independent module that depends on 1.6 even though the core does not? I feel favorable towards this approach because it makes enabling the precompilation a very explicit act, and gives the user the opportunity to exclude the Processor from his runtime deployment. Matt P.S. the com.sun.codemodel code I mentioned before is in fact working now
        Hide
        Simone Tripodi added a comment -

        always amazing feedbacks from you, Matt!!!

        I think that the suggested multi-module approach sounds the way to go! I will take care of it as soon as I get a cycle to dedicate to Digester and moving forward this issue from its status of problem to a feature

        Show
        Simone Tripodi added a comment - always amazing feedbacks from you, Matt!!! I think that the suggested multi-module approach sounds the way to go! I will take care of it as soon as I get a cycle to dedicate to Digester and moving forward this issue from its status of problem to a feature

          People

          • Assignee:
            Simone Tripodi
            Reporter:
            Simone Tripodi
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development