Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Mon, 10 Mar 2008 21:08:23 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Problem with addSuiteByReflection() on phoneME advanced platform
In-reply-to: <47D56CE0.9030304@sun.com>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x7y78q8hqg.fsf@ugle.localdomain>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <47D56CE0.9030304@sun.com>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (usg-unix-v)

Vemund Ostgaard <Vemund.Ostgaard@Sun.COM> writes:

> The past few days it has not been possible to run suites.All on
> phoneME advanced, junit will just exit with an
> InvocationTargetException when trying to invoke the suites.All.suite()
> method. Unwrapping the exception shows that the underlying reason is a
> NoClassDefFoundError from the invoke() call in
> AllPackages.addSuiteByReflection() when trying to load the new JMX
> suite.
>
> Now, this suite is compiled into 1.5 classfiles, so the
> Class.forName() call before the invoke() should have failed with
> UnsupportedClassVersionError. It does fail as expected when running
> with jdk 1.4, but on phoneME advanced it does not, I think it has to
> be a bug in phoneME advanced.

Not sure if it's a bug in phoneME. It sounds like the VM is able to read
the class file format of Java 1.5 and the class library is based on Java
1.4. Perhaps an odd combination, but not necessarily wrong.

> Now, I was pondering if it would make sense to also catch
> InvocationTargetException from the try block below, unwrap it and see
> if it is an instance of LinkageError and if so skip the
> testsuite. This would make it possible to run the tests on phoneME
> advanced, despite the bug. Any reason why this would be a bad idea?

Sounds like a good idea to me.

-- 
Knut Anders