Community
Participate
Working Groups
The EGL Java debugger runs off generated code, and extensions to the base generator might implement variables differently. For example generator A might implement a dictionary as a Java class "org.foo.Dictionary" while generator B might implement it as a Java class "com.bar.DictionaryField". The underlying object differs between implementations, so we can't be hard-coding anything for either type in the debugger. Rather the debugger should support a set of variable adapters that take care of figuring out how to display an object in the Variables view (including its children). In addition to defining the extension point and supporting the contributions in the debugger, we'll want to provide some adapters for the base EDT Java runtime (e.g. arrays). If multiple adapters will work for a given IJavaVariable, the first one invoked will be used, and the order in which Eclipse returns the extension points is non-deterministic. But this should hopefully not be an issue, since it's unlikely multiple adapters will exist for some "com.foo.Bar" class.
Note that this adapter is not necessarily required to make a new type work in the Variables view. You may choose to include SMAP information in the class. The adapter framework will exist for those cases where this is not possible (or not desirable). For example, records generated by the base EDT generator produce SMAP information so that you only see the record's children as defined in the EGL (no internal variables are displayed, and the EGL names are shown instead of the generated names - e.g. "class" gets generated as "eze_class" since it's a Java keyword).
Adapters can now be contributed via the org.eclipse.edt.debug.core.variableAdapters extension point. Classes must implement org.eclipse.edt.debug.core.java.IVariableAdapter. An example is provided in the org.eclipse.edt.debug.core plug-in.
Verified
