Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 62194 invoked from network); 12 May 2005 02:31:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 May 2005 02:31:11 -0000 Received: (qmail 55824 invoked by uid 500); 12 May 2005 02:34:59 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 55560 invoked by uid 500); 12 May 2005 02:34:57 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 55546 invoked by uid 99); 12 May 2005 02:34:57 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from Unknown (HELO mail.fts-vn.com) (210.245.44.131) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 11 May 2005 19:34:57 -0700 Received: from sg0104.fts-vn.com ([172.16.1.104]) by mail.fts-vn.com with esmtp (Exim 4.50) id 1DW3TF-00044D-At for harmony-dev@incubator.apache.org; Thu, 12 May 2005 09:30:41 +0700 Message-ID: <4282C04F.5050801@it.fts-vn.com> Date: Thu, 12 May 2005 09:32:47 +0700 From: Kev Jackson User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: Backward compatibility References: <3498248664443aa9f97730bdc9bc0615@gmail.com> <428236A8.5090805@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 {--} X-Spam-Report: Spam detection software, running on the system "jupiter.fts-vn.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > >> 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 [sigh]. [...] Content analysis details: (-2.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.8 ALL_TRUSTED Did not pass through any untrusted hosts X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N > >> 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 [sigh]. > 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