All About Perspective

In line with the changes to the launching framework (retargetting launch delegates, etc), we thought it would be a good idea if we could also fit the 'new way' of launching into the existing perspective switching way of things.

We felt that with such fine control (now) over how and what does the launching, it would be a nice addition to extend that notion to perspective settings. For example, consider you have two profilers that both launch a Java application with profile options. Traditionally this would have led to perspective switching based on which-ever launch delegate was chosen in the end, leaving the user no control over what would be switched to based on what did the launching.

Now however, the user can select down to the launch delegate level to specify launch perspective settings. Changes to these setting can be applied on the Perspective preference page as before, with the only notable change being to the launchers tree (see screen shot).

This new page design also allows multiple perspectives to be set at one time, i.e. you can multi-select items in the tree and set perspectives for common modes to all delegates/types in the selection. You can also over-write common perspective settings for launch delegates of a particular type by changing the perspective settings of that type.

This new hotness is available in builds >= Jan 9 2006

Mixed-up Launching

I guess since it has been quite a while and we have made a pile more changes, it would be a good idea to maybe discuss some of it on "the blog".

The most notible additon to the debug platform as of late is mixed mode launching. With this new launching notion, we can perform things such as debugging and profiling at the same time....say what? The functionality to do so is an implementation delail that is not provided in the platform, but surely some on-the-ball client of the debug platform will provide it :) -- never-the-less the ability to have mixed mode launching still exists.....really it does....you can believe me....have I lied to you before?

Along with mixed-mode launching we have vastly improved contributing to launching in Eclipse:

1. To extend an existing tab group is now as simple as contributing your own tab...gone are the days of recreating the entire tab group to add one or more of your own tabs. You can even specify the location of your tab...oh my!
2. Name and description fields have been added to the schemas for launch delegates
3. Launch delegates (the code that actually launches stuff) can be retargetted dynamically during the launching process
4. Duplicate launch delegate detection is now in place, with resolution mechanisms and a framework to set preferred delegates for both the workspace AND for individual launch configurations

So basicallly we have made a tonne of changes that 99% of normal users will never see, because it all appears to work the same on top. Making improvements noone ever sees or cares about rules.

There is some more information and a test plugin available from the debug team webpage
here: http://www.eclipse.org/eclipse/debug/documents.php.

Oh and here is a screenshot showing the launch dialog opened with more that one launcher available and some contributed tabs added after the Main tab:

Terminate Key Binding Requests (please)

The platform is running low on available key-bindings. So, we've decided to add one final key-binding for the debugger's terminate action. The action has been mapped to "CTRL-F2". If you can figure out how to use the key binding preference page, feel free to change it.

We've also fixed a small bug in the Debug view context menu. Key-bindings are once again displayed for the standard step commands in the context menu (when you are debugging). During 3.2, the actions were all changed from view contributions to being contributed by actual code. When we did this, we forgot to assign action definition id's in the code. Woops. Fixed now.

Painfully Fast (Now)

Today the debug team revels in its own greatness...Ok we didn't actually fix anything, but we did find out that a bug that was a critical stop ship for us was not at all our fault AND someone had already fixed it (I love those ones).

The bug in question is https://bugs.eclipse.org/bugs/show_bug.cgi?id=153458, and long story short, has to do with the apparent 'extreme slow down' of the eclipse debuger. It turns out (as the previous comment dictates) that it was not our fault; it was really a combination of factors...but mainly the new conjestion algorithm in the newer Linux kernels (> 2.6.14). Luckily though the kernel champions jumped on it and bullied Sun into fixing the way jvms communicate over TCP/IP.

To summarize:
If you have a newer Linux kernel (> 2.6.14) and you are NOT using jdk 1.5.08 or jdk 1.6 r79 you are boned, and doomed to have a matrix-neo-style debugging experience.