On Sun, Jun 24, 2012 at 9:20 PM, Vladimir Berezniker <v...@hitechman.com> wrote:
> Hi All,
>
> In the current JavaHL code the C++ objects are attached via pointer stored in
> the long cppAddr field in java object. The way C++ code gets hold of the
> cppAddr value is to read this field using the GetLongField(). In summary
>
> Java:
>
> class JHLClass
> {
> long cppAddr;
> public native method();
> }
>
>
> JNI Stub:
>
> Java_method(JNIEnv *env, jobject jthis)
> {
> JHLClass cppObj = JHLClass::getCppObject(jthis);
> }
>
> C++:
>
> class JHLClass
> {
> JHLClass getCppObject(jobject jthis) { .... }
> }
>
>
> I was thinking why not simplify this by doing all object->jlong lookup in the
> java land. What takes about 20 lines of C++ takes 1 line in java, at a cost of
> implementing 3 line java wrapper method that converts from caller visible
> method signature to native method signature. As follows:
>
> class JHLClass
> {
> long cppAddr;
>
> private native static method(long cppAddr);
> method() {
> method(cppAddr);
> }
> }
>
> JNI Stub:
>
> Java_method(JNIEnv *env, jlong cppAdder)
> {
> JHLClass cppObj = reinterpret_cast<SVNFile *>(fileCppAddr);
> }
>
> C++: No additional code necessary
>
> This will require a related change in JNIStackElement, as it won't have jthis
> anymore. But this logic also can move up to java code in a similar manner.
>
> What do others think? Any objections at least of doing this in RA functions?
While I can't comment on the specific implications of your plan,
generally the more we can write in Java in the JavaHL bindings, the
better. Hopefully that nugget of wisdom gives you some insight. :)
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
