You can ignore this query. There was an obscure change in the code from using the JavaVM* pointer to using a dialog window handle which would be limited to 32 bits and thus not a problem. The JavaVM* pointer appears to be limited to calling Attach/DetachCurrentThread.
Pete On 7/17/15 2:53 PM, Pete Brunet wrote: > This is a JNI question. Is the JavaVM* pointer returned by GetJavaVM > guaranteed to not have any bits in the upper 32? > > There is old code I am working with that stores the JavaVM pointer in > longs (32 bits on 64 bit Win) and uses longs to transfer the value all > around within the code and to/from an external native API. > > It's not been a problem in the past but since 9 b58 and the switch to > VS 2013 java.exe has the High Entropy Virtual Addresses bit set which > means that all memory addresses in a 64-bit app are guaranteed to be > above 4gb ( 4294967295 aka 0xFFFFFFFF) and thus have bits in the upper > 32, but I don't know if that also applies to the JavaVM* pointer. > > If there will be address bits in the upper 32 one possible workaround > to save recompilation by users of the external native API might be to > save the upper 32 bits after calling GetJavaVM and then prepend those > bits whenever the long comes back in from the external API. The users > of the external API never manipulate those bits; they receive the bits > when starting to use the API. > > Is there a better list for this question? > > Pete
