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

FYI, I've raised Harmony-646 and applied patch for this. Oliver Deakin wrote: Paulex Yang wrote: Oliver Deakin wrote: Paulex Yang 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 imp

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

Paulex Yang wrote: Oliver Deakin wrote: Paulex Yang 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

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

Oliver Deakin wrote: Paulex Yang 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

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

Tim Ellison wrote: Oliver Deakin wrote: Rebuilding a single component can also be done. For example, to rebuild the hyluni.dll you would: 1. cd to native-src//luni 2. set the HY_HDK environment variable to point to a directory where you have a complete prebuilt HDK (which could be the deploy

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

Oliver Deakin wrote: > Rebuilding a single component can also be done. For example, to rebuild > the hyluni.dll you would: > 1. cd to native-src//luni > 2. set the HY_HDK environment variable to point to a directory where > you have a complete prebuilt HDK (which could be the deploy dir if you > ha

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

Hi Jimmy, LvJimmy，Jing wrote: > Hi Oliver: > > I've seen the modularisation on native, that's great! :) But I have a > question here. > As I work on native before, I usually build the whole native code once, > and then make seperate modules alone, e.g., luni, or nio. It was easy to > enter directo

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

Hi Oliver: I've seen the modularisation on native, that's great! :) But I have a question here. As I work on native before, I usually build the whole native code once, and then make seperate modules alone, e.g., luni, or nio. It was easy to enter directory luni and force build by "make" and

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

Oliver Deakin wrote: Paulex Yang 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

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

Paulex Yang 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

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

Paulex Yang wrote: > Mark Hindess wrote: >> 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

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

Mark Hindess wrote: On 20 June 2006 at 14:18, Paulex Yang <[EMAIL PROTECTED]> 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 n

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

On 20 June 2006 at 14:18, Paulex Yang <[EMAIL PROTECTED]> 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 reintroduc

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

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 ignora

Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

Archie Cobbs wrote: Paulex Yang wrote: But after all, the implementation details(class name, fields/methods, etc) are different, so the idea is to provide the three JNI methods' implementation in NIO module, and add them into VMI, so that VM vendor can choose to add them into the JNI function

Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

Paulex Yang wrote: But after all, the implementation details(class name, fields/methods, etc) are different, so the idea is to provide the three JNI methods' implementation in NIO module, and add them into VMI, so that VM vendor can choose to add them into the JNI function table. I think this w

Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

Paulex Yang wrote: > I think the kernel class means the classes which heavily depends on VM > implementation, but the buffer is another story, it is the JNI actually > depends on Classlib implementation, so instead of put buffers into > kernel, I prefer to pull the three JNI methods out of VM into

Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

Jimmy, Jing Lv wrote: Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| * |GetDirectBufferAddress|

Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

Archie Cobbs wrote: Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| * |GetDirectBufferAddress|

Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| * |GetDirectBufferAddress|

Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

On 6/13/06, Paulex Yang <[EMAIL PROTECTED]> wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| < http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer > * |GetDirectBufferA

Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| * |GetDirectBufferAddress|

[classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer

There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| * |GetDirectBufferAddress|