Does `jobject` always have the same address if it represents the same Java instance?
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
|
show 4 more comments
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
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 callingNewGlobalRef
gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed injobject
is global or local. Based on my current understanding, the passed injobject
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 ajobject
(that represents the java instance), do you know if all the otherjobject
s that I would receive in my native instance methods would be equivalent to this global reference?
– TheeNinjaDev
Nov 20 '18 at 0:36
|
show 4 more comments
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
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
java c jni native jniwrapper
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 callingNewGlobalRef
gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed injobject
is global or local. Based on my current understanding, the passed injobject
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 ajobject
(that represents the java instance), do you know if all the otherjobject
s that I would receive in my native instance methods would be equivalent to this global reference?
– TheeNinjaDev
Nov 20 '18 at 0:36
|
show 4 more comments
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 callingNewGlobalRef
gives a global reference that can be assigned to a global variable, it doesn't seem to change whether the passed injobject
is global or local. Based on my current understanding, the passed injobject
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 ajobject
(that represents the java instance), do you know if all the otherjobject
s 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 jobject
s 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 jobject
s that I would receive in my native instance methods would be equivalent to this global reference?– TheeNinjaDev
Nov 20 '18 at 0:36
|
show 4 more comments
1 Answer
1
active
oldest
votes
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.
If I made a static native factory method that returns a globaljobject
, 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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
If I made a static native factory method that returns a globaljobject
, 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
add a comment |
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.
If I made a static native factory method that returns a globaljobject
, 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
add a comment |
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.
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.
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 globaljobject
, 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
add a comment |
If I made a static native factory method that returns a globaljobject
, 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 injobject
is global or local. Based on my current understanding, the passed injobject
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 otherjobject
s that I would receive in my native instance methods would be equivalent to this global reference?– TheeNinjaDev
Nov 20 '18 at 0:36