users@jaxb.java.net

java.lang.IncompatibleClassChangeError and JDK versions

From: William Press <wpress_at_bea.com>
Date: Wed, 17 May 2006 12:37:01 -0700

Greetings,

 

I am creating a JAVA client that calls against an API I generate from a
schema. I am then handing this client to a customer. Unfortunately,
when the customer (simulated by our test framework) tries to use the
client, the client throws a java.lang.IncompatibleClassChangeError when
it tries to call a method on an API object returned by ObjectFactory.
Interestingly, the customer/test doesn't get this when they call against
the API directly, only when the client calls against the API.

 

In all cases, everything (XJC, the client build, and the customer/test
code that calls against the client) has access to the same version of
JWSDP (1.6). So it's not a JAXB jar mismatch.

 

However, we do have some idiosyncrasies with the build environment and
JDK versions. I don't have much control over this, so I'm hoping to
find a solution within my dev environment parameters.

 

Here's the deal:

 

Our API and client build environment uses JDK 1.5.0 and Ant 1.6.5.

 

Some customer build/runtime environments use JDK 1.4.2, some use JDK
1.5.0. Thus, what I hand to the customer needs to be JDK 1.4.2
compatible.

 

Neither JDK (ours or the customers') has the JWSDP endorsed JARs copied
into it; however, we do set the java.endorsed.dirs property to the path
given in the JWSDP installation instructions. I'll note when we do this
below.

 

1. To create the Java API from the schema, we use XJC (version
1.0.5-b16-fcs, which comes with JWSDP 1.6). I do not use JXCTask, as
this picks up the JDKs xercesImpl.jar (which in our case is the version
associated with JDK 1.5.0). Instead, I use <java> and specify the
appropriate java.endorsed.dirs sysproperty. I know this works because
running ant with "-v" yields a warning using JXCTask that goes away when
we run using <java> with the java.endorsed.dirs property. The classpath
is set according to the XJC documentation (jaxb/lib/*.jar,
jaxp/**/*.jar, and jwsdp-shared/lib/**/*.jar).

 

2. To compile the API and the client (which calls against this
API), I use <javac> with the source and target attributes both set to
"1.4". I include the same classpath as above. The parameters for
building the API and the client are pretty much identical.

 

3. Our tests (which simulates the customer) set the
java.endorsed.dirs property when they run the code built against our
client.

 

Now, when we build and run our tests using JDK 1.5.0, we get a
java.lang.IncompatibleClassChangeError when the client calls against the
API. As I mentioned above, we do not have any problems calling against
the API directly.

 

When we try to build using JDK 1.4.2, we get an error saying that the
version in the class files is "49", where it should be "48".

 

It seems, then, that perhaps the source and target attributes for the
<javac> tag may not be having effect I'm expecting. Even if this were
the case, though, I would expect the JDK 1.5.0 test build and run to
work without problems.

 

Any light you can shed on this would be appreciated.

 

Thanks,

Bill