How to set a breakpoint in Eclipse in a third party library?
Asked Answered
J

7

61

I'm getting a NullPointerException in a Class from a 3rd party library. Now I'd like to debug the whole thing and I would need to know from which object the class is held. But it seems to me that I cannot set a breakpoint in a Class from a 3rd party.

Does anyone know a way out of my trouble? Of course I'm using Eclipse as my IDE.

Update: the library is open-source.

Jeffiejeffrey answered 16/12, 2008 at 9:42 Comment(0)
T
38

The most sure-fire way to do this (and end up with something that's actually useful) is to download the source (you say that it is open-source), and set up another "Java Project" pointing at that source.

To do that, get the source downloaded and unzipped somewhere on your system. Click "File"->"New"->"Java Project". In the next dialog, give it a project name and select "Create Project from Existing Source". Browse to the root location of the open source library.

Supposing that all the additional libraries that are required by the project and such are included in the project you downloaded, Eclipse will figure everything out and set the build path up for you.

You'll need to remove the open source jar from your project's build path, and add this new project to the build path of your project.

Now, you can just treat this as your code, and debug at will.

This gets around at least a couple of problems with other approaches:

  1. You could "attach source" to the jar file, but if the jar file was compiled without debug information, this still won't work. If the jar file was compiled with debug information (lines,source,vars...see http://java.sun.com/j2se/1.3/docs/tooldocs/win32/javac.html, and the -g option).

  2. You could add an "exception breakpoint" to see when the NullPointerException is raised, but that's a common exception, and may well get raised and dealt with many (hundreds of?) times prior to the one you're looking for. Plus, without the original source, you won't be able to really see much of anything about the code that is throwing the NullPointerException - the likelihood you'll be able to figure out what's wrong is pretty low.

Taliped answered 16/12, 2008 at 20:39 Comment(3)
when debugging an external library, if we see the comments in this library's classes, does it mean it has been compiled using the -goption? The doc states that -g : Generate all debugging information, including local variables., then only source, lines, & variable are mentioned. I read on coderanch that real names of fields are also used coderanch.com/t/262054/java-programmer-SCJP/certification/… . But nothing is mentioned about comments.Eaves
I would expect the -g option to let us then debug without any trouble, that is, being able to keep the debuger synchronized with the code. I guess the only way to do this is to leave the class files "untouched". Is this what this does? note: I've been looking for clear info regarding this but it seems that generating a jar with & then without -g is the only way to find out what actually changes when using that -g option.Eaves
"Create project from existing source" doesn't exist since Eclipse Indigo; just uncheck "use default location" and browse to the location of your unzipped source. https://mcmap.net/q/324186/-where-is-quot-create-project-from-existing-source-quot-in-eclipse-indigoSiward
C
67

You can easily set method breakpoints in 3rd party libraries without having the source. Just open the class (you'll get the "i-have-no-source" view). Open the outline, right-click on the method you want and click on Toggle Method Breakpoint to create the method breakpoint.

Cyclothymia answered 16/12, 2008 at 9:45 Comment(7)
This requires that the 3rd party library was compiled with debugging symbols.Saucer
Ah, maybe not... but I found I couldn't put a method breakpoint in the ServletResponse interface, while I could put one in the implementing class ( ServletResponseWrapper ).Saucer
@AdamMonsen I understand the confusion, but if you think about it, of course you can't put a meaningful breakpoint on an abstract method...that method is never called, there's no binary to weave a breakpoint into. Eclipse doesn't have a feature to "put a breakpoint at the start of all overrides of this method", only to put a breakpoint in a specific concrete implementation.Nalepka
@akapelko It's very much still present in current versions of Eclipse...perhaps you misunderstood the directions? The steps given are to open the class file, then, with that class file focused, open the "Outline" view, and right-click the method there. You won't see the class outline in the class file editor. It's also available from the right click menu of a method in the Package Explorer.Nalepka
Does this still work? When I open a class file, I just get The Class File Viewer cannot handle the given input ('org.eclipse.ui.ide.FileStoreEditorInput'). Is it supposed to work from the "Open file..." dialog in the main File menu or is there a special dialog for it?Parathion
...and that was because it wants the class file to be in the build path.Parathion
alt+shift+w for outline in windows :)Animism
T
38

The most sure-fire way to do this (and end up with something that's actually useful) is to download the source (you say that it is open-source), and set up another "Java Project" pointing at that source.

To do that, get the source downloaded and unzipped somewhere on your system. Click "File"->"New"->"Java Project". In the next dialog, give it a project name and select "Create Project from Existing Source". Browse to the root location of the open source library.

Supposing that all the additional libraries that are required by the project and such are included in the project you downloaded, Eclipse will figure everything out and set the build path up for you.

You'll need to remove the open source jar from your project's build path, and add this new project to the build path of your project.

Now, you can just treat this as your code, and debug at will.

This gets around at least a couple of problems with other approaches:

  1. You could "attach source" to the jar file, but if the jar file was compiled without debug information, this still won't work. If the jar file was compiled with debug information (lines,source,vars...see http://java.sun.com/j2se/1.3/docs/tooldocs/win32/javac.html, and the -g option).

  2. You could add an "exception breakpoint" to see when the NullPointerException is raised, but that's a common exception, and may well get raised and dealt with many (hundreds of?) times prior to the one you're looking for. Plus, without the original source, you won't be able to really see much of anything about the code that is throwing the NullPointerException - the likelihood you'll be able to figure out what's wrong is pretty low.

Taliped answered 16/12, 2008 at 20:39 Comment(3)
when debugging an external library, if we see the comments in this library's classes, does it mean it has been compiled using the -goption? The doc states that -g : Generate all debugging information, including local variables., then only source, lines, & variable are mentioned. I read on coderanch that real names of fields are also used coderanch.com/t/262054/java-programmer-SCJP/certification/… . But nothing is mentioned about comments.Eaves
I would expect the -g option to let us then debug without any trouble, that is, being able to keep the debuger synchronized with the code. I guess the only way to do this is to leave the class files "untouched". Is this what this does? note: I've been looking for clear info regarding this but it seems that generating a jar with & then without -g is the only way to find out what actually changes when using that -g option.Eaves
"Create project from existing source" doesn't exist since Eclipse Indigo; just uncheck "use default location" and browse to the location of your unzipped source. https://mcmap.net/q/324186/-where-is-quot-create-project-from-existing-source-quot-in-eclipse-indigoSiward
C
7

You can also set breakpoints on specific exceptions. From the Debug perspective, there's a button "Add Java Exception Breakpoint", and there you can add "NullPointerException". Your debugger will then suspend execution as soon as such an exception is raised.

Carmel answered 16/12, 2008 at 10:29 Comment(3)
This doesn't catch the Exceptions flung in the library. Maybe there is something about what Bent said with the debug flags not set.Jeffiejeffrey
I've never seen that happen. The JVM still has the stack trace, just no source or line numbers, so it should still break on the exception.Gombroon
I used this to catch a servlet exception in Eclipse debugging a problem that I couldn't seem to catch in the app code itself. Many thanks for this tip!Lore
B
1

Normally, you should be able to set a break point. Especially if the 3rd party library is open source. But if your 3rd party lib is from a commercial vendor, they may have compiled the source with the debug flag turned off. This will make it impossible for you to debug into it. Your vendor might have done this as part of an obfuscation process to make it impossible to reverse engineer the library, or just simply because the final compiled classes will be smaller.

Bayberry answered 16/12, 2008 at 10:25 Comment(1)
I will ask a colleague if the debug flag was turned off.Jeffiejeffrey
B
1

To make this work with a maven materialized web app, I had to do three things.

1) Create a new eclipse project with the source code of the 3rd party jar.

2) Remove the reference to the jar from pom.xml dependencies.

