I would have thought that it must pass the TCK to have any chance of wide acceptance, so presumably that means implementing depracted code [sigh].
Deprecated or non deprecated, we want Harmony to pass the TCK, so whatever the TCK wants us to do, we'll do it.
So what's the point? If all you're trying to do is duplicate J2SE 5, what advantage is there to making it an open source project? As soon as you "improve" something, aren't you're likely to break the API?
The point I'd make is that just because you have to implement deprecated code to make it pass teh TCK doesn't mean you have to do a particularly good job at it. For example to implement some deprecated code will take 2 days (bear with me figures pulled from /dev/null) if you actually care about the performance, or 5 minutes and another 5 for the unit test just to ensure that the code does what you think it does. Should we spend any time optimizing deprecated code so that deprecated apps run as fast on harmony as on Sun J2SE? I'd argue no, for the simple reason that most of the stuff that's deprecated has been for a *long* time, and if you haven't refactored by now, you need to rethink your job as a professional developer (granted some apps can't be refactored, but then will they be contenders to run on Harmony?)
Kev
