Community
Participate
Working Groups
It would be nice to define a tracepoint which, when hit, would execute a snippet which could stream text to the console. You can simulate this by creating a conditional breakpoint which calls println and then returns false. Performance is not as good as code which has println in it. The benefit is that programmers are less likely to release println() to CVS.
Performance is not as good, since the "condition" is evaluated via JDI calls which have a communication overhead. The condition is in interpreted and each message send requires a JDI call. Does the "tracepoint" you are referring to have a direct correlation to something in the Java debug architecture, or are you just asking for "faster" conditions?
I'm just asking for a conditional breakpoint which isn't conditional at all. It simply executes the code in the "condition", but it never interrupts execution. This is useful for "adding" printlns to code which is loaded as binary. As I mentioned, you can already do this, but it isn't obvious to the user and could be sold as a cool feature in Eclipse.
*** Bug 28096 has been marked as a duplicate of this bug. ***
Deferred
*** Bug 98890 has been marked as a duplicate of this bug. ***
The explicit "tracepoint" could be nevertheless nice for the user even if we can do it otherwise. regards Xavier
unfortunately, until breakpoints can be saved and shared, this would achieve only a part of its potential
Adam, this feature is extremely useful whenever you have code loaded as binary because it's not your code. Think of all the times you might use println in your own code for debugging, but you can't do the same in someone elses code. I don't see contributing these things to CVS as a common use case.
I do agree that it would be very good to have this. My scenario is that I work on 5 different machines so anything that is not CVSable is of much smaller value for me because I'd have to configure it on each machine separately (that's why I don't use bookmarks, for example). Anyway, understandably postponed at this point. Let's reopen past 3.1.
I'm very interested in this feature and I'm willing to have a go at implementing it. If not as part of the current debugging facilities, then as a plugin that could be merged later.
Here are conditional breakpoints mentioned. How to create such breakpoint programmatically? It is possible through evaluating the condition to communicate with a plugin, that set such a breakpoint programmatically? I think tracepoints should be able to do this, and it should be able to set them on method-entry/exit. At last it should be easy to hide tracepoints from the user (to not show them to the user and to not allow the user to disable them by mistake).
A condition is simply an attribute of an IJavaLineBreakpoint (package org.eclipse.jdt.debug.core, plug-in org.eclipse.jdt.debug) - see set/getCondition. To create a breakpoint, use the factory methods on JDIDebugModel.
*** Bug 110426 has been marked as a duplicate of this bug. ***
*** Bug 179983 has been marked as a duplicate of this bug. ***
*** Bug 200340 has been marked as a duplicate of this bug. ***
Adding helpwanted keyword. There is definite interest in this bug, but there are no plans to work on this in 3.4.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
*** Bug 386957 has been marked as a duplicate of this bug. ***
reopening
*** Bug 375484 has been marked as a duplicate of this bug. ***
We can add a 'Create Tracepoint' action to the context and 'Run' menu. This would create the conditional breakpoint with the text from the 'systrace' template'.
*** Bug 315404 has been marked as a duplicate of this bug. ***
(In reply to Dani Megert from comment #21) > We can add a 'Create Tracepoint' action to the context and 'Run' menu. Adapted bug summary to this. > This > would create the conditional breakpoint with the text from the 'systrace' > template'. See also bug 412982, which should eliminate the need for a "return false;" at the end of the conditional breakpoint.
(In reply to Dani Megert from comment #21) > [..] with the text from the 'systrace' template. Problem is that variables currently don't resolve properly there, see bug 498433.
This change request was updated based on a scientific study on how developers debug, in discussion with Daniel Megert, Markus Keller, Sarika Sinha, and Moritz Beller. Link to the study - http://repository.tudelft.nl/islandora/object/uuid%3Abf3325ce-f246-4977-91bc-785f877347b8?collection=education
Moving to M4, as M3 is dedicated for Java 9 work.
*** Bug 502094 has been marked as a duplicate of this bug. ***
Adding few notes, from dup Bug 502094. 1. It would be good to have print-points, which would be similar to conditional breakpoints, which prints their method + line but do not stop the execution. 2. It would be nice if each print-point has by default a method customizable by the user, i.e. printf("%n printPointMethod:Line") that should be easy to customize using scoped variables: printf("%n printPointMethod:Line %s", variable) 3. We could get great benefits if we could save a set of print points, in order to be shared between developers. Adding Andrey in c/c as he refined the bug proposing idea 1.
We can have a new option under Run, After Toggle Line Breakpoint as "Toggle Tracepoint" It will create a conditional breakpoint , with systrace template like System.out.println("enclosing_type.enclosing_method()"); After Bug 412982 , Conditional breakpoint will not give any error for void returning conditional blocks, it will assume return false and will not suspend. Will try to work on bug 498433 as a separate issue to resolve enclosing type and enclosing method properly. Toggle Tracepoint action on existing tracepoint , will prompt for deleting conditional breakpoint if the conditions have been changed and does not have simple systreace template statement Conditional breakpoints are available for Line and Method breakpoint, Tracepoint as well will be available at these two places.
New Gerrit change created: https://git.eclipse.org/r/87541
New Gerrit change created: https://git.eclipse.org/r/87542
(In reply to Eclipse Genie from comment #31) > New Gerrit change created: https://git.eclipse.org/r/87542 This is work in progress patch. Working on 2 more things - 1. Method tracepoint is not available right now, only line tracepoint is available. Will be working on it so that if method name is selected and Toggle Tracepoint menu is selected, it will create a method breakpoint with systrace condition otherwise line breakpoint with condition. 2. Current Action is extending an internal action class from platform debug Current patch does resolve the enclosing type and method, so systrace generates a resolved println like System.out.println("Testing.test()");
Method tracepoint is available now, so if the text selection is method name and user selects, Create Tracepoint, method breakpoint will be created with the condition. Current Action still extends an internal action class from platform debug.
Gerrit change https://git.eclipse.org/r/87541 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=954ee8fb25dd011bf8ef8ca9c282303c392419b3
Gerrit change https://git.eclipse.org/r/87542 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=31938cddc73e05325fc2ad6374aa9093fb431ad2
Thanks Noopur for testing it out!!! Verified using Eclipse SDK Version: Oxygen (4.7) Build id: I20170123-2000
Will add in Help.
