[PATCH] [MinGW]: Reset/Ignore Thread Interruption for Plain[Datagram]SocketImpl

[Bryce McKinlay]

On Dec 15, 2003, at 2:08 PM, Mohan Embar wrote:

>>> If you're interested, take NetTest.java (attached here):
>>>
>>> http://gcc.gnu.org/ml/java-patches/2003-q4/msg00736.html
>>>
>>> ...for a spin under Sun's JRE as well as both pre-patch and
>>> post-patch gcj and see what you think.
>>
>> Thats a nice test. Have you thought about adapting it into one or more
>> mauve tests?
>
> I have. I really do want to be a team player and figure all of this 
> stuff
> out. Is there any link that talks about the different tests: jacks, the
> libjava tests, Mauve and what a POSIX person typically does to certify
> his or her stuff? I'm still confused and overwhelmed by this.

Jacks = generic compiler test suite. language-lawyer stuff. Tests 
language features and stresses parser, semantic analysis etc. Tests 
compilation, not class libraries.
Mauve = generic java class library test suite, organized hierarchically 
by packages & classes.
libjava/testsuite = GCJ-specific tests. Mostly tests for regressions 
for specific bugs that have been found in gcj/libgcj. Includes both 
compiler and runtime tests. Good place to put a "quick and dirty" 
regression test for a patch, but more extensive test cases should go 
into mauve.

Writing a mauve test is pretty easy. I suggest just copying one of the 
existing tests to use as a starting point, paste in your own code, and 
call check() or fail() at the right times.

To run a specific test, I do something like:
./configure --with-gcj
make
echo gnu.testlet.java.net.MyTest | ./SimpleTestHarness

The tags/keys system that mauve uses can be a little awkward since you 
may need to re-run "make" with a different KEYS argument in the event 
that your test doesn't have one of the default tags. The libjava-mauve 
file included with GCJ gives a good set of defaults, though.

Incidentally, I've wondered if it would be worthwhile porting mauve to 
use JUnit rather than its own proprietary test harness. This way we'd 
get the benefits of a well-tested, industry standard test architecture 
with an API that is immediately familiar to most Java developers. It 
also has a nice GUI for running tests (in addition to the command 
line). Porting our tests to JUnit would be a pretty mechanical affair - 
the calls have different names, but conceptually the APIs are pretty 
similar.

Regards

Bryce.