Marina Goldburt wrote:
> The patch is only an experiment to change the internal portlib
> implementation, that, as I think, reveals some design/implementation
> problems of the luni module.

Please elaborate.

I'm pleased that you are looking at this code, but may I suggest that
you make a point of talking to people here early rather than crafting a
large patch in silence.  Firstly, it means that we all learn from your
learning experience; and secondly if there is some doubt over the
approach you will hear about it quicker.

Sorry if that sounds negative, but I'd hate to see your hard work and
enthusiasm wasted.

Regards,
Tim


> I think, it makes sense to move all platform-specific code of the luni into
> the portlib. And in parallel to cooperate with the APR developers "on
> making
> it possible to use APR without pools" - that, of course, the main problem
> that makes the APR not suitable for JVM needs.
> 
> By the end of the process We'll have platform independent interface to
> operating system functionality, that covers all the luni needs,
> isolating in
> the portlib and can switch the portlib implementation to APR (if it have
> the
> appropriate memory model by the moment).
> 
> Marina.
> 
> On 7/4/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>>
>>
>> On 4 July 2006 at 13:13, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> > Marina Goldburt wrote:
>> > > Hi,
>> > >
>> > >
>> > >
>> > > To support the idea mentioned in the letter
>> > >
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/
>>
>> > [EMAIL PROTECTED],
>> > >
>> > >
>> > > I've tried to implement the file I/O  part of the Harmony portlib
>> using
>> > > APR.
>> > >
>> > > The JIRA issue with the patch is
>> > > http://issues.apache.org/jira/browse/HARMONY-751.
>> > >
>> > >
>> >
>> > I wouldn't want to tie us to APR like this - I can see us offering an
>> > "APR port" that is a peer to the native Windows and Linux.ia32 ports
>> [it
>> > would be fun to test performance differences], but not make it the
>> core,
>> > shared implementation.
>>
>> +1
>>
>> I'd always imagined it would progress this way until it was in a
>> position to supplant the current ports.
>>
>> -Mark.
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to