Bug 80090 - API support for static context information and return value of methods
API support for static context information and return value of methods
Product: debugger
Classification: Unclassified
Component: Java
All All
: P2 (vote)
: 6.x
Assigned To: Martin Entlicher
Depends on:
Blocks: 28936 41113
  Show dependency treegraph
Reported: 2006-07-12 18:17 UTC by Martin Entlicher
Modified: 2010-04-29 09:29 UTC (History)
2 users (show)

See Also:

The new ClassVariable class. (1.55 KB, text/plain)
2006-07-12 20:08 UTC, Martin Entlicher
The new JPDAClassType class. (2.24 KB, text/plain)
2006-07-12 20:09 UTC, Martin Entlicher
The new ReturnVariable class. (1.48 KB, text/plain)
2006-07-12 20:09 UTC, Martin Entlicher
Other changes associated with this API change, including test. (8.26 KB, text/plain)
2006-07-12 20:11 UTC, Martin Entlicher

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Entlicher 2006-07-12 18:17:38 UTC
In order to be able to provide static context information and return value of
methods, three new classes need to be added:

JPDAClassType  - Representation of type of an object (class, interface, array) in
                 the target VM.
ClassVariable  - Representation of an instance of java.lang.Class from the target
ReturnVariable - Representation of a return value from a method.
Comment 1 Martin Entlicher 2006-07-12 20:08:30 UTC
Created attachment 31781 [details]
The new ClassVariable class.
Comment 2 Martin Entlicher 2006-07-12 20:09:18 UTC
Created attachment 31782 [details]
The new JPDAClassType class.
Comment 3 Martin Entlicher 2006-07-12 20:09:59 UTC
Created attachment 31783 [details]
The new ReturnVariable class.
Comment 4 Martin Entlicher 2006-07-12 20:11:27 UTC
Created attachment 31784 [details]
Other changes associated with this API change, including test.
Comment 5 Martin Entlicher 2006-07-12 20:13:11 UTC
Please review this simple API change in DebuggerJPDA module, which is necessary
for the new features: issue #28936 and issue #41113. Thanks.
Comment 6 _ rkubacki 2006-07-18 14:19:22 UTC
I see how ReturnVariable is supposed to be used and have no comment about this. 

It is not clear to me from attachments why you need ClassVariable and
JPDAClassType. How these will be used? What is relationship between these?
ObjectVariable already provides list of static fields. Why do we need to
duplicate this in JPDAClassType?
Comment 7 Martin Entlicher 2006-07-18 16:25:33 UTC
The JPDAClassType and ClassVariable are used in the Local Variables window, in a
similar way how This and Super are used.
JPDAClassType just represents the "Static" node, which is proposed in issue
#28936. It needs the staticFields() method to display the fields below the
"Static" node. There is no other way, because we do not have any instance, just
the class type. So we can not use ObjectVariable.
ClassVariable is for representation of "class" from issue #28936.
Is this explanation sufficient?
Comment 8 Martin Entlicher 2006-07-19 17:38:13 UTC
Thanks for the review, I'm going to integrate this change tomorrow.
Comment 9 _ rkubacki 2006-07-19 18:18:22 UTC
Sorry but can you wait for a while?

I do not agree with concept of Super and This interfaces. They are just adding a
lot of instanceof check when they are used. Why do you need these? To build some
string sdisplyed in UI using 
if (obj instanceof This) {
name = "foo "+obj.getName()}
else if (obj instanceof That) {
name = "bar "+obj.getName()}
else ...

Inherited or Static nodes are created in VariablesModelTreeFilterSI anyway and
can work without these interfaces.

What information is missing? You know the class so there should be
ObjectVariable representing related instance of java.lang.Class. Then you can
also find its static fields and create wrapping node for these.
Comment 10 Jaroslav Tulach 2006-07-20 08:08:52 UTC
The test seems to test just the ReturnVariable and not ClassVariable and 
Comment 11 Martin Entlicher 2006-07-20 10:01:11 UTC
To Radim:
Regarding This and Super:
The views are full of "intanceof" checks. They get just an Object and they need
to find out what it is about. So from this point of view this looks fine to me.
It's just one instanceof check instead of another ;-)

