Stuart Ballard writes: > Andrew Haley <aph <at> redhat.com> writes: > > > > This case is totally different: the test case is an illegal Java > > program. In no circumstances should Mauve contain illegal programs! > > While I disagree, I take your point, but I do take issue with your > terminology.
OK. > It's not an "illegal" Java program, it's a Java program with a > bug. If that makes it illegal, then every nontrivial Java program > is illegal. No, that's not what I mean by illegal. It's illegal in the sense that the specification places requirements on the implementors of subclasses, and that a subclass which does not meet these requirements is not a well-defined Java program. > My position is that the line between spec and RI is fuzzy, > especially in the case of Java (at least to date, and for the next > year or so). And while that's a bad thing, it's the reality we live > in. There's a lot of code out there that assumes that "Java" means > the RI. Until that changes, we need to decide whether our mission > is an ideological goal - "implement the spec" - or a practical goal > - "provide a way for users to run programs written in Java on a > Free system". Sure, we're in a weird halfway world. Maybe the famous Sun TCK even tests for this behaviour. > If our goal is the latter, then when a situation like this comes up > where lack of bug-compatibility is impacting an actual user's > ability to run actual code, then we should provide the > bug-compatibility for that situation, and take appropriate steps to > ensure that we don't regress on it. OK. I don't believe that illegal programs should be checked into Mauve, and I'm amazed that anyone does. I won't fight anyone who is determined to do so. > As an aside, there is at least one reason for Mauve to contain > illegal programs - the spec may require that a particular kind of > illegal program fails to run in a particular way or with a > particular exception. Sure. But, in that case, we are checking to make sure that it fails, which is reasonable enough. > > It is fully specified now. > > I disagree with this point too; a full specification should include > a description of how error situations are handled, or state that > it's explicitly implementation dependent. Programs whose behaviour is undefined *are* explicitly implementation- dependent, surely. It's not as though there were any doubt about this one. Andrew.
