Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30261 > unrolled thread

annotation metadata proposal

Back to article view | Back to comp.lang.java.programmer

Contents

  annotation metadata proposal boxzou@gmail.com - 2014-10-30 21:06 -0700
    Re: annotation metadata proposal Joerg Meier <joergmmeier@arcor.de> - 2014-10-31 07:46 +0100
    Re: annotation metadata proposal Arne Vajhøj <arne@vajhoej.dk> - 2014-10-31 20:53 -0400
      Re: annotation metadata proposal boxzou@gmail.com - 2014-10-31 20:26 -0700
    Re: annotation metadata proposal Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-01 00:33 -0400
      Re: annotation metadata proposal boxzou@gmail.com - 2014-11-01 07:50 -0700
        Re: annotation metadata proposal Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-01 20:42 +0000
          Re: annotation metadata proposal boxzou@gmail.com - 2014-11-01 15:56 -0700
            Re: annotation metadata proposal Robert Klemme <shortcutter@googlemail.com> - 2014-11-02 00:08 +0100
              Re: annotation metadata proposal boxzou@gmail.com - 2014-11-01 19:38 -0700
                Re: annotation metadata proposal boxzou@gmail.com - 2014-11-04 21:46 -0800
                  Re: annotation metadata proposal boxzou@gmail.com - 2014-11-04 21:50 -0800
            Re: annotation metadata proposal Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-02 00:31 +0000

#30261 — annotation metadata proposal

1. Problem:
Suppose I wrote 2 classes summer.sports.Soccer and winter.sports.Hockey each in their own jar (soccer.jar and hockey.jar).  Each class is annotation @Sport.  Now at runtime, I want to find all classes annotated with @Sport.

Scanning all jars is kinda expensive.

The alternative is to have a properties file where you can list all such classes or better yet packages that contain those classes.  Each jar file would have such a properties file.

But it is tedious to maintain such list.

Note I allow new sports jar added, I can not specify the packages using something like Spring framework's component:scan(packages) because I can not predict future.

I think tools can help.

2. Proposal:
    a) add an file in jar: META-INF/annotated-classes
    b) format: full.class.name:Ann1,Ann2, one class per line
    c) mvn plugin to generate META-INF/annotated-classes and package it in jar/war
    d) IDE: when building a project generate such entry and put in output folder (e.g. target/classes)
    e) provide library to read all META-INF/annotated-classes

What do you think?

Thanks.

Bo

[toc] | [next] | [standalone]

#30262

On Thu, 30 Oct 2014 21:06:08 -0700 (PDT), boxzou@gmail.com wrote:

> What do you think?

Consider: 

<https://github.com/rmuller/infomas-asl>

From the readme:

"This library can be used to scan (part of) the class path for annotated
classes, methods or instance variables. Main advantages of this library
compared with similar solutions are: light weight (no dependencies, simple
API, 20 kb jar file) and very fast (fastest annotation detection library as
far as I know)."

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#30263

On 10/31/2014 12:06 AM, boxzou@gmail.com wrote:
> 1. Problem:
> Suppose I wrote 2 classes summer.sports.Soccer and winter.sports.Hockey each in their own jar (soccer.jar and hockey.jar).  Each class is annotation @Sport.  Now at runtime, I want to find all classes annotated with @Sport.
>
> Scanning all jars is kinda expensive.
>
> The alternative is to have a properties file where you can list all such classes or better yet packages that contain those classes.  Each jar file would have such a properties file.
>
> But it is tedious to maintain such list.
>
> Note I allow new sports jar added, I can not specify the packages using something like Spring framework's component:scan(packages) because I can not predict future.
>
> I think tools can help.
>
> 2. Proposal:
>      a) add an file in jar: META-INF/annotated-classes
>      b) format: full.class.name:Ann1,Ann2, one class per line
>      c) mvn plugin to generate META-INF/annotated-classes and package it in jar/war
>      d) IDE: when building a project generate such entry and put in output folder (e.g. target/classes)
>      e) provide library to read all META-INF/annotated-classes
>
> What do you think?

That is practically the same as the properties file solution just with
automatic generation instead of manual maintenance.

But fundamentally I don't understand the approach.

You can have a file with a list of classes that are special.

