From dev-return-32272-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Feb 26 05:12:31 2008
Return-Path:
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 95147 invoked from network); 26 Feb 2008 05:12:31 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 26 Feb 2008 05:12:31 -0000
Received: (qmail 27311 invoked by uid 500); 26 Feb 2008 05:12:25 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 27279 invoked by uid 500); 26 Feb 2008 05:12:25 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 27270 invoked by uid 99); 26 Feb 2008 05:12:25 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Feb 2008 21:12:24 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of firepure@gmail.com designates 64.233.166.180 as permitted sender)
Received: from [64.233.166.180] (HELO py-out-1112.google.com) (64.233.166.180)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Feb 2008 05:11:51 +0000
Received: by py-out-1112.google.com with SMTP id a25so2628702pyi.13
for ; Mon, 25 Feb 2008 21:12:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
bh=YGFAcwwNkBHkhX9RHQFsPqbUkSh2/Dq7ZF+W6J8PSZw=;
b=O9nokeCa8EiXf4MpLyrExElXKh0pjfvQU+mt85YT7cBTP7dLA91H4WdnG2zzIX/dq7m8JTjlBO8vCI6p0ZDNRuHjlz9kUi7UxE+J48GifcgYnpc6SR8RwrKDE9zQ2AdWAwCcqXs/lJ4cYBqoiZXndnO0U9kPyboUv1fnvOVc0zI=
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=rzbC6vQ4kplvh/fLhDcU/gpPvkzB9WkFgvDTvbemBX0+J5vW4HcQJrGqyjkfRr7IIf9V+xpJqgZgkBRKHc7IjpTKczuU+tSZe8k5/A7YxpQSj+GTitwsAznArasqdrkERFf3Hizp9q5Of180ypD7XqEsWwzPX+UZXbAGdzUyiaQ=
Received: by 10.65.220.8 with SMTP id x8mr8474289qbq.39.1204002720247;
Mon, 25 Feb 2008 21:12:00 -0800 (PST)
Received: by 10.65.112.16 with HTTP; Mon, 25 Feb 2008 21:12:00 -0800 (PST)
Message-ID: <5c8e69f0802252112i22afcac3v1560dce021f1f2d1@mail.gmail.com>
Date: Tue, 26 Feb 2008 13:12:00 +0800
From: "Jimmy,Jing Lv"
To: dev@harmony.apache.org
Subject: Re: [general] Should we make portlib a separate component?
In-Reply-To: <47A77724.8060805@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200802041518.m14FIrGi017046@d06av04.portsmouth.uk.ibm.com>
<47A77724.8060805@gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org
2008/2/5, Tim Ellison :
> Mark Hindess wrote:
> > Should portlib be a separate component like classlib, drlvm, jdktools,
> > etc.?
> >
> > Currently portlib is closely associated with classlib. It is built in
> > the same way as any other classlib module. But really it isn't just
> > another classlib module. It's a porting layer for classlib, DRLVM,
> > jdktools, etc.
>
>
> Well it isn't today. DRLVM and jdktools do their own thing, so it
> really is just a factoring of the class library code.
>
>
> > It is suppose to have a well-defined API ... but we changed the API
> > without a second thought when the patch for HARMONY-2236, for example,
> > was committed. I'm under no illusions that having portlib as a separate
> > component will stop this happening but I think it would help us think
> > about it a little differently.
>
>
> I don't see why this a problem. We have control over both sides of the
> API boundary, so changing the API to suit a usecase better is fine,
> provided the implementation and its usage is changed simultaneously --
> and it was.
>
> We don't promote the portlib APIs for our end users to use. If we did
> then of course we would have to be more careful. Even internally, like
> the VMI, we are careful when there are internal users.
>
>
> > It would also enable us to apply versioning (branching/tagging) to
> > portlib separately from classlib which in turn would allow us to
> > manage changes to the API more easily. Classlib/DRLVM could make
> > compile/runtime decisions based on the version of the portlib API that
> > is found.
>
>
> I see what you are saying, but again, I'm yet to be convinced there is a
> problem being solved here. Why not also version control the hycommon,
> hythread, etc internal APIs too?
>
>
> > Separate versioning of this component should make it easier to make
> > changes and extend the portlib to cover additional requirements. For
> > example, to better support DRLVM, particularly if it moved away from
> > using APR which I seem to recall was mentioned (again) recently.
> >
> > It would also give us the flexibility to choose to have portlib use a
> > different build mechanism in future - such as autoconf - if we decided
> > that was more suitable for a pure native code component.
> >
> > Comments?
>
>
> I don't have a strong objection to moving it out to a 'top level'
> component -- it just seems premature when there is no pressing need to
> do so. If somebody declared a porting problem, or DRLVM gurus said they
> want easier access to use it then sure. Perhaps there is a driver that
> I'm not seeing here.
>
> It sounds like it is just a move within the project, not a re-architecture.
>
I have a request here, that JDWP may use portlib to port to all
platforms and facilitate the development and refactor. As a result,
moving portlib to top-level may be a good way for build?
> Regards,
>
> Tim
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM