The additional test cases which will not be announced until the final evaluation occurs

[tsdh]

The case description says that the correctness and completeness will also be validated with "additional test cases which will not be announced until the final evaluation occurs".

In my humble opinion, that's a very bad idea because it makes the case too open. My solution now works for all ARTE test cases but I'm very sure that there are dozens of cases which I haven't foreseen. Thus, I can easily spend the next few weeks in order to create my own tests and refine the solution until I'm confident that I can handle the complete Java spec with the exception of the parts the case description explicitly excludes. Unfortunately, I have other stuff to do and want to finish all my TTC solutions today (which is the original deadline).

So I'd very much welcome if you could just add these additional test cases to ARTE so that solution devs can start writing their solution descriptions with the good feeling that all tests pass. (I mean, if you would write that transformation for production use, you would test it with anything you can get, not just with 10 toy examples and then pass it to you customer and say "GO!", no?)

[tsdh]

Just to give some concrete example: currently my solution pulls up methods which have the same signature, and the signature doesn't account for the return type. But for PUM in the "real world", you actually cannot ignore the return type.

class S {};
class A extends S {Collection m() {...}}
class B extends S {ArrayList m() {...}}

In the example, pulling up B.m() would be valid but pulling up A.m() would not be valid because you can assign an array list to any collection variable but the reverse is not true.

That is, you can only pull up the method declaration with the most specific return type and all other method declarations must have a return type which is a subtype of that most specific type.

My current solution creates TClass objects only for the classes that are used in the user-defined code, i.e., there are TClass objects for S, A, B, Collection, and ArrayList but not more (which is nice for debugging because the PG can be visualized). Thus I cannot decide if ArrayList is a subtype of Collection.

That's not a big deal; I could either query the jamopp model which contains that information from the refactoring transformation or make the PG contain the information about every class on the CLASSPATH. But I actually like my solution in its conciseness as it is right now, so I don't want to add stuff which isn't needed anyway.

[SvenPeldszus]

We also like concise solutions :) The final test cases will not differ from the already known ones. Our intention was not to test some nasty corner cases which weren´t even mentioned. With the final test cases, we just wanted to reward in the final score those solutions which contain as less hard-coded parts as possible. As yours appears to be one of those, you don´t have to worry at all :)

[tsdh]

Ok then. :-)