A snippet from VariablesNodeModel.getDisplayName():
        if (o instanceof Field)
            return ((Field) o).getName ();
        if (o instanceof LocalVariable)
            return ((LocalVariable) o).getName ();
        if (o instanceof Super)
            return "super"; // NOI18N
        if (o instanceof This)
            return "this"; // NOI18N

There is really no other way to do this, since we have strictly split
implementation module (JPDA Debugger), which have access to JDI classes, from
GUI module (JPDA Debugger UI), which does not have access to JDI classes. So if
we should display "this" string, we need to have a representation of this in the
API. Perhaps it could be done in another way, but it went through review in this
form in the past.

Regarding JPDAClassType and ClassVariable:
No, I do not know the class! I have a static context, and the view need to
diplay a list of static fields in the current class. Where can I get the
information from? There might be no other variables in Local View? I can pass
there the ObjectVariable, which represents the Class object. Fine, but how do I
now that it is the "class" object and not a local variable? I need ClassVariable
for that. Now how do I fing the static fields?
ClassVariable.getAllStaticFields() returns static fields from java.land.Class
class! It's not the class I have in the static context, which I'm interested in.
I need JPDAClassType, which represents the type I have and
JPDAClassType.staticFields() method to get the list of static fields in that
class type.
I didn't find a way how to do this without an API change, if you have some idea,
let me know. This is just following the original design....
Comment 12 Martin Entlicher 2006-07-20 10:07:42 UTC
To Yarda:
Yes, I didn't write tests for ClassVariable and JPDAClassType, they are not
directly available from any API method, their implementation is just provided to
views. There is no test for Field, etc, not test for Local Variables View and
other views. JPDA tests contains just tests of what's provided directly by API
Comment 13 _ rkubacki 2006-07-20 14:34:38 UTC
After discussion with Martin I accepted proposed that are changes following the
original design...

Comment 14 Martin Entlicher 2006-07-21 12:26:50 UTC
Thanks for comments, the API change together with the implementation is
committed to trunk:

 <--  AbstractVariable.java
new revision: 1.42; previous revision: 1.41

RCS file:

 <--  ClassVariableImpl.java
initial revision: 1.1

 <--  ClassesTreeModel.java
new revision: 1.13; previous revision: 1.12

RCS file:

 <--  JPDAClassTypeImpl.java
initial revision: 1.1

 <--  JPDAThreadImpl.java
new revision: 1.19; previous revision: 1.18

 <--  LocalsTreeModel.java
new revision: 1.37; previous revision: 1.36

 <--  ObjectTranslation.java
new revision: 1.5; previous revision: 1.4

RCS file:

 <--  ReturnVariableImpl.java
initial revision: 1.1

 <--  BreakpointImpl.java
new revision: 1.29; previous revision: 1.28

 <--  Bundle.properties
new revision: 1.31; previous revision: 1.30

 <--  VariablesNodeModel.java
new revision: 1.13; previous revision: 1.12

 <--  VariablesTableModel.java
new revision: 1.14; previous revision: 1.13

RCS file:

<--  ClassVariable.java
initial revision: 1.1

RCS file:

<--  JPDAClassType.java
initial revision: 1.1

RCS file:

<--  ReturnVariable.java
initial revision: 1.1

 <--  EvaluationContext.java
new revision: 1.6; previous revision: 1.5

<--  Evaluator.java
new revision: 1.30; previous revision: 1.29

 <--  Expression.java
new revision: 1.4; previous revision: 1.3

RCS file:

 <--  JDIObjectVariable.java
initial revision: 1.1

 <--  JPDADebuggerImpl.java
new revision: 1.102; previous revision: 1.101

 <--  MethodBreakpointApp.java
new revision: 1.3; previous revision: 1.2

 <--  MethodBreakpointTest.java
new revision: 1.11; previous revision: 1.10

/cvs/debuggerjpda/api/apichanges.xml,v  <--  apichanges.xml
new revision: 1.15; previous revision: 1.14

/cvs/debuggerjpda/api/manifest.mf,v  <--  manifest.mf
new revision: 1.18; previous revision: 1.17

/cvs/debuggerjpda/api/nbproject/project.properties,v  <--  project.properties
new revision: 1.8; previous revision: 1.7

/cvs/debuggerjpda/nbproject/project.properties,v  <--  project.properties
new revision: 1.12; previous revision: 1.11
Comment 15 Quality Engineering 2010-04-29 09:29:25 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo