4

In Java, the '@' sign in an address (e.g., in a printed stack trace) is generally used to represent an instance of an object as "object name" + '@' + System.identityHashCode() (there is a good discussion of this at Memory address of variables in Java).

But that doesn't seem to explain the syntax used by Android Studio when it prints out object addresses.

I have a variable, gmap, which has the following value when viewed in the Android Studio Debugger's "Variables" window (when the program has hit a breakpoint).

gmap = {com.google.android.gms.maps.GoogleMap@4541}

However, when I run the following in the Evaluate Code Fragment window, none of them come up with the value "4541".

gmap.toString(): com.google.android.gms.maps.GoogleMap@63676d9
System.identityHashCode(gmap): 104232665
gmap.hashCode(): 104232665

String.format("%x", System.identityHashCode(gmap)): 63676d9
String.format("%d", System.identityHashCode(gmap)): 104232665

What does "4541" represent?

UPDATE: I took another look at a stack trace and noticed that the numbers tend to increase in a sort-of sequential fashion. The following is a partial dump of the mContext variable, as shown in the Variables window when at a breakpoint.

mContext = {com.barryholroyd.tapit.ActivityMain@3624} 
 LOGTAG = {java.lang.String@3642} "TAPIT APS"
 bh_aps = {com.barryholroyd.tapit.Bhlogger@3643} 
 mActionBar = null
 mActivityInfo = {android.content.pm.ActivityInfo@3644} 
 mActivityTransitionState = {android.app.ActivityTransitionState@3645} 
 mAllLoaderManagers = null
 mApplication = {android.app.Application@3646} 
 mCalled = true
 mChangeCanvasToTranslucent = false
 mChangingConfigurations = false
 mCheckedForLoaderManager = false
 mComponent = {android.content.ComponentName@3647} 
 mConfigChangeFlags = 0
 mContainer = {android.app.Activity$1@3648} 
 mCurrentConfig = {android.content.res.Configuration@3649}

I suspect the @#### values might be offsets into some kind of allocation table or something, but that's just a guess. I'm not sure how/why that would be useful. I'd rather have them be the hash code or something else that would help me identify the particular class instantiation easily.

Barry

Community
  • 1
  • 1
Barry Holroyd
  • 1,005
  • 1
  • 11
  • 20
  • That number isn't guaranteed to be the same from one run to the next. I wonder if the variables view is running in (or reporting on) a different VM from the Evaluate Code Fragment window. That could account for the difference. – Ian McLaird Oct 01 '15 at 21:47
  • Thanks Ian. I don't think that's it, but I do have some new information. I'll update the question. – Barry Holroyd Oct 06 '15 at 18:30
  • What you have interpreted is correct for `Oracle JVM` not for `Dalvik VM` on which the bytecodes are generated. It has fixed set of Registers which ranges from 0-65535. If you want to learn more you can visit this [link](https://source.android.com/devices/tech/dalvik/dalvik-bytecode.html) – JavaGhost Oct 06 '15 at 19:31
  • Excellent -- thank you! If I understand correctly, the #### is actually an identifier for the register which stores the value -- is that correct? (That's a lot of registers.) That seems like a pretty useless thing to provide to developers since we can't correlate it with the stuff that we have access to (such as hashCode()). – Barry Holroyd Oct 13 '15 at 16:17

0 Answers0