Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (nike.apache.org: 195.212.29.136 is neither permitted
 nor denied by domain of mark.hindess@googlemail.com)
Message-Id: <200802041518.m14FIrGi017046@d06av04.portsmouth.uk.ibm.com>
From: "Mark Hindess" <mark.hindess@googlemail.com>
To: "Apache Harmony Dev List" <dev@harmony.apache.org>
Subject: [general] Should we make portlib a separate component?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 04 Feb 2008 15:18:50 +0000


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.

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.

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.

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?

Regards,
 Mark.