I fully agree with this proposal. It makes at least a common native resource manager easier for native memory, file handles, etc.
Thanks, xiaofeng On Feb 4, 2008 11:18 PM, Mark Hindess <[EMAIL PROTECTED]> 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. > > 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. > > > -- http://xiao-feng.blogspot.com
