On 4 February 2008 at 20:35, Tim Ellison <[EMAIL PROTECTED]> wrote: > 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.
I think you'll find DRLVM does several of its own things ;-) *and* that one of them is portlib - see: vm/port/src/logger/logger.cpp I'll comment on the rest of your message in the morning. -Mark. > > 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. > > Regards, > Tim >
