Feature Concept for Review: Mark generated methods as synthetic (Lombok + JaCoCo)

[dodtsair]

There is a previous thread under similar title. 

https://groups.google.com/forum/#!searchin/project-lombok/jacoco/project-lombok/IvwOjf0McvI/R5mHVw-WRX4J

The basic problem is that I want to ensure high code coverage because to me that means I know my code works.  I also do not want to spend a bunch of time testing boiler plate code.  Right now if I point jacoco at a lombok generated classes then it reports a ton of code that is all generated.  I do not want jacoco to measure this.

The original idea was to annotate the byte code to with a byte code specific concept of synthetic.  This was ruled out because that would remove the identifiers from code completion.

I thought I would propose an alternate solution to the same problem for community review. 

Option 1
Update the retention policy on Lombok annotations to Class.  This will allow code coverage tools to be configured to ignore lombok annotated methods. 

Option 2
Create a new annotation named GeneratedSource give it a retention policy of Class.  Code coverage tools can look for that annotation.

Note there are SuppressWarnings and Generated annotations in the jdk.  However their retention policies are set to Source.  So byte code analyzers never see them.  If there was a way to retain these annotations in the byte code that would work as well. 

Michael Power

[Fabrizio Giudici]

On Sat, 24 Aug 2013 09:37:20 +0200, dodtsair
<mpower...@alumni.calpoly.edu> wrote:

> There is a previous thread under similar title.
>
> https://groups.google.com/forum/#!searchin/project-lombok/jacoco/project-lombok/IvwOjf0McvI/R5mHVw-WRX4J

It's a problem for me too and I'd like to see a solution. Can somebody
please resume why the simpler approach of marking generated methods as
synthetic is not good?

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[eric.giese]

"It's a problem for me too and I'd like to see a solution. Can somebody  
please resume why the simpler approach of marking generated methods as  
synthetic is not good?"

IDE's won't show you the identifiers if I remember correctly. Also there is a conceptual problem. "Synthetic" methods in java are really just bridge methods generated internally by the compiler. These are used in example in generics when you create a new class with fixed generic parameters. Lombok however generates "normal" java code, not synthetic one. Otherwise code generated by lombok-apt and delombok would differ after compilation.

Considering javacoco:
There is no need to use lombok for this. Just include guava-testlib and use the ClassSanityTester, which automatically tests getters, setters, equals and hashcode. Sometimes you have to supply test sample objects, but its really easy.

Include it and your test coverage will sky-rocket:
http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/ClassSanityTester.java

[Roel Spilker]

I agree with Eric. But it's not just about IDEs won't show you the methods; even other code won't compile if they refer to synthetic methods that are generated in a different compile run.

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[dodtsair]

Yeah, so synthetic does not seem to work.  Is there another way this could be accomplished?

Does Java have any annotations that could be put on code and be retained in the class files.  SuppressWarnings is only retained on source so it would not work.  No way to force it to be retained in the class file?

Do annotations have to be available in the classpath?  Could we add a Generated annotation to the lombok jar and still use maven's provided scope?

[Fabrizio Giudici]

The problem with any bytecode-retention annotation, that could be
generated by Lombok, is that they require a small library to be in the
classpath. If I'm not wrong, there's nothing that Lombok does now and
requires an additional jar on the classpath *that is not explicitly
referenced from the source*. So it would be a departure from the today's
standard. It's also true that if you miss an annotation from the classpath
nothing wrong happens...

[Reinier Zwitserloot]

Fortunately, class retention and even runtime retention annotations _DO NOT_ require the related annotation to be on the classpath. If they aren't, then they are ignored entirely.

A class-level retention @Generated annotation would be fantastic, but lombok.Generated is probably not the appropriate name for this type; it's not lombok-specific, it's something that optimally should have been in java.lang.

[Roel Spilker]

We probably could annotate most of the code we generate as generated, like fields and entire methods, but @SneakyThrows, @Synchronized, @Cleanup and val only affect past of the code and copy some other part. I wouldn't knows how to annotate that, especially since annotation can (currently) only be put on packages, types, fields, methods, parameters and local variables, and not on a block or statement.

[dodtsair]

I agree, it really should have been in the jdk.  It actually kind of already is in the JDK: http://docs.oracle.com/javase/6/docs/api/javax/annotation/Generated.html

The problem with it is that the retention policy is set to Source.  I had this thought that while building the java code with lombok on the classpath it might be possible to violate the retention policy.

[Reinier Zwitserloot]

We can probably shove it in there (but it won't survive delomboking, but then perhaps the intent of delombok is in fact to strip @Generated too), but it'll never be a standard. We might as well just invent lombok.Generated and try and flog that.

 --Reinier Zwitserloot

--