Re: API Differences

[Daryl Lee <dlee at altaregos dot com>]

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.