Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)

[Mark Hindess <ma...@googlemail.com>]

On 20 June 2006 at 14:18, Paulex Yang <pa...@gmail.com> wrote:
> Seems no one objects this proposal:), so I'm going to implement the
> JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578,
> Because this implementation requires some native codes, so I probably
> need to reintroduce hynio.dll(.so), but I have some questions.(Excuse
> me about my ignorance on the native layout evolution).
>
> At first, seems native codes will be separated into modules(I guess
> Oli is working on?), so should I assume my native codes will be
> directly put into nio modules, or still in native-src/win.IA32/nio
> directory? because I'm used to provide a shell to move/svn add new
> files in the patch, so it will be easier for me to know how others
> think about it.

If you aren't planning on waiting until Oliver has done at least some of
the moves, then assume the old/current locations of native-src/*/nio.
(I assume this will mostly be shared?)

If you are planning on waiting, then use Oliver's work as a template for
how the native build should proceed.

(Personally, I'm waiting before doing the awt/swing native source
integration.)

> And second, the native codes probably need portlib, so the portlib's
> header file must be accessible, say, portsock.h, but now it has been
> moved into luni/src/main/native/blabla, should I include one in my
> patch so that nio module can have a copy? or the header file itself
> should be put some other well known directory(deploy/build/include I
> guess)?

Yes.  Since this header forms part of the API it probably should be
moved to deploy/include at build time - like the other headers for the
classlib natives API.

No code should reference the native source of another module directly
only via the deploy tree.

Regards,
 Mark.



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)

[Tim Ellison <t....@gmail.com>]

Paulex Yang wrote:
> Mark Hindess wrote:
<snip>
>> Yes.  Since this header forms part of the API it probably should be
>> moved to deploy/include at build time - like the other headers for the
>> classlib natives API.
>>   
> I see, but seems not all header files in LUNI are copied into
> deploy/include now, for example, portsock.h. So is there any rules which
> one is copied and which one is not?

It should be all headers that are available externally to the module
(i.e. just not those that are local impl. functions) so I would have
expected portsock.h to be in there.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)

[Paulex Yang <pa...@gmail.com>]

Mark Hindess wrote:
> On 20 June 2006 at 14:18, Paulex Yang <pa...@gmail.com> wrote:
>   
>> Seems no one objects this proposal:), so I'm going to implement the
>> JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578,
>> Because this implementation requires some native codes, so I probably
>> need to reintroduce hynio.dll(.so), but I have some questions.(Excuse
>> me about my ignorance on the native layout evolution).
>>
>> At first, seems native codes will be separated into modules(I guess
>> Oli is working on?), so should I assume my native codes will be
>> directly put into nio modules, or still in native-src/win.IA32/nio
>> directory? because I'm used to provide a shell to move/svn add new
>> files in the patch, so it will be easier for me to know how others
>> think about it.
>>     
>
> If you aren't planning on waiting until Oliver has done at least some of
> the moves, then assume the old/current locations of native-src/*/nio.
> (I assume this will mostly be shared?)
>
> If you are planning on waiting, then use Oliver's work as a template for
> how the native build should proceed.
>
> (Personally, I'm waiting before doing the awt/swing native source
> integration.)
>   
I see, thank you for the explanation.
>   
>> And second, the native codes probably need portlib, so the portlib's
>> header file must be accessible, say, portsock.h, but now it has been
>> moved into luni/src/main/native/blabla, should I include one in my
>> patch so that nio module can have a copy? or the header file itself
>> should be put some other well known directory(deploy/build/include I
>> guess)?
>>     
>
> Yes.  Since this header forms part of the API it probably should be
> moved to deploy/include at build time - like the other headers for the
> classlib natives API.
>   
I see, but seems not all header files in LUNI are copied into 
deploy/include now, for example, portsock.h. So is there any rules which 
one is copied and which one is not?
> No code should reference the native source of another module directly
> only via the deploy tree.
>   
Agree.
> Regards,
>  Mark.
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org