JDK-4252790 : JDI: spec is inconsistent in handling of Location of native methods
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_nt
  • CPU: generic,x86
  • Submitted: 1999-07-09
  • Updated: 2002-09-06
  • Resolved: 2002-09-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 betaFixed
Related Reports
Duplicate :  
JDK-4302538 - MethodEntryEvent.location() is not returning null for native method
Duplicate :  
JDK-4359298 - exceptions getting variable information
Duplicate :  
JDK-4325270 - JDI: Location.codeIndex() for native method does not return -1.
Relates :  
JDK-4323433 - JDI: location is not null for an Abstract method
Relates :  
JDK-4419459 - JDI spec: Locatable.location() returns non-null for a native method
Description
The JDI spec is inconsistent with regards to location() of native methods.  In some places
it claims they cannot be created (should return null).  In others, it is claimed they can.

Can:

	StackFrame.location()

 		If the frame represents a native method invocation, the returned
     		location indicates the class and method, but the code index will not be valid.

	Location.codeIndex()

		Returns the long representing the position within the method, or -1 if the 
		method is native.

Unspecified, but implies by virtue of being Locatable that they can:

	MethodEntryEvent
	MethodExitEvent
	AccessWatchpointEvent
	ModificationWatchpointEvent
		
		all of which are events which can occur in native code

Cannot:

	Locatable.location()

     		Returns the Location of this mirror, or null if there is no executable code 
		associated with it. For example, abstract and native Methods will return
         	null when their location method is called.

It would severely break the interface if StackFrame.location() or the events could not return
Location.  So it is Locatable.location() that must be changed (note: it will still return
null for abstract methods).

Additionally then. all users of Location objects must behave correctly when encountering
Location objects for native methods.  Specifically, 

	EventRequestManager.createBreakpointRequest(Location location)

which is the only consumer of Location objects must have its spec changed so that it throws
NativeMethodException (which is a RuntimeException) if passed a Location for a native
method.  And the related methods within Location must have their specs clarified.


robert.field@Eng 2000-03-28
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: merlin-beta INTEGRATED IN: merlin-beta
14-06-2004
EVALUATION Fixed.
11-06-2004
PUBLIC COMMENTS The JDI spec is inconsistent with regards to location() of native methods. In some places it claims they cannot be created (should return null). In others, it is claimed they can. Can: StackFrame.location() If the frame represents a native method invocation, the returned location indicates the class and method, but the code index will not be valid. Location.codeIndex() Returns the long representing the position within the method, or -1 if the method is native. Unspecified, but implies by virtue of being Locatable that they can: MethodEntryEvent MethodExitEvent AccessWatchpointEvent ModificationWatchpointEvent all of which are events which can occur in native code Cannot: Locatable.location() Returns the Location of this mirror, or null if there is no executable code associated with it. For example, abstract and native Methods will return null when their location method is called. I would severely break the interface if StackFrame.location() or the events could not return Location. So it is Locatable.location() that must be changed (note: it will still return null for abstract methods). Additionally then. all users of Location objects must behave correctly when encountering Location objects for native methods. Specifically, EventRequestManager.createBreakpointRequest(Location location) which is the only consumer of Location objects must have its spec changed so that it throws NativeMethodException (which is a RuntimeException) if passed a Location for a native method. And the related methods within Location must have their specs clarified. robert.field@Eng 2000-03-28
28-03-2000
WORK AROUND Use Method.isNative and Method.isAbstract to detect native and abstract methods and avoid calling Method.location in these cases. gordon.hirsch@eng 1999-07-09
09-07-1999