Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xiaofeng.li@gmail.com
 designates 209.85.198.241 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=fbUI9iPfSb4sAgG0zF6bQ/Cxapf+Vw1Pnbqzcq+42lwWbqzaZs8fy8T5+XHm+L6eFa
         HjH5J8cw6gTEEYgfGrUNkovfey3ZqmENZqoUIfRm4YSbX3AaMXufZoV1HrGPdB9NHO6R
         uJjEpHR3wQecRZNdfZnm+qhY4zNKJXlciGMxM=
Message-ID: <9623c9a50811170121j331b00f4rdbdd2e285caa9ca5@mail.gmail.com>
Date: Mon, 17 Nov 2008 17:21:52 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
In-Reply-To: <4921352C.6030907@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <bdbaeccd0811031931o16ab41c5oeac5a8f2f0140d92@mail.gmail.com>
	 <bdbaeccd0811120023h34792189haaea58cfc881de0f@mail.gmail.com>
	 <491AFABD.2070209@gmail.com>
	 <bdbaeccd0811122340l428b6687w60d4224a3fe48bea@mail.gmail.com>
	 <3b3f27c60811130643v27e44143xd58d7c88a915ac63@mail.gmail.com>
	 <491CF0C3.3010008@gmail.com>
	 <9623c9a50811132154i1b43942cx60653a55696f9cc2@mail.gmail.com>
	 <491D6DE7.2010702@gmail.com>
	 <9623c9a50811161936w1644adf8rf2c4f935ad7d1ddc@mail.gmail.com>
	 <4921352C.6030907@gmail.com>

On Mon, Nov 17, 2008 at 5:11 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Xiao-Feng Li wrote:
>> On Fri, Nov 14, 2008 at 8:24 PM, Regis <xu.regis@gmail.com> wrote:
>>> IMHO, it isn't negative to modularity of Harmony itself at developing time,
>>> but it is at deployment or runtime. For example, someone want to replace
>>> concurrent module with another implementation, he just need to replace the
>>> concurrent.jar, that's enough. But if we pack them into one big jar, he need
>>> to unpack, replace and pack again. That also work, but isn't convenient and
>>> straightforward.
>>
>> We can offer a build option to provide separate JARs if that's
>> desirable. Does anyone really need this feature?
>
> It is a desirable feature for people who consume only parts of Harmony,
> or who want to subset the runtime -- though I agree that there are
> multiple ways to solve that problem.

Ok, then let's provide the extra option.

Thanks,
xiaofeng

> As written elsewhere though, let's check we are solving the right problem.
>
> Regards,
> Tim
>
>


-- 
http://xiao-feng.blogspot.com