3) Add the new eclipse project to Deployment Assembly in the project properties.

4) Add the new eclipse project to project Properties -> Java Build Path -> Projects of the existing project that references the 3rd party project.

If the 3rd project has been added to your maven repository correctly, with sources, maven will automagically download the appropriate source code and let you add breakpoints without you having to do any of the steps above; however, I have learnt that you can't always count on this.

Biotope answered 12/10, 2015 at 19:43 Comment(0)
G
1

In maven projects, easily you can open maven dependencies tree view in project explorer view and see a list of jar files that your project depends on.   Open project explorer and then expand your project.   Then, look for maven dependencies and expand this tree view.   Now, you can expand any jar file and see list of available classes and by pressing enter on any of them, Eclipse will decompile the source for you and you can set a breakpoint.   If your project has sub maven module projects, you should look for dependencies in your modules. I recommend to install Enhance class decompiler plugin, So you can easily debug your project without source code or you can specify source for eclipse to avoid source not found while debugging.If the third party jar file's source  is already open as project in eclipse, You can not expand it in Maven dependencies section.

Genesisgenet answered 11/12, 2021 at 20:32 Comment(1)
great answer, I did that after deziping the source jar of the third party lib in a directory, asked eclipse to browse that source, then followed your instruction to open the class I wanted in the package explorer, and the source opened, I could put a breakpoint and I stopped onto it :) thanks !!!Rocha
T
0

Just attach the source (or use something that automatically attaches the source jar) and then set a breakpoint in the normal way, by double-clicking to the left of the line of interest.

Thanks answered 28/9, 2012 at 12:26 Comment(1)
This method helped me very much when debugging my app linked with an Open Source project. In my case I have (a) a jar with classes, (b) a jar with corresponding sources, and (c) I unzipped the sources to my local drive. To place a breakpoint on a function within the Open Source project, I (1) opened the specific local drive source file in Eclipse, and (2) placed a breakpoint on the desired function line. When I ran my app, Eclipse was smart enough to break at the desired point.Anole

© 2022 - 2024 — McMap. All rights reserved.