Does `jobject` always have the same address if it represents the same Java instance?












0















Given a java object A a = new A(), and a bunch of native instance methods, if I were to take the address of the jobject representing a passed into those methods, would the address always be the same?



I have multiple final fields in these classes that I want to store in a hashmap in my C code (so I don't have to continue fetching them with Get___Field), with the hash of a jobject being the address. If I can guarantee that the address of a passed in jobject representing a will always be the same, then the hash is deterministic, which means my program's behavior will not be inconsistent.










share|improve this question























  • If you want to retain a reference to any object across multiple jni calls, you need to call NewGlobalRef. journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/…. However, although that guarantees that the reference you hold remains valid, I don’t know if it guarantees that subsequent references passed in will match.

    – prl
    Nov 20 '18 at 0:16













  • @prl I've looked through that, but calling NewGlobalRef gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed in jobject is global or local. Based on my current understanding, the passed in jobject is not something I construct and determine the locality of, the JVM constructs it and passes it in.

    – TheeNinjaDev
    Nov 20 '18 at 0:23













  • In a similar situation, I stored an “object id” (the hash) in the object. I had Java pass in the id as an additional parameter to the native method.

    – prl
    Nov 20 '18 at 0:27











  • @prl I might as well pass in the values of the final instance fields (and dropping the idea of a global hashmap in the C code) if I opt in for passing in additional parameters, would this be more performant than fetching the values within the C code through the JNI interface?

    – TheeNinjaDev
    Nov 20 '18 at 0:30













  • @prl If I made a static native method (which would be used in place of a constructor), that returns a global reference to a jobject (that represents the java instance), do you know if all the other jobjects that I would receive in my native instance methods would be equivalent to this global reference?

    – TheeNinjaDev
    Nov 20 '18 at 0:36
















0















Given a java object A a = new A(), and a bunch of native instance methods, if I were to take the address of the jobject representing a passed into those methods, would the address always be the same?



I have multiple final fields in these classes that I want to store in a hashmap in my C code (so I don't have to continue fetching them with Get___Field), with the hash of a jobject being the address. If I can guarantee that the address of a passed in jobject representing a will always be the same, then the hash is deterministic, which means my program's behavior will not be inconsistent.










share|improve this question























  • If you want to retain a reference to any object across multiple jni calls, you need to call NewGlobalRef. journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/…. However, although that guarantees that the reference you hold remains valid, I don’t know if it guarantees that subsequent references passed in will match.

    – prl
    Nov 20 '18 at 0:16













  • @prl I've looked through that, but calling NewGlobalRef gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed in jobject is global or local. Based on my current understanding, the passed in jobject is not something I construct and determine the locality of, the JVM constructs it and passes it in.

    – TheeNinjaDev
    Nov 20 '18 at 0:23













  • In a similar situation, I stored an “object id” (the hash) in the object. I had Java pass in the id as an additional parameter to the native method.

    – prl
    Nov 20 '18 at 0:27











  • @prl I might as well pass in the values of the final instance fields (and dropping the idea of a global hashmap in the C code) if I opt in for passing in additional parameters, would this be more performant than fetching the values within the C code through the JNI interface?

    – TheeNinjaDev
    Nov 20 '18 at 0:30













  • @prl If I made a static native method (which would be used in place of a constructor), that returns a global reference to a jobject (that represents the java instance), do you know if all the other jobjects that I would receive in my native instance methods would be equivalent to this global reference?

    – TheeNinjaDev
    Nov 20 '18 at 0:36














0












0








0








Given a java object A a = new A(), and a bunch of native instance methods, if I were to take the address of the jobject representing a passed into those methods, would the address always be the same?



I have multiple final fields in these classes that I want to store in a hashmap in my C code (so I don't have to continue fetching them with Get___Field), with the hash of a jobject being the address. If I can guarantee that the address of a passed in jobject representing a will always be the same, then the hash is deterministic, which means my program's behavior will not be inconsistent.










share|improve this question














Given a java object A a = new A(), and a bunch of native instance methods, if I were to take the address of the jobject representing a passed into those methods, would the address always be the same?



I have multiple final fields in these classes that I want to store in a hashmap in my C code (so I don't have to continue fetching them with Get___Field), with the hash of a jobject being the address. If I can guarantee that the address of a passed in jobject representing a will always be the same, then the hash is deterministic, which means my program's behavior will not be inconsistent.







java c jni native jniwrapper






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 19 '18 at 23:59









TheeNinjaDevTheeNinjaDev

2401313




2401313













  • If you want to retain a reference to any object across multiple jni calls, you need to call NewGlobalRef. journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/…. However, although that guarantees that the reference you hold remains valid, I don’t know if it guarantees that subsequent references passed in will match.

    – prl
    Nov 20 '18 at 0:16













  • @prl I've looked through that, but calling NewGlobalRef gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed in jobject is global or local. Based on my current understanding, the passed in jobject is not something I construct and determine the locality of, the JVM constructs it and passes it in.

    – TheeNinjaDev
    Nov 20 '18 at 0:23













  • In a similar situation, I stored an “object id” (the hash) in the object. I had Java pass in the id as an additional parameter to the native method.

    – prl
    Nov 20 '18 at 0:27











  • @prl I might as well pass in the values of the final instance fields (and dropping the idea of a global hashmap in the C code) if I opt in for passing in additional parameters, would this be more performant than fetching the values within the C code through the JNI interface?

    – TheeNinjaDev
    Nov 20 '18 at 0:30













  • @prl If I made a static native method (which would be used in place of a constructor), that returns a global reference to a jobject (that represents the java instance), do you know if all the other jobjects that I would receive in my native instance methods would be equivalent to this global reference?

    – TheeNinjaDev
    Nov 20 '18 at 0:36



















  • If you want to retain a reference to any object across multiple jni calls, you need to call NewGlobalRef. journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/…. However, although that guarantees that the reference you hold remains valid, I don’t know if it guarantees that subsequent references passed in will match.

    – prl
    Nov 20 '18 at 0:16













  • @prl I've looked through that, but calling NewGlobalRef gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed in jobject is global or local. Based on my current understanding, the passed in jobject is not something I construct and determine the locality of, the JVM constructs it and passes it in.

    – TheeNinjaDev
    Nov 20 '18 at 0:23













  • In a similar situation, I stored an “object id” (the hash) in the object. I had Java pass in the id as an additional parameter to the native method.

    – prl
    Nov 20 '18 at 0:27











  • @prl I might as well pass in the values of the final instance fields (and dropping the idea of a global hashmap in the C code) if I opt in for passing in additional parameters, would this be more performant than fetching the values within the C code through the JNI interface?

    – TheeNinjaDev
    Nov 20 '18 at 0:30













  • @prl If I made a static native method (which would be used in place of a constructor), that returns a global reference to a jobject (that represents the java instance), do you know if all the other jobjects that I would receive in my native instance methods would be equivalent to this global reference?

    – TheeNinjaDev
    Nov 20 '18 at 0:36

















If you want to retain a reference to any object across multiple jni calls, you need to call NewGlobalRef. journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/…. However, although that guarantees that the reference you hold remains valid, I don’t know if it guarantees that subsequent references passed in will match.

– prl
Nov 20 '18 at 0:16







If you want to retain a reference to any object across multiple jni calls, you need to call NewGlobalRef. journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/…. However, although that guarantees that the reference you hold remains valid, I don’t know if it guarantees that subsequent references passed in will match.

– prl
Nov 20 '18 at 0:16















@prl I've looked through that, but calling NewGlobalRef gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed in jobject is global or local. Based on my current understanding, the passed in jobject is not something I construct and determine the locality of, the JVM constructs it and passes it in.

– TheeNinjaDev
Nov 20 '18 at 0:23







@prl I've looked through that, but calling NewGlobalRef gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed in jobject is global or local. Based on my current understanding, the passed in jobject is not something I construct and determine the locality of, the JVM constructs it and passes it in.

– TheeNinjaDev
Nov 20 '18 at 0:23















In a similar situation, I stored an “object id” (the hash) in the object. I had Java pass in the id as an additional parameter to the native method.

– prl
Nov 20 '18 at 0:27





In a similar situation, I stored an “object id” (the hash) in the object. I had Java pass in the id as an additional parameter to the native method.

– prl
Nov 20 '18 at 0:27













@prl I might as well pass in the values of the final instance fields (and dropping the idea of a global hashmap in the C code) if I opt in for passing in additional parameters, would this be more performant than fetching the values within the C code through the JNI interface?

– TheeNinjaDev
Nov 20 '18 at 0:30







@prl I might as well pass in the values of the final instance fields (and dropping the idea of a global hashmap in the C code) if I opt in for passing in additional parameters, would this be more performant than fetching the values within the C code through the JNI interface?

– TheeNinjaDev
Nov 20 '18 at 0:30















@prl If I made a static native method (which would be used in place of a constructor), that returns a global reference to a jobject (that represents the java instance), do you know if all the other jobjects that I would receive in my native instance methods would be equivalent to this global reference?

– TheeNinjaDev
Nov 20 '18 at 0:36





@prl If I made a static native method (which would be used in place of a constructor), that returns a global reference to a jobject (that represents the java instance), do you know if all the other jobjects that I would receive in my native instance methods would be equivalent to this global reference?

– TheeNinjaDev
Nov 20 '18 at 0:36












1 Answer
1






active

oldest

votes


















1














As comments have suggested, you cannot keep the passed-in jobject around beyond the current JNI call context because it is a local reference. The jobject values may be reused (leading to duplicate table entries) or become invalid. Furthermore, each call to CreateGlobalRef() will create a new, distinct jobject. The short answer is "you cannot do it this way". Such has been already addressed in this post. As an alternative approach, note that every Java Object has a hashCode() and equals() method. You can call those methods from your C/C++ code using JNI, and use them in your hash table. However, without knowing the details of when and how you are fetching the field values, calling JNI methods may not be any better than fetching the field values again.



Finally, as answered in this question, you can test jobject equality directly using env->IsSameObject(jobject1, jobject2). Presumably, jobject1 is the global reference that you have created and stored, whereas jobject2 is the passed-in local reference that you want to test against. Unfortunately this still doesn't help you probe into your hash table.






share|improve this answer


























  • If I made a static native factory method that returns a global jobject, would that object still not be passed in to the instance native methods?

    – TheeNinjaDev
    Nov 27 '18 at 5:35











  • I don't think so. Anything passed from java to C/C++ is going to get a brand new local reference.

    – Wheezil
    Nov 27 '18 at 23:58











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384354%2fdoes-jobject-always-have-the-same-address-if-it-represents-the-same-java-insta%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














As comments have suggested, you cannot keep the passed-in jobject around beyond the current JNI call context because it is a local reference. The jobject values may be reused (leading to duplicate table entries) or become invalid. Furthermore, each call to CreateGlobalRef() will create a new, distinct jobject. The short answer is "you cannot do it this way". Such has been already addressed in this post. As an alternative approach, note that every Java Object has a hashCode() and equals() method. You can call those methods from your C/C++ code using JNI, and use them in your hash table. However, without knowing the details of when and how you are fetching the field values, calling JNI methods may not be any better than fetching the field values again.



Finally, as answered in this question, you can test jobject equality directly using env->IsSameObject(jobject1, jobject2). Presumably, jobject1 is the global reference that you have created and stored, whereas jobject2 is the passed-in local reference that you want to test against. Unfortunately this still doesn't help you probe into your hash table.






share|improve this answer


























  • If I made a static native factory method that returns a global jobject, would that object still not be passed in to the instance native methods?

    – TheeNinjaDev
    Nov 27 '18 at 5:35











  • I don't think so. Anything passed from java to C/C++ is going to get a brand new local reference.

    – Wheezil
    Nov 27 '18 at 23:58
















1














As comments have suggested, you cannot keep the passed-in jobject around beyond the current JNI call context because it is a local reference. The jobject values may be reused (leading to duplicate table entries) or become invalid. Furthermore, each call to CreateGlobalRef() will create a new, distinct jobject. The short answer is "you cannot do it this way". Such has been already addressed in this post. As an alternative approach, note that every Java Object has a hashCode() and equals() method. You can call those methods from your C/C++ code using JNI, and use them in your hash table. However, without knowing the details of when and how you are fetching the field values, calling JNI methods may not be any better than fetching the field values again.



Finally, as answered in this question, you can test jobject equality directly using env->IsSameObject(jobject1, jobject2). Presumably, jobject1 is the global reference that you have created and stored, whereas jobject2 is the passed-in local reference that you want to test against. Unfortunately this still doesn't help you probe into your hash table.






share|improve this answer


























  • If I made a static native factory method that returns a global jobject, would that object still not be passed in to the instance native methods?

    – TheeNinjaDev
    Nov 27 '18 at 5:35











  • I don't think so. Anything passed from java to C/C++ is going to get a brand new local reference.

    – Wheezil
    Nov 27 '18 at 23:58














1












1








1







As comments have suggested, you cannot keep the passed-in jobject around beyond the current JNI call context because it is a local reference. The jobject values may be reused (leading to duplicate table entries) or become invalid. Furthermore, each call to CreateGlobalRef() will create a new, distinct jobject. The short answer is "you cannot do it this way". Such has been already addressed in this post. As an alternative approach, note that every Java Object has a hashCode() and equals() method. You can call those methods from your C/C++ code using JNI, and use them in your hash table. However, without knowing the details of when and how you are fetching the field values, calling JNI methods may not be any better than fetching the field values again.



Finally, as answered in this question, you can test jobject equality directly using env->IsSameObject(jobject1, jobject2). Presumably, jobject1 is the global reference that you have created and stored, whereas jobject2 is the passed-in local reference that you want to test against. Unfortunately this still doesn't help you probe into your hash table.






share|improve this answer















As comments have suggested, you cannot keep the passed-in jobject around beyond the current JNI call context because it is a local reference. The jobject values may be reused (leading to duplicate table entries) or become invalid. Furthermore, each call to CreateGlobalRef() will create a new, distinct jobject. The short answer is "you cannot do it this way". Such has been already addressed in this post. As an alternative approach, note that every Java Object has a hashCode() and equals() method. You can call those methods from your C/C++ code using JNI, and use them in your hash table. However, without knowing the details of when and how you are fetching the field values, calling JNI methods may not be any better than fetching the field values again.



Finally, as answered in this question, you can test jobject equality directly using env->IsSameObject(jobject1, jobject2). Presumably, jobject1 is the global reference that you have created and stored, whereas jobject2 is the passed-in local reference that you want to test against. Unfortunately this still doesn't help you probe into your hash table.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 26 '18 at 15:58

























answered Nov 26 '18 at 15:35









WheezilWheezil

1,89211029




1,89211029













  • If I made a static native factory method that returns a global jobject, would that object still not be passed in to the instance native methods?

    – TheeNinjaDev
    Nov 27 '18 at 5:35











  • I don't think so. Anything passed from java to C/C++ is going to get a brand new local reference.

    – Wheezil
    Nov 27 '18 at 23:58



















  • If I made a static native factory method that returns a global jobject, would that object still not be passed in to the instance native methods?

    – TheeNinjaDev
    Nov 27 '18 at 5:35











  • I don't think so. Anything passed from java to C/C++ is going to get a brand new local reference.

    – Wheezil
    Nov 27 '18 at 23:58

















If I made a static native factory method that returns a global jobject, would that object still not be passed in to the instance native methods?

– TheeNinjaDev
Nov 27 '18 at 5:35





If I made a static native factory method that returns a global jobject, would that object still not be passed in to the instance native methods?

– TheeNinjaDev
Nov 27 '18 at 5:35













I don't think so. Anything passed from java to C/C++ is going to get a brand new local reference.

– Wheezil
Nov 27 '18 at 23:58





I don't think so. Anything passed from java to C/C++ is going to get a brand new local reference.

– Wheezil
Nov 27 '18 at 23:58


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384354%2fdoes-jobject-always-have-the-same-address-if-it-represents-the-same-java-insta%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

ComboBox Display Member on multiple fields

Is it possible to collect Nectar points via Trainline?