Suppress compiler warnings on JAXB generated classes

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.

Hambley

How many different kinds kf warnings are you getting on your generated JAXB model? – Luhey

About 95% of warnings can be broken down to two categories. One is about extranous generic type declaration (JAXB doesn't use the Java 7 diamond operator) and the other one is about non-nls String literals not being externalized. There are a few others and generally we don't care about any of them. – Hambley

We have the same issue and are using option 4 in our project. If you think Atkassuans plugin is too large, you might want to create your own plugin that just add that annotation. It should only be a few code lines. You might even publicize it so we all can get rid of this problem :). See docs.oracle.com/cd/E17802_01/webservices/webservices/docs/2.0/… – Antananarivo

@BlaiseDoughan FYI, I'm getting a bunch of "Dead Code" warnings from the plugin that makes toString(), hashCode() and equals(). – Floreated

@flaschenpost Agreed - it seems like the least fussy and "most proper" solution at present. – Hambley

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>

Illative

Thanks for detailed answer, especially the correct syntax in the custom binding. – Auriga

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.

Premature

Ah, I also found JAXB-1053, but I completely disagree with "can't be applied yet". Maybe I'm very old-school, but once upon a time there have been command-line options to enable one program to create different outputs. Unfortunately I can't write that in JAXB-1053 (since I'm not member of that forum). – Auriga

@Auriga You can register on java.net, this is not a problem. Concerning the CLI option to produce warnings-free code on - well, this is surely an option but also an additional configuration dimension. I don't say it's impossible, it's just effort. And what you alsways have to consider is that Oracle faces huge "don't break existing solutions" responsibility on customer-facing APIs (XJC being one of them). – Premature

@Premature Thanks, I didn't intend to be bashful in any way with my remarks - it simply seemed like an complete overkill for such a trivial use case. I was convinced there had to be an easy solution without external deps which I had overlooked but turns out there isn't. However, I have amended my question with ownership clarification. I have also added a couple of other workarounds we were considering. In the end, we migrated to Eclipse 4.4 and hid the warnings but I didn't think such solution warrants a separate answer. I have up-voted both your answers (they propose reasonable solution(s)). – Hambley

@Quantum No, no, don't worry, I did not interpret it as "bashful". :) I just wanted to update the topic to the current state of affairs and add a clarification on a few things. No worries. :) – Premature

@Quantum I also think that your question and approaches you listed provide valuable context to the interested users. Thumbs up. :) – Premature

At the time of writing, JAXB-1053 only has one vote (by me, a moment ago). I suggest that all those who think this is important should also vote for the issue. – Seductive