Or you can add an annotation to classes that are special.

But I do not see the point in doing both.

If you drop adding the annotation to classes and instead just maintain
the list then it is only one manual change and you get the
functionality you want.

Arne

[toc] | [prev] | [next] | [standalone]

#30264

this mechanism allows you to only annotate claases without worrying about maintaining a file containing the list of classes.  the file approach has a few drawbacks:

1 you have to remember to write the file when you add a new module
2 you have to remember to add the class annotated

if one or two projects or a few classes, it's OK.  When you have 50+ projects and hundreds if not thousands of classes, it becomes tedious and daunting to maintain the files.  And the information is completely derivatives.

[toc] | [prev] | [next] | [standalone]

#30265

On 10/31/2014 12:06 AM, boxzou@gmail.com wrote:
> 1. Problem:
> Suppose I wrote 2 classes summer.sports.Soccer and winter.sports.Hockey each in their own jar (soccer.jar and hockey.jar).  Each class is annotation @Sport.  Now at runtime, I want to find all classes annotated with @Sport.
>
> Scanning all jars is kinda expensive.
>
> The alternative is to have a properties file where you can list all such classes or better yet packages that contain those classes.  Each jar file would have such a properties file.
>
> But it is tedious to maintain such list.
>
> Note I allow new sports jar added, I can not specify the packages using something like Spring framework's component:scan(packages) because I can not predict future.
>
> I think tools can help.
>
> 2. Proposal:
>      a) add an file in jar: META-INF/annotated-classes
>      b) format: full.class.name:Ann1,Ann2, one class per line
>      c) mvn plugin to generate META-INF/annotated-classes and package it in jar/war
>      d) IDE: when building a project generate such entry and put in output folder (e.g. target/classes)
>      e) provide library to read all META-INF/annotated-classes
>
> What do you think?

     I think: "*Why* do you need to find all the @Sport-annotated classes
at runtime?"

     I can see why it's useful to find all something-or-other classes (or
packages, or other things) at runtime: That's how things like Swing
look-and-feel implementions get found, not to mention crypto plugins,
fonts, and a good deal of other stuff that lives "in the environment."
My question isn't why you want to find something, but why you want to
use annotations as the search keys (or filters).  For one thing, it
seems rather limiting: You could only search for annotatable things,
so fonts and DLL's and other such artifacts would be forever invisible.

     In a follow-up, you refer to "hundreds if not thousands of classes,"
which makes me wonder whether class-at-a-time annotation is a scalable
way to organize things.  Isn't there a higher-level taxonomy of some
kind you could take advantage of?  How many thousands of sports are
there, anyhow?

     What is the problem you face?  Can you describe it concretely
without breaching too many confidences?

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#30266

I am developing a framework taking many plugins.  Each plugin will have Jersey ReST end points and batch components.  Right now each plugin has to be a WAR file to specify the component packages so Jersey knows where to look up the ReST end points.  The plugin also must list all the packages that contain batch components.  Jersey end points and batch components are all annotated with annotations.  There are also other classes with annotations, like configurations for each plugin (and its validation), custom configuration loaders, exception codes etc.  Since the framework does not know where to look for the annotated classes (a complete classpath scanning is too expensive), we use properties files to list the packages that contain the annotated classes. 

Right now each annotation mandates its own file.  We are considering consolidating into one single file.  Even so maintaining those files can be error-prone because such properties files contain derived information. Ideally the compile/IDE should be able to put such info in a file and build them as build artifacts.

That's the rational/thinking behind this proposal.
  
>      I think: "*Why* do you need to find all the @Sport-annotated classes
> at runtime?"
> 
>      I can see why it's useful to find all something-or-other classes (or
> packages, or other things) at runtime: That's how things like Swing
> look-and-feel implementions get found, not to mention crypto plugins,
> fonts, and a good deal of other stuff that lives "in the environment."
> My question isn't why you want to find something, but why you want to
> use annotations as the search keys (or filters).  For one thing, it
> seems rather limiting: You could only search for annotatable things,
> so fonts and DLL's and other such artifacts would be forever invisible.
> 
>      In a follow-up, you refer to "hundreds if not thousands of classes,"
> which makes me wonder whether class-at-a-time annotation is a scalable
> way to organize things.  Isn't there a higher-level taxonomy of some
> kind you could take advantage of?  How many thousands of sports are
> there, anyhow?
> 
>      What is the problem you face?  Can you describe it concretely
> without breaching too many confidences?
> 
> -- 
> esosman

[toc] | [prev] | [next] | [standalone]

#30267

On Sat, 01 Nov 2014 07:50:26 -0700, boxzou wrote:

> Right now each annotation mandates its own file.  We are considering
> consolidating into one single file.  Even so maintaining those files can
> be error-prone because such properties files contain derived
> information. Ideally the compile/IDE should be able to put such info in
> a file and build them as build artifacts.
>
Rather than manually maintaining the annotation-related properties files, 
why don't you use a program or script to scan the codebase for classes 
containing each target annotation and writes the names of the classes 
containing it to a configuration file. This should be a very simple job 
if you're running a development system that supports the 'find' utility. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#30268

> Rather than manually maintaining the annotation-related properties files, 
> why don't you use a program or script to scan the codebase for classes 
> containing each target annotation and writes the names of the classes 
> containing it to a configuration file. This should be a very simple job 
> if you're running a development system that supports the 'find' utility. 
That would be the parts 2c and 2d in my original proposal.

Seamless integration with unit tests in IDE and maven is the main problem to solve.

[toc] | [prev] | [next] | [standalone]

#30269

On 01.11.2014 23:56, boxzou@gmail.com wrote:
>> Rather than manually maintaining the annotation-related properties files,
>> why don't you use a program or script to scan the codebase for classes
>> containing each target annotation and writes the names of the classes
>> containing it to a configuration file. This should be a very simple job
>> if you're running a development system that supports the 'find' utility.
> That would be the parts 2c and 2d in my original proposal.
>
> Seamless integration with unit tests in IDE and maven is the main problem to solve.

It seems APT (the Java tool not to be confused with the debian package 
tool) would be the weapon of choice for compile time annotation 
processing.  That should integrate with Java tools.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#30271

> It seems APT (the Java tool not to be confused with the debian package 
> tool) would be the weapon of choice for compile time annotation 
> processing.  That should integrate with Java tools.
> 
Thanks a lot for the lead.  Found this:

http://deors.wordpress.com/2011/10/08/annotation-processors/

So IDE and Maven both have support.  Need to experiment how to generate a resource file now :)

[toc] | [prev] | [next] | [standalone]

#30278

> Thanks a lot for the lead.  Found this:
> 
> http://deors.wordpress.com/2011/10/08/annotation-processors/
> 
> So IDE and Maven both have support.  Need to experiment how to generate a resource file now :)

Here is the result of my experiment:

2 libraries:
    a) apt (pahakia-apt): at compile/build time, generate annotated classes info and store in META-INF/annotated-classes
        in both Eclipse and maven build
    b) annotation-registry (pahakia-annotation-registry): at runtime, process META-INF/annotated-classes.

Extra config in pom.xml (to enable annotation processing in IDE):
    https://github.com/pahakia/lib-test/blob/master/pom.xml
    search for maven-eclipse-plugin
    Note: pahakia-apt must be declared as project dependency in pom.xml

Test:
    https://github.com/pahakia/lib-test
    project: apt-test

Note:
1. The libraries are not published in maven central yet.
2. The annotated-classes file contains only classes that have annotation at the class level.

Thanks a lot for very one's help!

Bo

[toc] | [prev] | [next] | [standalone]

#30279

> 2 libraries:

forgot project location: 
    https://github.com/pahakia/lib
    projects: apt and annotation-registry.

[toc] | [prev] | [next] | [standalone]

#30270

On Sat, 01 Nov 2014 15:56:56 -0700, boxzou wrote:

>> Rather than manually maintaining the annotation-related properties
>> files,
>> why don't you use a program or script to scan the codebase for classes
>> containing each target annotation and writes the names of the classes
>> containing it to a configuration file. This should be a very simple job
>> if you're running a development system that supports the 'find'
>> utility.
> That would be the parts 2c and 2d in my original proposal.
> 
> Seamless integration with unit tests in IDE and maven is the main
> problem to solve.

Has it been tried, and if not, why not? 



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web