Bug 363685

Comment 1 Sven Efftinge 2012-11-09 03:29:52 EST

*** Bug 387974 has been marked as a duplicate of this bug. ***

Comment 2 Sven Efftinge 2013-01-21 03:22:11 EST

We now have a compiler flag for enabling/disabling the synthetic @SupressWarnings("all").

We should respect @SupressWarnings in the validator, this could be integrated in a specialized IssueSeverities.

If synthetic suppress warnings is activated and a type declaration contains a manual @SupressWarnings, the manual one should not be generated.

Comment 3 Holger Schill 2013-01-21 04:40:41 EST

Created attachment 225878 [details]
Suggestion to fix this ticket

Comment 4 Holger Schill 2013-01-21 08:36:30 EST

Pushed fix to avoid manual @SuppressWarnings when synthetic @SuppressWarnings is enabled to master.

Comment 5 Sven Efftinge 2013-01-23 04:48:29 EST

unscheduling. I thought it was necessary to suppress unused warnings when using Java-black-box expressions in active annotations. But we decided to go with a different protocol.

Comment 6 Alexander Fichtinger 2013-07-30 05:16:17 EDT

I have the following scenario:

Active Annotation which generates 3 methods.

In an implementation class I declare just the field.

Example:

class ServiceAccessor {
	@Service ProjectIndexService projectIndexService
}

This implementation causes an "unused" warning.

It is VERY ANNOYING because there is no way to suppress it (even the xtend-maven-plugin does not have an option to deactivate this warning).

Comment 7 Sven Efftinge 2013-09-12 09:40:29 EDT

(In reply to Alexander Fichtinger from comment #6)
> I have the following scenario:
> 
> Active Annotation which generates 3 methods.
> 
> In an implementation class I declare just the field.
> 
> Example:
> 
> class ServiceAccessor {
> 	@Service ProjectIndexService projectIndexService
> }
> 
> This implementation causes an "unused" warning.
> 
> It is VERY ANNOYING because there is no way to suppress it (even the
> xtend-maven-plugin does not have an option to deactivate this warning).

This is covered in bugzilla #404167

Comment 8 K Kumar 2014-07-18 14:35:27 EDT

+1

Comment 9 Ed Staub 2014-07-18 16:41:59 EDT

One hack (of many) to work around this, is to do a double assignment:

    static MyPackage myPackage = myPackage = MyPackage.eINSTANCE  

This obviously doesn't work with finals.

Incidentally, the Ecore idiom above is the use-case that drove me to vote for this enhancement; eINSTANCE registers the package in the global package registry, which is sometimes needed early in static initialization.

Comment 10 Sven Efftinge 2014-07-19 02:01:22 EDT

(In reply to Alexander Fichtinger from comment #6)
> I have the following scenario:
> 
> Active Annotation which generates 3 methods.
> 
> In an implementation class I declare just the field.
> 
> Example:
> 
> class ServiceAccessor {
> 	@Service ProjectIndexService projectIndexService
> }
> 
> This implementation causes an "unused" warning.
> 
> It is VERY ANNOYING because there is no way to suppress it (even the
> xtend-maven-plugin does not have an option to deactivate this warning).

This bit is solved in 2.6 already. There's new API for active annotations that let's you flag a MutableField (markAsRead).

Comment 11 Lorenzo Bettini 2014-09-29 12:04:15 EDT

Just some additional information:

I don't mind @SuppressWarnings("all"), but
it looks like that this annotation will prevent Sonarqube from reporting
possible issues on the generated Java code (see
http://sonarqube.15.x6.nabble.com/sonarqube-findbugs-and-generated-sources-td5028237.html).

I tried adding an explicit @SuppressWarnings annotation, e.g., @SuppressWarnings("serial"), but the generated Java file still contains @SuppressWarnings("all")

Comment 12 Bouchet Stéphane 2014-10-17 09:02:04 EDT

hi,

in my case, i'm using checkstyle on my projects and the @SuppressWarnings("all") on top of every generated class reports no violations. ( of course :) )
I have to manually supress the annotation to have an analysis of the code.
I meanly use it for copyright header checks.

Comment 13 Miro Spönemann 2015-01-13 11:10:13 EST

Committed a change for release 2.8: @SuppressWarnings is not generated if it is already present in the Xtend source. This should help for the use cases mentioned above.

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=388749

What is left to be done for this bug:

(In reply to Sven Efftinge from comment #2)
> We should respect @SupressWarnings in the validator, this could be
> integrated in a specialized IssueSeverities.