harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kev Jackson <kevin.jack...@it.fts-vn.com>
Subject Re: Backward compatibility
Date Thu, 12 May 2005 02:32:47 GMT

>> Deprecated or non deprecated, we want Harmony to pass the TCK, so 
>> whatever the TCK wants us to do, we'll do it.
I would have thought that it must pass the TCK to have any chance of 
wide acceptance, so presumably that means implementing depracted code 

> 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?)


View raw message