Re: [jdt-debug-dev] Released changes

[Darin_Wright@xxxxxxx]

Yes, there are benefits to this change.

This feature was motivated requested by a client that is developing a "super debug adapter" - that is, a debug model that uses the java debug model for part of its implementation. This allows clients to write high level debuggers for languages that are compiled to Java (for which there is no Java Model), and allows clients to experiment with ways of writing end to end (cross lannguage/JNI) debuggers.

In order to set a breakpoint, with the old API, a client required Java Model Objects - such as IType, IField, etc. With the new API, all that is required by the debug model is type names, field names, etc. This allows clients to set breakpoints when Java Model Objects are not available. Clients now specify the resource to associate a breakpoint with (before we constrained it to the associated Java Model resources). Breakpoints can now also be "hidden". That is, the need not be registered with the breakpoint manager. Breakpoints can also be selectively persisted (markers only allowed all/none of a marker type to be persisted). This makes the debug model more flexible, and gives clients more building blocks.

The old API, in terms of Java Model Elements, was only convenient for clients that had access to  a Java Model. Our source lookup has become more flexible - it is now possible to debug programs for which there is no corresponding Java Model, and retrieve source from the file system. However, with the old breakpoint API, it would not be possible to set breakpoints in such programs.

This has also simplified some part of our Java debug implementation - for example, the feature "suspend on any uncaught exception", simply sets a breakpoint for the type named "java.lang.Throwable", rather than a specific IType in a specific project. The breakpoint is not registered with the breakpoint manager - it is only known and used by one client. Another example is the "run to line breakpoint". The IJavaRunToLineBreakpoint has been removed, as its special functionallity is no longer required. Now, the Java debug ui simply creates a "line breakpoint" that is hidden, non persisted, and has a hit count of 1. This is an example of providing building blocks to clients.

There is now a utility class in the Java debug UI, to determine which resource a breakpoint should be saved with, and which IType a breakpoint is associated with. I agree this removes some of the OO-ness we had developed, but it also makes the debug model more flexible. 

Darin

Jared Burns <jared-eclipse@xxxxxxxxx> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx 01/21/2002 07:39 AM Please respond to jdt-debug-dev

To:        jdt-debug-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [jdt-debug-dev] Released changes

Wait a minute... I've been looking over these changes and I don't understand 
them at all.

It looks like the breakpoint object hierarchy has been stripped down and 
we're back to using utility "classes" to extract marker attributes and our 
clients are back to manually pumping attributes into our breakpoint markers.

Unless I'm completely missing something this change seems to render our 
objects impotent. A watchpoint can no longer answer #getField()?

Can someone please explain the benefits of this change? I'm very turned off 
by this new model, but it might help if I knew what we were getting for it.

- Jared

On Sunday 20 January 2002 04:43 pm, you wrote:
> http://dev.eclipse.org/bugs/show_bug.cgi?id=7807
>
> I have released changes for bug 7807 to
>         org.eclispe.debug.core
>         org.eclispe.jdt.debug
>         org.eclispe.jdt.debug.ui
>         org.eclispe.jdt.ui
>
> Darin
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev