Annotation processor

Thread view:

Antti - 29 Jun 2007 14:40 GMT

Hi,

I wonder if anyone knows about an annotation processor that would make
the compilation timestamp of a class available within a jvm?

I have only scratched the surface of the guide for using 'apt' and am
not even sure this is the way to do it. If it is, a 'roll your own'
solution is not outruled, but not preferable either.

--
Antti

Reply to this Message

Arne Vajhøj - 01 Jul 2007 00:51 GMT

> I wonder if anyone knows about an annotation processor that would make
> the compilation timestamp of a class available within a jvm?
>
> I have only scratched the surface of the guide for using 'apt' and am
> not even sure this is the way to do it. If it is, a 'roll your own'
> solution is not outruled, but not preferable either.

Does classes contain an annotation with compile time ?

If not then you can not solve the problem this way.

Arne

Reply to this Message

Roedy Green - 04 Jul 2007 03:46 GMT

>Does classes contain an annotation with compile time ?

I don't see any sign of one included by default.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Antti - 04 Jul 2007 09:36 GMT

On Jul 1, 2:51 am, Arne Vajh?j <a...@vajhoej.dk> wrote:

> > I wonder if anyone knows about an annotation processor that would make
> > the compilation timestamp of a class available within a jvm?
[quoted text clipped - 4 lines]
>
> Does classes contain an annotation with compile time ?

They may, but it would be generated, see below.

This would be the Annotation:

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.SOURCE)
@Target( {ElementType.TYPE} )

public @interface CompileTimestamp {}

And it would be used like this:

@CompileTimestamp
public class Foo{}

Implementation suggestions:

The annotation processor should modify Foo's source and insert/modify/
remove a constant field declaration containing the timestamp.
Clientcode would use reflection to find it out.

Alternatively a runtime annotation, eg 'CompiledAt', tag could be
inserted/modified/removed.

As a third alternative the annotation processor could completely
(re)generate a source containing a static Map<Class,Timestamp> and a
static getter to query for a Class' compilation timestamp.

Latter two solutions force client code dependent of another component,
however. On the other hand I am not sure if messing with sources not
completely generated by apt process is a good idea either.

> Arne

--
Antti

Reply to this Message

Piotr Kobzda - 04 Jul 2007 23:05 GMT

> The annotation processor should modify Foo's source and insert/modify/
> remove a constant field declaration containing the timestamp.
> Clientcode would use reflection to find it out.

Modifications of inputs is not allowed during annotation processing.

Quote from the Filer documentation:

"In general, processors must not knowingly attempt to overwrite existing
files that were not generated by some processor. A Filer may reject
attempts to open a file corresponding to an existing type, like
java.lang.Object. Likewise, the invoker of the annotation processing
tool must not knowingly configure the tool such that the discovered
processors will attempt to overwrite existing files that were not generated.

Processors can indicate a source or class file is generated by including
an @Generated annotation."

So, maybe when you annotate your classes with @Generated it would work?
But, even if it would, it sounds to me like an annotations processing
rules abuse, so I discourage that.

> Alternatively a runtime annotation, eg 'CompiledAt', tag could be
> inserted/modified/removed.

RetentionPolicy.CLASS is enough, but post-processing of a generated
class files is required, because 'apt' cannot do that (compiler's output
is not an input for processor rounds, even when a processor is used with
'javac'). Post-processing of a compiled class files could be supported
with some bytecode manipulation framework, e.g. ObjectWeb ASM.

> As a third alternative the annotation processor could completely
> (re)generate a source containing a static Map<Class,Timestamp> and a
> static getter to query for a Class' compilation timestamp.

Possible, but unnecessarily complicated IMHO. Easier version of that
approach would be (re)generation of a single meta-data resource (for
instance a compile-times.properties file with a simple
class-name=compile-time pairs), or separate meta-data resource for each
class.

> Latter two solutions force client code dependent of another component,
> however.

True, but that's the way (I think) annotation processing tools are
intended to operate -- by design the user input (a source code) is
read-only.

> On the other hand I am not sure if messing with sources not
> completely generated by apt process is a good idea either.

FWIW, I would do that simply transforming a class files (possibly only
these specially annotated) just after compilation. Consequently, all
Java standard tools for annotation processing seams to be useless in
your case to me.

HTH,
piotr

Reply to this Message

Annotation processor

Free Magazines