You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Paulex Yang <pa...@gmail.com> on 2006/06/13 13:23:55 UTC
[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|
<http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer>
* |GetDirectBufferAddress|
<http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress>
* |GetDirectBufferCapacity|
<http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity>
Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?)
I propose to provide the implementation in NIO component, and I raise Harmony-578 for it. The idea is: export these three methods in NIO module as hynio.dll(.so), which is loaded by Harmony launcher, and add these methods to VMI in some way, so that the VM vendor(i.e., JNI implementation vendor) can add these methods to JNI function table.
Other choices I can imagine now include:
1. Add related direct buffers class to kernel class, so that the VM vendor can implement it as well as the JNI methods. IMO this is not good choice because buffers are actually VM independent, it's not reasonable to let VM vendor to implement these classes.
2. Provides some utility methods in o.a.h.nio, add these methods to VMI, so that VM vendor can get inside knowledge on the direct buffers by these utilities. This option is acceptable, but it also needs to modify VMI, and the modification is based on some Harmony specific contract, while my proposal above is based on public JNI spec, so this one is not preferred.
Any ideas and comments are highly welcome.
[1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html
--
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
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI
1.4 enhancement on ByteBuffer)
Posted by Paulex Yang <pa...@gmail.com>.
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 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.
>>>
>>> It depends on whether you want to wait for what I'm doing or not :)
>>> If you want to get the code out now, then you can temporarily put it
>>> under native-src/win.IA32/nio and I will move it later as part of
>>> the natives modularisation.
>>> However, if you don't mind waiting a day or so I should be able to
>>> submit my first patch to move the prefs natives. This ought to be
>>> enough of an example for you to put your native code directly into
>>> modules/nio/src/main/native.
>>>
>>>>
>>>> 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)?
>>>
>>> At build time, the "copy.native.includes" target in
>>> luni/make/build.xml is called - it copies a selection of the header
>>> files in luni/src/main/native/include that need to be shared between
>>> modules into the deploy/include directory. This is done with an
>>> explicit fileset in luni/make/build.xml - if you need to have
>>> portsock.h added to the list of shared header files, then this is
>>> the place to make that change. Just add its filename to the list,
>>> and next time you build it will appear in the deploy/include
>>> directory. Your nio code should include the headers from the
>>> deploy/include dir, and *not* directly from the
>>> luni/src/main/native/include dir.
>> Oli, I tried to modify the luni/make/build.xml, and it successfully
>> copied the portsock.h, but I found I still cannot build my native
>> codes. So I looked inside the portsock.h, and found that all its
>> content is just to include another file: "../port/hysock.h", my
>> native codes in modules/nio/src/main/native cannot find
>> "../port/hysock.h" so it fails. I guess the reason why the luni
>> natives still can build is all LUNI's native codes are still located
>> in native-src/luni, so they can found the hysock.h in native-src/port.
>>
>> Seems portsock.h is useless and confusable, so I suggest the steps
>> below to fix this problem:
>> 1. svn delete portsock.h in luni
>> 2. svn move hysock.h from native-src to luni
>> 3. update all reference to portsock.h to hysock.h
>> 4. rebuild
>
> Yes, that sounds reasonable. From what I can see portsock.h is basically
> pointless, since it just includes hysock.h. Your plan to replace
> portsock.h with hysock.h sounds like the right thing to do here.
>
>>
>> If no one objects, I'll raise a separated JIRA and provide patch
>
> Thanks!
>
> Regards,
> Oliver
>
>
>>>
>>> I hope this makes more sense now - if it doesn't, please let me
>>> know. I am in the process of writing up some documentation for the
>>> website on the natives layout and where headers should go (and also
>>> how modules should build against the HDK) - once that is complete it
>>> should all be a lot clearer.
>>>
>>> Regards,
>>> Oliver
>>>
>>
>>
>
--
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
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI
1.4 enhancement on ByteBuffer)
Posted by Oliver Deakin <ol...@googlemail.com>.
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.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.
>>
>> It depends on whether you want to wait for what I'm doing or not :)
>> If you want to get the code out now, then you can temporarily put it
>> under native-src/win.IA32/nio and I will move it later as part of the
>> natives modularisation.
>> However, if you don't mind waiting a day or so I should be able to
>> submit my first patch to move the prefs natives. This ought to be
>> enough of an example for you to put your native code directly into
>> modules/nio/src/main/native.
>>
>>>
>>> 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)?
>>
>> At build time, the "copy.native.includes" target in
>> luni/make/build.xml is called - it copies a selection of the header
>> files in luni/src/main/native/include that need to be shared between
>> modules into the deploy/include directory. This is done with an
>> explicit fileset in luni/make/build.xml - if you need to have
>> portsock.h added to the list of shared header files, then this is the
>> place to make that change. Just add its filename to the list, and
>> next time you build it will appear in the deploy/include directory.
>> Your nio code should include the headers from the deploy/include dir,
>> and *not* directly from the luni/src/main/native/include dir.
> Oli, I tried to modify the luni/make/build.xml, and it successfully
> copied the portsock.h, but I found I still cannot build my native
> codes. So I looked inside the portsock.h, and found that all its
> content is just to include another file: "../port/hysock.h", my native
> codes in modules/nio/src/main/native cannot find "../port/hysock.h" so
> it fails. I guess the reason why the luni natives still can build is
> all LUNI's native codes are still located in native-src/luni, so they
> can found the hysock.h in native-src/port.
>
> Seems portsock.h is useless and confusable, so I suggest the steps
> below to fix this problem:
> 1. svn delete portsock.h in luni
> 2. svn move hysock.h from native-src to luni
> 3. update all reference to portsock.h to hysock.h
> 4. rebuild
Yes, that sounds reasonable. From what I can see portsock.h is basically
pointless, since it just includes hysock.h. Your plan to replace
portsock.h with hysock.h sounds like the right thing to do here.
>
> If no one objects, I'll raise a separated JIRA and provide patch
Thanks!
Regards,
Oliver
>>
>> I hope this makes more sense now - if it doesn't, please let me know.
>> I am in the process of writing up some documentation for the website
>> on the natives layout and where headers should go (and also how
>> modules should build against the HDK) - once that is complete it
>> should all be a lot clearer.
>>
>> Regards,
>> Oliver
>>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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)
Posted by Paulex Yang <pa...@gmail.com>.
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 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.
>
> It depends on whether you want to wait for what I'm doing or not :)
> If you want to get the code out now, then you can temporarily put it
> under native-src/win.IA32/nio and I will move it later as part of the
> natives modularisation.
> However, if you don't mind waiting a day or so I should be able to
> submit my first patch to move the prefs natives. This ought to be
> enough of an example for you to put your native code directly into
> modules/nio/src/main/native.
>
>>
>> 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)?
>
> At build time, the "copy.native.includes" target in
> luni/make/build.xml is called - it copies a selection of the header
> files in luni/src/main/native/include that need to be shared between
> modules into the deploy/include directory. This is done with an
> explicit fileset in luni/make/build.xml - if you need to have
> portsock.h added to the list of shared header files, then this is the
> place to make that change. Just add its filename to the list, and next
> time you build it will appear in the deploy/include directory. Your
> nio code should include the headers from the deploy/include dir, and
> *not* directly from the luni/src/main/native/include dir.
Oli, I tried to modify the luni/make/build.xml, and it successfully
copied the portsock.h, but I found I still cannot build my native codes.
So I looked inside the portsock.h, and found that all its content is
just to include another file: "../port/hysock.h", my native codes in
modules/nio/src/main/native cannot find "../port/hysock.h" so it fails.
I guess the reason why the luni natives still can build is all LUNI's
native codes are still located in native-src/luni, so they can found the
hysock.h in native-src/port.
Seems portsock.h is useless and confusable, so I suggest the steps below
to fix this problem:
1. svn delete portsock.h in luni
2. svn move hysock.h from native-src to luni
3. update all reference to portsock.h to hysock.h
4. rebuild
If no one objects, I'll raise a separated JIRA and provide patch
>
> I hope this makes more sense now - if it doesn't, please let me know.
> I am in the process of writing up some documentation for the website
> on the natives layout and where headers should go (and also how
> modules should build against the HDK) - once that is complete it
> should all be a lot clearer.
>
> Regards,
> Oliver
>
--
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
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI
1.4 enhancement on ByteBuffer)
Posted by Oliver Deakin <ol...@googlemail.com>.
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/<platform>/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
>> have previously run a global build).
>>
>
> Can we have it set to the deploy dir by default?
>
This is only a temporary step while the natives are still in native-src.
Once all the native code is
moved into the modules the default will be the deploy directory. In
fact, if you go to the prefs
module and type in "Ant build.native" it will build the prefs native
code and place the output
libs into the deploy directory. (ok, that's not strictly true - you need
to use
"Ant -Dmake.command=nmake build.native" because the modular scripts dont
pick up this
variable from /make/properties.xml yet, but this will be fixed in the
future.)
>
>> 3. Run make/nmake. The hyluni.dll will be built against the libs already
>> in HY_HDK, and the generated dll will be placed into the
>> native-src/<platform>
>> directory, where you can then copy it wherever you want
>>
>> Once the natives are all modularised (so native-src no longer exists) you
>> will be able to just go to the module you want and run "ant build.native"
>> (or some similarly name target) and the natives will be incrementally
>> rebuilt and automatically placed into your target directory.
>>
>
> This is the mode of working that people should get used to, so that
> if/when we have ./configure steps too they will still build the natives
> the same way (i.e. rather than just typing (n)make).
>
Agreed
Regards,
Oliver
> Regards,
> Tim
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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)
Posted by Tim Ellison <t....@gmail.com>.
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/<platform>/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
> have previously run a global build).
Can we have it set to the deploy dir by default?
> 3. Run make/nmake. The hyluni.dll will be built against the libs already
> in HY_HDK, and the generated dll will be placed into the
> native-src/<platform>
> directory, where you can then copy it wherever you want
>
> Once the natives are all modularised (so native-src no longer exists) you
> will be able to just go to the module you want and run "ant build.native"
> (or some similarly name target) and the natives will be incrementally
> rebuilt and automatically placed into your target directory.
This is the mode of working that people should get used to, so that
if/when we have ./configure steps too they will still build the natives
the same way (i.e. rather than just typing (n)make).
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)
Posted by Oliver Deakin <ol...@googlemail.com>.
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 directory luni and force build by "make" and create a new DLL/so
> file.
> In this way it is easy to write codes and debug. However after
> modularisation nowadays, as there are envionment variables in the
> makefile,
> which are defined in the build.xml, I have no idea but build whole native
> with ant, even after changing a single line.
> So I turn to help for if there's an easy way to build single module
> alone? Thanks!
If you want to rebuild all the natives in one go, you can still (currently)
go to the native-src directory and run ant. This will rebuild all the native
components.
Rebuilding a single component can also be done. For example, to rebuild
the hyluni.dll you would:
1. cd to native-src/<platform>/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
have previously run a global build).
3. Run make/nmake. The hyluni.dll will be built against the libs already
in HY_HDK, and the generated dll will be placed into the
native-src/<platform>
directory, where you can then copy it wherever you want
Once the natives are all modularised (so native-src no longer exists) you
will be able to just go to the module you want and run "ant build.native"
(or some similarly name target) and the natives will be incrementally
rebuilt and automatically placed into your target directory.
Hope this helps,
Oliver
>
> at 06-6-20，Oliver Deakin <ol...@googlemail.com> 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 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.
>>
>> It depends on whether you want to wait for what I'm doing or not :)
>> If you want to get the code out now, then you can temporarily put it
>> under native-src/win.IA32/nio and I will move it later as part of the
>> natives modularisation.
>> However, if you don't mind waiting a day or so I should be able to
>> submit my first patch to move the prefs natives. This ought to be enough
>> of an example for you to put your native code directly into
>> modules/nio/src/main/native.
>>
>> >
>> > 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)?
>>
>> At build time, the "copy.native.includes" target in luni/make/build.xml
>> is called - it copies a selection of the header files in
>> luni/src/main/native/include that need to be shared between modules into
>> the deploy/include directory. This is done with an explicit fileset in
>> luni/make/build.xml - if you need to have portsock.h added to the list
>> of shared header files, then this is the place to make that change. Just
>> add its filename to the list, and next time you build it will appear in
>> the deploy/include directory. Your nio code should include the headers
>> from the deploy/include dir, and *not* directly from the
>> luni/src/main/native/include dir.
>>
>> I hope this makes more sense now - if it doesn't, please let me know. I
>> am in the process of writing up some documentation for the website on
>> the natives layout and where headers should go (and also how modules
>> should build against the HDK) - once that is complete it should all be a
>> lot clearer.
>>
>> Regards,
>> Oliver
>>
>> --
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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)
Posted by LvJimmy，Jing <fi...@gmail.com>.
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 create a new DLL/so file.
In this way it is easy to write codes and debug. However after
modularisation nowadays, as there are envionment variables in the makefile,
which are defined in the build.xml, I have no idea but build whole native
with ant, even after changing a single line.
So I turn to help for if there's an easy way to build single module
alone? Thanks!
at 06-6-20，Oliver Deakin <ol...@googlemail.com> 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 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.
>
> It depends on whether you want to wait for what I'm doing or not :)
> If you want to get the code out now, then you can temporarily put it
> under native-src/win.IA32/nio and I will move it later as part of the
> natives modularisation.
> However, if you don't mind waiting a day or so I should be able to
> submit my first patch to move the prefs natives. This ought to be enough
> of an example for you to put your native code directly into
> modules/nio/src/main/native.
>
> >
> > 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)?
>
> At build time, the "copy.native.includes" target in luni/make/build.xml
> is called - it copies a selection of the header files in
> luni/src/main/native/include that need to be shared between modules into
> the deploy/include directory. This is done with an explicit fileset in
> luni/make/build.xml - if you need to have portsock.h added to the list
> of shared header files, then this is the place to make that change. Just
> add its filename to the list, and next time you build it will appear in
> the deploy/include directory. Your nio code should include the headers
> from the deploy/include dir, and *not* directly from the
> luni/src/main/native/include dir.
>
> I hope this makes more sense now - if it doesn't, please let me know. I
> am in the process of writing up some documentation for the website on
> the natives layout and where headers should go (and also how modules
> should build against the HDK) - once that is complete it should all be a
> lot clearer.
>
> Regards,
> Oliver
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI
1.4 enhancement on ByteBuffer)
Posted by Paulex Yang <pa...@gmail.com>.
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 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.
>
> It depends on whether you want to wait for what I'm doing or not :)
> If you want to get the code out now, then you can temporarily put it
> under native-src/win.IA32/nio and I will move it later as part of the
> natives modularisation.
> However, if you don't mind waiting a day or so I should be able to
> submit my first patch to move the prefs natives. This ought to be
> enough of an example for you to put your native code directly into
> modules/nio/src/main/native.
>
I see, I can wait for your reference move:), it doesn't make sense to
let you move them again later.
>>
>> 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)?
>
> At build time, the "copy.native.includes" target in
> luni/make/build.xml is called - it copies a selection of the header
> files in luni/src/main/native/include that need to be shared between
> modules into the deploy/include directory. This is done with an
> explicit fileset in luni/make/build.xml - if you need to have
> portsock.h added to the list of shared header files, then this is the
> place to make that change. Just add its filename to the list, and next
> time you build it will appear in the deploy/include directory. Your
> nio code should include the headers from the deploy/include dir, and
> *not* directly from the luni/src/main/native/include dir.
>
Got it, I will try. Thank you very much, Oli!
> I hope this makes more sense now - if it doesn't, please let me know.
> I am in the process of writing up some documentation for the website
> on the natives layout and where headers should go (and also how
> modules should build against the HDK) - once that is complete it
> should all be a lot clearer.
>
> Regards,
> Oliver
>
--
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
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI
1.4 enhancement on ByteBuffer)
Posted by Oliver Deakin <ol...@googlemail.com>.
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
> 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.
It depends on whether you want to wait for what I'm doing or not :)
If you want to get the code out now, then you can temporarily put it
under native-src/win.IA32/nio and I will move it later as part of the
natives modularisation.
However, if you don't mind waiting a day or so I should be able to
submit my first patch to move the prefs natives. This ought to be enough
of an example for you to put your native code directly into
modules/nio/src/main/native.
>
> 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)?
At build time, the "copy.native.includes" target in luni/make/build.xml
is called - it copies a selection of the header files in
luni/src/main/native/include that need to be shared between modules into
the deploy/include directory. This is done with an explicit fileset in
luni/make/build.xml - if you need to have portsock.h added to the list
of shared header files, then this is the place to make that change. Just
add its filename to the list, and next time you build it will appear in
the deploy/include directory. Your nio code should include the headers
from the deploy/include dir, and *not* directly from the
luni/src/main/native/include dir.
I hope this makes more sense now - if it doesn't, please let me know. I
am in the process of writing up some documentation for the website on
the natives layout and where headers should go (and also how modules
should build against the HDK) - once that is complete it should all be a
lot clearer.
Regards,
Oliver
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
[classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI
1.4 enhancement on ByteBuffer)
Posted by Paulex Yang <pa...@gmail.com>.
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.
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)?
>
--
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
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Posted by Paulex Yang <pa...@gmail.com>.
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 table. I think
>> this will make it easier to integrate Harmony classlib and multi VMs.
>
> This seems like a good approach. The VM can just add the
> classlib-provided
> function pointers to its JNI invoke table and not need to know anything
> else. Of course, the classlib implementations will have to be written
> as JNI functions (they can't use "direct" access to the objects or
> classes) but that's fine.
Agreed, that classlib implementation needs to access objects or classes
by JNI accessor functions. And I think it is fine because we can provide
some static utilities in Java, and the utilitie methods' handle can be
cached, so that not so many reflection/accessor work needed.
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Posted by Archie Cobbs <ar...@dellroad.org>.
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 will
> make it easier to integrate Harmony classlib and multi VMs.
This seems like a good approach. The VM can just add the classlib-provided
function pointers to its JNI invoke table and not need to know anything
else. Of course, the classlib implementations will have to be written
as JNI functions (they can't use "direct" access to the objects or
classes) but that's fine.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Posted by Paulex Yang <pa...@gmail.com>.
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|
>>
>> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer>
>>
>>
>> * |GetDirectBufferAddress|
>>
>> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress>
>>
>>
>> * |GetDirectBufferCapacity|
>>
>> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity>
>>
>>
>> Because these methods are actually classlib dependent and JNI
>> implementation must know some details of ByteBuffer implementation,
>> current IBM VME hasn't them implemented, and seems DRLVM doesn't
>> implemented thoroughly(please correct me if I made mistake here,
>> seems DRLVM tries to get some non-api method/field of ByteBuffer, and
>> if fails, it return NULL or -1 as JNI spec says). And I have no idea
>> how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let
>> me know?)
>
> FYI, here is how this is handled in Classpath-based VMs like JCHEVM.
>
> The direct buffer classes derive from a common superclass containing
> the well known fields "data" and "capacity". The latter is an int,
> while the former is of type gnu.classpath.Pointer32 (or Pointer64),
> which is just a container that stores a native pointer in an int/long.
> The native pointer points to the native buffer. These two fields are
> accessed by GetDirectBufferAddress() and GetDirectBufferCapacity().
>
> There is also a constructor available for the JNI code to call,
> taking: gnu.classpath.Pointer32/64, and int (capacity). This is
> used for NewDirectByteBuffer().
>
> The resulting JNI code is fairly simple. You can see it on line 2580 of
> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm/libjc/jni_native.c
>
Thank you, Archie, very clear explanation!
Actually Harmony classlib can be used in similar way, in Harmony's
classlib, there is a interface named as DirectBuffer, which is
implemented by all direct buffers(including MappedByteBuffer), and it
provides method to get a native address wrapper named as
PlatformAddress, which should be similar with Pointer32/64 in classpath
I believe. About the NewDirectByteBuffer, Harmony classlib can work in
similar way, create a PlatformAddress, and invoke
ReadWriteDirectBuffer's constructor.
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 will
make it easier to integrate Harmony classlib and multi VMs.
Comments? ideas?
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Posted by Archie Cobbs <ar...@dellroad.org>.
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|
>
> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer>
>
>
> * |GetDirectBufferAddress|
>
> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress>
>
>
> * |GetDirectBufferCapacity|
>
> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity>
>
>
> Because these methods are actually classlib dependent and JNI
> implementation must know some details of ByteBuffer implementation,
> current IBM VME hasn't them implemented, and seems DRLVM doesn't
> implemented thoroughly(please correct me if I made mistake here, seems
> DRLVM tries to get some non-api method/field of ByteBuffer, and if
> fails, it return NULL or -1 as JNI spec says). And I have no idea how
> Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?)
FYI, here is how this is handled in Classpath-based VMs like JCHEVM.
The direct buffer classes derive from a common superclass containing
the well known fields "data" and "capacity". The latter is an int,
while the former is of type gnu.classpath.Pointer32 (or Pointer64),
which is just a container that stores a native pointer in an int/long.
The native pointer points to the native buffer. These two fields are
accessed by GetDirectBufferAddress() and GetDirectBufferCapacity().
There is also a constructor available for the JNI code to call,
taking: gnu.classpath.Pointer32/64, and int (capacity). This is
used for NewDirectByteBuffer().
The resulting JNI code is fairly simple. You can see it on line 2580 of
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm/libjc/jni_native.c
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/13/06, Paulex Yang <pa...@gmail.com> 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
> >
>
> * |GetDirectBufferAddress|
> <
> http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress
> >
>
> * |GetDirectBufferCapacity|
> <
> http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity
> >
>
> Because these methods are actually classlib dependent and JNI
> implementation must know some details of ByteBuffer implementation, current
> IBM VME hasn't them implemented, and seems DRLVM doesn't implemented
> thoroughly(please correct me if I made mistake here, seems DRLVM tries to
> get some non-api method/field of ByteBuffer, and if fails, it return NULL or
> -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with
> this issue yet.(anyone kindly let me know?)
I propose to provide the implementation in NIO component, and I raise
> Harmony-578 for it. The idea is: export these three methods in NIO module as
> hynio.dll(.so), which is loaded by Harmony launcher, and add these methods
> to VMI in some way, so that the VM vendor(i.e., JNI implementation vendor)
> can add these methods to JNI function table.
>
> Other choices I can imagine now include:
> 1. Add related direct buffers class to kernel class, so that the VM vendor
> can implement it as well as the JNI methods. IMO this is not good choice
> because buffers are actually VM independent, it's not reasonable to let VM
> vendor to implement these classes.
It seems that JCHEVM follows this way. It depends on classes from classpath
library.
2. Provides some utility methods in o.a.h.nio, add these methods to VMI, so
> that VM vendor can get inside knowledge on the direct buffers by these
> utilities. This option is acceptable, but it also needs to modify VMI, and
> the modification is based on some Harmony specific contract, while my
> proposal above is based on public JNI spec, so this one is not preferred.
It seems that DRLVM follows this way, except it assumes the utility methods
are located in java.nio.ByteBuffer, not o.a.h.nio.
Any ideas and comments are highly welcome.
>
> [1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html
>
>
>
> --
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Posted by Tim Ellison <t....@gmail.com>.
Paulex Yang wrote:
<snip>
> 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 classlib.
If you export functions that implement the required JNI functionality
then VM-writers can either choose to use them directly (i.e. put the
function addresses in the JNI table), or choose to reach into the
classlib Java code.
Since the second option would require the VM to reach into
implementation details of NIO (which may change) the recommended way
would be to use the provided functions.
I agree that there is no need to label any NIO types 'kernel'.
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][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Posted by Paulex Yang <pa...@gmail.com>.
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|
>>
>> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer>
>>
>>
>> * |GetDirectBufferAddress|
>>
>> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress>
>>
>>
>> * |GetDirectBufferCapacity|
>>
>> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity>
>>
>>
>> Because these methods are actually classlib dependent and JNI
>> implementation must know some details of ByteBuffer implementation,
>> current IBM VME hasn't them implemented, and seems DRLVM doesn't
>> implemented thoroughly(please correct me if I made mistake here,
>> seems DRLVM tries to get some non-api method/field of ByteBuffer, and
>> if fails, it return NULL or -1 as JNI spec says). And I have no idea
>> how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let
>> me know?)
>>
>> I propose to provide the implementation in NIO component, and I raise
>> Harmony-578 for it. The idea is: export these three methods in NIO
>> module as hynio.dll(.so), which is loaded by Harmony launcher, and
>> add these methods to VMI in some way, so that the VM vendor(i.e., JNI
>> implementation vendor) can add these methods to JNI function table.
>> Other choices I can imagine now include:
>> 1. Add related direct buffers class to kernel class, so that the VM
>> vendor can implement it as well as the JNI methods. IMO this is not
>> good choice because buffers are actually VM independent, it's not
>> reasonable to let VM vendor to implement these classes.
>>
>
> By reading the spec, it seems RI prefer this way, take direct-buffer
> as kernel class ,like class String(Though maybe it is hard to tell
> "kernel" and "normal" classes in RI's implementation, they're always
> together there :) ).
>
> And in Harmony, there's an interface named "DirectBuffer"
> (o.a.h.nio.internal), abstract class Buffer(java.nio) and an
> implementation class "ReadWriteDirectByteBuffer" (java.nio),which
> contains fields and methods for JNI methods. So an easy way may be:
> take these "as" kernel classes, and get Address from
> DirectBuffer.getBaseAddress(), get Capacity from Buffer.capacity, and
> new a ReadWriteDirectByteBuffer as basic direct buffer in three JNI
> methods.
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 classlib.
>
>> 2. Provides some utility methods in o.a.h.nio, add these methods to
>> VMI, so that VM vendor can get inside knowledge on the direct buffers
>> by these utilities. This option is acceptable, but it also needs to
>> modify VMI, and the modification is based on some Harmony specific
>> contract, while my proposal above is based on public JNI spec, so
>> this one is not preferred.
>>
>> Any ideas and comments are highly welcome.
>> [1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html
>>
>>
>>
>
>
--
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
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
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|
>
> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer>
>
>
> * |GetDirectBufferAddress|
>
> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress>
>
>
> * |GetDirectBufferCapacity|
>
> <http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity>
>
>
> Because these methods are actually classlib dependent and JNI
> implementation must know some details of ByteBuffer implementation,
> current IBM VME hasn't them implemented, and seems DRLVM doesn't
> implemented thoroughly(please correct me if I made mistake here, seems
> DRLVM tries to get some non-api method/field of ByteBuffer, and if
> fails, it return NULL or -1 as JNI spec says). And I have no idea how
> Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?)
>
> I propose to provide the implementation in NIO component, and I raise
> Harmony-578 for it. The idea is: export these three methods in NIO
> module as hynio.dll(.so), which is loaded by Harmony launcher, and add
> these methods to VMI in some way, so that the VM vendor(i.e., JNI
> implementation vendor) can add these methods to JNI function table.
> Other choices I can imagine now include:
> 1. Add related direct buffers class to kernel class, so that the VM
> vendor can implement it as well as the JNI methods. IMO this is not good
> choice because buffers are actually VM independent, it's not reasonable
> to let VM vendor to implement these classes.
>
By reading the spec, it seems RI prefer this way, take direct-buffer as
kernel class ,like class String(Though maybe it is hard to tell "kernel"
and "normal" classes in RI's implementation, they're always together
there :) ).
And in Harmony, there's an interface named "DirectBuffer"
(o.a.h.nio.internal), abstract class Buffer(java.nio) and an
implementation class "ReadWriteDirectByteBuffer" (java.nio),which
contains fields and methods for JNI methods. So an easy way may be: take
these "as" kernel classes, and get Address from
DirectBuffer.getBaseAddress(), get Capacity from Buffer.capacity, and
new a ReadWriteDirectByteBuffer as basic direct buffer in three JNI methods.
> 2. Provides some utility methods in o.a.h.nio, add these methods to VMI,
> so that VM vendor can get inside knowledge on the direct buffers by
> these utilities. This option is acceptable, but it also needs to modify
> VMI, and the modification is based on some Harmony specific contract,
> while my proposal above is based on public JNI spec, so this one is not
> preferred.
>
> Any ideas and comments are highly welcome.
> [1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html
>
>
>
--
Best Regards!
Jimmy, Jing Lv
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