抑制JAXB生成的类的编译器警告

Question

This is possibly a duplicate of this question ( Avoiding Compiler warnings on code generated by xjc ) but since I am not very well versed in XJC/JAXB custom bindings idiosyncrasies, I'll presume I may have misunderstood the mentioned question.

My question seems simple enough - how can I add @SuppressWarnings("all") annotation to generated JAXB class? We have 0 warning policy on our project and after JAXB generation step, we end up with 350+ warnings which are just terrible noise.

I would expect either a simple flag on the XJC or at least an easy way to provide such info but I cannot find any.

From what I've seen in my travels, people do one of these things:

1. @lexicore's JAXB2 Annotate Plugin which, according to examples, seems to do the job but to add a whole framework and hundreds of kB of code just to add simple annotation to a bunch of classes? Really??,
2. Custom JAXB bindings (I may be mistaken but this seems very arcane and I am not fully sure if it were event possible to do it this way),
3. Custom ANT target which will do a search-and-replace post-JAXB generation,
4. Eclipse 4+ seems to have an option to filter out warnings on selected projects but for various historical/legacy reasons we're stuck on Eclipse 3.7.2 (Indigo),
5. Custom XJC plugin which would do the annotation insertion (as suggested by one of the commenters, see here ),
6. Placing all of the generated classes in a JAR, making the JAR a dependency of the project and then removing generated code altogether.

Formerly, we dealt with this by shoving the XML-related code in a separate Eclipse project and then disabling the warnings/errors on the project. Now, as part of code consolidation/refactoring, we've reshuffled things around and no longer have that luxury.

Is there really no elegant solution for such a seemingly trivial problem? Any feedback/thoughts are greatly appreciated.

FWIW, our project uses Ant as build system.

Answer 1

You have to use this plugin : jaxb2-annotate-plugin

2 solutions :

1 - Modify your xsd and add this kind of block

<xsd:element name="foobar" type="xsd:string">
    <xsd:annotation>
        <xsd:appinfo>
            <annox:annotate>@java.lang.SuppressWarnings("all")</annox:annotate>
        </xsd:appinfo>
    </xsd:annotation>
</xsd:element>

2 - Create a custom binding

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<jaxb:bindings
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:annox="http://annox.dev.java.net"
    xsi:schemaLocation="http://java.sun.com/xml/ns/jaxb http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd"
    jaxb:extensionBindingPrefixes="xjc annox"
    version="2.1">
    <jaxb:bindings schemaLocation="schema.xsd" node="/xs:schema">
        <annox:annotate target="class">@java.lang.SuppressWarnings("all")</annox:annotate>
    </jaxb:bindings>
</jaxb:bindings>

Answer 2

Disclaimer : I am the author of the jaxb2-annotate-plugin mentioned in @ToYonos answer.

This is not a standalone answer but rather an addition to @ToYonos answer.

I would like to address the following point from the question.

1. Annox plugin from Atlassian's JAXB2 Basics framework/project (according to examples, seems to do the job but to add a whole framework and hundreds of kB of code just to add simple annotation to a bunch of classes? Really??),

I just need to add a few notes:

• First of all, this is not "Atlassian's" framework/project. I am neither employee nor affiliated with Atlassian or Sun or Oracle (although I'm an official Sun/Oracle contributor). This is an indipendent open-source project not driven by any company.
• Next, jaxb2-annotate-plugin was moved to a standalone project , it is not longer part of JAXB2 Basics . It just got too large and deserved to be a standalone thing.
• Concerning "a whole framework and hundreds of kB of code".
  • jaxb2-annotate-plugin does not require or add ANY runtime dependencies to your code . If you annotations have runtime retention, you'll need the classes of your annotations in runtime, but it should be obvious.
  • jaxb2-annotate-plugin does indeed have a number of compile-time dependencies like javaparser which is used to parse annotations from Java syntax. Well, this is due to the fact the plugin has to do a lot of moderately advanced stuff like parse annotations from Java syntax and transform them to codemodel to add to the generated code. I personally don't think that a few hundred kBs in the compile time is a problem at all.

So, from my point of view, @ToYonos offered a reasonable workaround for the moment.

---

Now, how would a correct fix look like?

• The correct fix would be to fix XJC. Everything else is just a workaround.
• There is the JAXB-1053 issue for this problem. Iaroslav correctly points out that as long as 1.6 has to be supported, the diamond fix can't be applied.
• The CodeModel will have to be updated as well to support Java 7+ constructs.
• You could help by forking and providing a PR to XJC code on GitHub . However I could not say that PRs really do get applied. There are three of my PRs in the pipeline , for a month or so already.
• It is possible to write an XJC plugin which would override code generation. This is not easy but possible.

The correct fix does not look like an easy task, I'd opt to a workaround and wait for the vendor fix at the moment.