"is-getter" for Boolean?

[glassfishrobot]

I'm not sure about the subcomponent; please re-assign if possible.

JAXB 2.0 (used by XFire JAXB binding) generates getters for Boolean (wrapper type) with "is", rather than "get".

AFAIK the JavaBeans spec only defines "is" for boolean, not Boolean.

Environment

Operating System: All Platform: All

Affected Versions

[2.0 EA1]

[glassfishrobot]

Reported by goonie

[glassfishrobot]

kohsuke said: This behavior is governed by the spec, and unfortunately it's just too late for the spec to change now.

In terms of the user experience, thanks to auto-boxing, I don't think this will be a real issue for people. Is the problem that you are using Introspector and it's missing the property?

[glassfishrobot]

goonie said: In this specific case, the object mapper "Dozer" misses the getter and needs to be configured with exception rules for each Boolean property.

Each framework or application that deals with JavaBeans (POJOs) will fail. A very common case will be implementations of the javax.persistence API, like Hibernate.

What's an early access good for, if there cannot be changes any more? This is a rather un-intrusive change, you could even allow for backwards compatibility if you fear that already existing implementations will fail.

I don't understand your argument of auto-boxing. Method invocations are not auto-boxed (by Java5). Could you explain?

[glassfishrobot]

kohsuke said: Yes, early accesses are to solicit feedback, and we've been doing just that for the past year or more. But it's also true that we have to stop accepting feedback and ship at some point, or otherwise we can never ship anything. And unfortunately, that time is now.

I don't know if you've seen this or not, but we just released the release candidate of the RI, and the spec has already or is shortly going to go for the final vote in JCP. So the kind of fixes we can make at this point for 2.0 is fairly limited, and this is clearly not one of them, since this is very much an intrusive change — any change that makes a difference in the generate signature is an intrusive change.

I re-opened issue for 2.0.1 as an RFE to see if there's anything we can do. But the thing is, since the spec decides the signature that we generate, we can't really just "fix" this in the RI. There's a backward compatibility aspect, too — if we change the generated signature, it causes a trouble to a lot of people.

But perhaps you (or someone) might be able to write a plugin to fix this, or we might be able to have a vendor-extension customization.

The reason I mentioned auto-boxing is that you can write:

boolean b = foo.isBar();

even if isBar returns Boolean.

[glassfishrobot]

kohsuke said: Linking related topics: http://forums.java.net/jive/thread.jspa?threadID=15779

[glassfishrobot]

gturner@java.net said: FYI for anyone stumbling upon this bug, here's a work-around. Pass your Schema through the following XSLT before XJC:

<xsl:stylesheet xmlns="...target namespace here..." xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xalan="http://xml.apache.org/xalan" version="1.0" exclude-result-prefixes="xalan">

XBoolean exists only as a work-around to JAXB bugs [https://jaxb.dev.java.net/issues/show_bug.cgi?id=555](https://jaxb.dev.java.net/issues/show_bug.cgi?id=555) and [https://jaxb.dev.java.net/issues/show_bug.cgi?id=131](https://jaxb.dev.java.net/issues/show_bug.cgi?id=131). The use of this type declaration is slightly invalid, it exists to replace boolean, which may have lexical values "0" or "1" in addition to "true" or "false", this type is derived from NCName in order to get JAXB to generate an enum, NCName does not allow the values "0" or "1" (may not start with a digit). XBoolean In my particular case (using Apache Commons BeanUtils) I had to create an additional Converter to marshal String to XBoolean, no big deal since I have already created Converters for Duration and XMLGregorianCalendar classes.

[glassfishrobot]

snajper said: This is already fixed for 2.2 (so that we don't break compatibility for 2.1.x line).

[glassfishrobot]

snajper said: reopening to close with correct status

[glassfishrobot]

snajper said: We are not allowed to deliver the fix to 2.2 because of compatibility reasons.

[glassfishrobot]

snajper said:

• • • Issue 679 has been marked as a duplicate of this issue. ***

[glassfishrobot]

snajper said: Added -enableIntrospection switch to XJC.

[glassfishrobot]

snajper said: Re-closing with proper status.

[glassfishrobot]

Issue-Links: duplicates JAX_WS-922

[glassfishrobot]

Was assigned to jaxb-issues

[glassfishrobot]

This issue was imported from java.net JIRA JAXB-131

[glassfishrobot]

Marked as fixed on Thursday, April 15th 2010, 12:12:16 am