Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-debug-dev] Improved support for mapping other languages onto JDWP


Peter (with CC to debug lists since there are other interested parties),

I have some questions about improving the support for mapping other languages to JDWP.


First of all, if JSR045 were implemented, we would have access to strata, which could be supported in the java debug model. This would lilkely provide much flexibility, but perhaps not all that we need. The strata support provides a way to map line numbers to alternate source. However, it does not provide a way to map a VM to a different set of threads, or a thread to a different set of stack frames, or a frame to a different set of variables. I believe that many ISVs that proxy to a Java debug model will want to change the debug model element structure/hierarchy in some way.

The debug model presentation does not perform this task (as you found out) - it is simply a label provider.

I have toyed with the idea of allowing a "content provider" to be specified for a specific debug model, in a specific view. For example, to allow the java debug model to display thread groups, which are not part of the generic debug model, a go-between is required between the view and the model to get the proper structure/content into the view. Currently, debug views have hard-wired content providers. This sort of support would allow a toggle action to set a custom content provider in a specific view (i.e. toggle show/hide thread groups).

An extension of this idea is to allow a content provider and debug model presentation to be specified for a specific launch, on a global level. Thus, the custom content provider and presentation would be used in all debug views for the specified launch. This provides more power, but I am not sure how useful it is. In general, I believe that ISVs wanting to proxy to a Java debug model need more than "presentation" aspects. They likely need to maintain state in their own debug model. Do you agree?

If so, you mention the idea of a "JDWP proxy framework". Do you have more concrete ideas on how this framework would need to be implemented. I presume you are looking for a set of debug model elements implementing the standard debug model interfaces that proxy to the java debug model. But is the mapping 1:1 by default? i.e. frame to frame, thread to thread. Do users of the framework simply subclass and override?

Thanks,

Darin

Back to the top