harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy,Jing Lv" <firep...@gmail.com>
Subject Re: [general] Should we make portlib a separate component?
Date Tue, 26 Feb 2008 05:12:00 GMT
2008/2/5, Tim Ellison <t.p.ellison@gmail.com>:
> 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

View raw message