This is the mail archive of the
mauve-discuss@sources.redhat.com
mailing list for the Mauve project.
Re: API Differences
This is VERY helpful. So helpful, in fact, that the very first two lines
of output (in the java.io section) raise a general question on testing.
In the transition from JDK 1.1 to JDK 1.2, Sun redefined the behavior of
the FileOutputStream(String) constructor. In 1.1, it threw an IOException;
in 1.2 (and through 1.4), it throws a FileNotFoundException.
Since there is only one implementation of the API, and since it is trying
to be as up to date as possible, a specification change such as this will
inevitably cause a failure of a 1.1 test, where a 1.2 (or later) test will
pass. The general question is "How to handle such changes?" Or am I
missing something, like the existence of a classpath archived to the JDK
1.1 spec?
On Thu, Dec 26, 2002 at 08:45:34PM -0500, Brian Jones wrote:
> Daryl Lee <dlee@altaregos.com> writes:
>
> > Having completed the java.io JDK 1.1 tests, I am now ready to move on to
> > the 1.2 tests, but I need an efficient means of knowing the differences
> > between the two versions of the APIs. Is there a tool I can use that will
> > identify exactly what needs to be tested?
>
> japicompat/japize can be used for this purpose. Take the 1.1 and 1.2
> files from the japize website and run japicompat to compare them.
>
> > An associated question has more to do with the mauve 'choose' script, which
> > looks more and more like Greek everytime I try to figure out how it works.
> > If I specify JDK1.2 in mauve-classpath, will it cause the selected JDK1.0 and
> > JKD1.1 tests to be run as well as any JDK1.2 tests I create? (Please say
> > yes!) A corollary question is, "What is the difference between the 'uses:'
> > declaration in mauve tests and the standard Java 'import' statement?"
>
> Yes, it will do what you think and select the previous version tests
> as well. Uses is for the choose script... or other scripts, to know
> that test foo in foo.java also uses bar in bar.java (must be in same
> package currently). So it would be nice in some cases to avoid code
> duplication of utility methods useful to a particular subset of tests.
>
> Brian
> --
> Brian Jones <cbj@gnu.org>
>
--
Daryl Lee
Open the present--it's a gift.