398

I am getting this strange error in Eclipse while trying to set a breakpoint.

Unable to insert breakpoint Absent Line Number Information

I ticked the checkbox from Compiler options but no luck.

Eric Leschinski
  • 146,994
  • 96
  • 417
  • 335
chandrajeet
  • 8,833
  • 6
  • 23
  • 15
  • can you do a javap -verbose on the class file and paste the information here? See if it actually has a line number. – z - Jun 05 '09 at 19:59
  • 3
    Hi yx, I did a javap on that class. It generates the line numbers – chandrajeet Jun 05 '09 at 21:34
  • Strangely, I've just come across this problem with BlackBerry plugin, Eclipse 3.5, nothing to do with Tomcat. And I it also does stop at breakpoints, except for one of them... if I find an answer, I'll post. – Richard Le Mesurier Apr 22 '11 at 20:59
  • 8
    For me it was a wrong mock, I accidentally mocked the class I was testing. Maybe someone finds this relevant. – hipokito Oct 24 '14 at 14:05
  • 1
    @hipokito Can you explain what it means to mock a class and how to undo it? The other solutions aren't working for me. – Amber Apr 06 '16 at 15:21
  • @chandrajeet - In my case it was a simple switch from runtime referred from jre to jdk/jre and a complete rebuild which solved the problem. – userx Feb 21 '19 at 05:35
  • Hi, if you are creating your build through ant then add debug="on" in – Debaprasad Jana Aug 20 '20 at 17:56

42 Answers42

240

I had the same error message in Eclipse 3.4.1, SUN JVM1.6.0_07 connected to Tomcat 6.0 (running in debug-mode on a different machine, Sun JVM1.6.0_16, the debug connection did work correctly).

Window --> Preferences --> Java --> Compiler --> Classfile Generation: "add line number attributes to generated class file" was checked. I did a clean, recompile. I did uncheck it, recompile, check it, recompile. I made sure the project did use the global settings. Still the same message.

I switched to ant build, using

<javac srcdir="./src/java" destdir="./bin" debug="true">

Still, same message.

I didn't find out what caused this message and why it wouldn't go away. Though it seemed to have something to do with the running Tomcat debug session: when disconnected, recompiling solves the issue. But on connecting the debugger to Tomcat or on setting new breakpoints during a connected debug session, it appeared again.

However, it turned out the message was wrong: I was indeed able to debug and set breakpoints, both before and during debugging (javap -l did show line numbers, too). So just ignore it :)

Zefiro
  • 2,821
  • 2
  • 20
  • 21
  • 37
    The above didn't work for me. I had to click the 'Remove all Breakpoints' icon in the Eclipse > Breakpoints view, then re-add the breakpoints. That worked. – Vik David May 19 '11 at 14:05
  • 3
    I closed all the other project, removed all breakpoints, made a random change in the file, cleaned the project, introduced the break point again. That worked for me – Ali Feb 27 '12 at 13:18
  • 4
    Adding `debug="true"` to the `javac` task of the `ant` build script worked. – Justin Skiles Mar 27 '14 at 17:07
  • This answer is still valid for my installation of Eclipse Kepler running on windows 8 64 bit with Java 7. – Magnilex Aug 20 '14 at 07:50
  • 3
    "it turned out the message was wrong..." -- this should be ridiculously over-emphasized. Even after reading that, I didn't comprehend what it is that you were saying. Consider moving your entire answer to the bottom and at the top in big bold box say something like "It is likely that this message means nothing -- try just clicking the don't-bother-me-about-it and see if you can still debug". – Bane Nov 04 '14 at 16:06
  • I encountered this in Eclipse Luna working in a "spring-boot" app. After removing all breakpoints, and re-adding, the problem went away, but also I had built at least once with classfile line numbers off also, but according to Vik David's answer perhaps all that was required was deleting and re-adding the breakpoints. –  Dec 18 '14 at 22:55
  • Nothing above worked for me. So I deleted my project, did mvn eclipse:eclipse and imported it again. Working fine now :D – Heisenberg Mar 07 '16 at 14:25
  • If the problem is fixed by adding debug="true" than that's one problem: of course you can't set reliably breakpoints if you're compiling without debug information. My theory is that there's another problem having to do with setting a breakpoint in a class that is in some way proxied by Spring (instrumented via Spring AOP or whatever). I haven't diagnosed it yet, don't have a fix, but I think the problem is that the instrumented code hangs around too long. I suspect deleting the Tomcat temp directories may solve that, but I haven't tried that yet. – DaBlick Oct 23 '17 at 20:39
  • I´m having this issue specifically within Lambda expressions used in code blocks like @Bean that are explicitly managed within Spring. Just checking "Don't show this message again" prevents the spam and the debugging works fine as far as I can tell. Weird. – G_V May 02 '19 at 08:11
124
  1. In eclipse menu, go to Window->Preferences->Java->Compiler
  2. Unmark checkbox "Add line number attributes..."
  3. Click Apply -> Yes
  4. Mark checkbox "Add line number attribute..."
  5. Apply again.
  6. Go happy debugging
Paolo Forgia
  • 6,572
  • 8
  • 46
  • 58
30

This fixed my issue:

  1. Window -> preferences -> server -> runtime environments
  2. Apache Tomcat -> edit
  3. Select a JDK instead of JRE
user584572
  • 459
  • 4
  • 9
  • 3
    This fixed my problem (had the wrong version of jdk specified in ant config). It did fix the problem, but eclipse *STILL* gave me the error message. So be sure to actually go through and try to debug your code after you make this change - don't let the error message put you off. – Paul May 29 '14 at 13:04
  • Even your app not web, solution is Ok, by make `Installed JREs` default is `JDK` instead of `JRE` – Ahmed Nabil Oct 25 '18 at 08:14
  • I know the rule, but there are a lot of answers here. This one, works for me at Nov 2019 But I change the main Runtime enviorement too, that solve the problem 100%. – Alvargon Nov 21 '19 at 12:34
19

For Spring related issues consider that in some cases it generate classes "without line numbers"; for example a @Service annotated class without an interface, add the interface and you can debug. see here for a complete example.

@Service("SkillService")
public class TestServiceWithoutInterface {
   public void doSomething() {
      System.out.println("Hello TestServiceWithoutInterface");
   }
}

The service above will have an interface generated by spring causing "missing line numbers". Adding a real interface solve the generation problem:

public interface TestService {
    void doSomething();
}

@Service("SkillService")
public class TestServiceImpl implements TestService {
   public void doSomething() {
      System.out.println("Hello TestServiceImpl");
   }
}
Paizo
  • 3,986
  • 30
  • 45
  • 1
    What does "add the interface" mean? Import it into the file? – CamHart Jun 26 '15 at 22:34
  • 1
    Hello the definitive explanation here https://github.com/spring-projects/spring-ide/issues/78#issuecomment-293573057 and https://technology.first8.nl/eclipse-cannot-install-breakpoints-due-to-missing-line-number-attributes-when-using-spring-managed-beans-that-dont-have-an-interface/ – Poutrathor Mar 18 '19 at 14:27
  • I have an `@Configuration` class and have this problem. But adding an interface doesn't help. Spring still generates one itself. I only have one public function on my class, which is `@Override` now (it's also `@Bean`, if that matters). I changed the class name to add "Impl" at the end and sue the original name for the interface. The message has changed to include the "Impl" but spring is still trying to generate it's own interface. is `@Configuration` special? Or the fact it's a bean function? – Adam Dec 09 '20 at 07:18
14

I have the answer to this problem from the BlackBerry SDK side of things: For some reason, no matter how many times I changed the options in the compiler, the actual underlying settings file did not change.

Have a look in the .settings folder of your project for a file called org.eclipse.jdt.core.prefs.

In there you can modify the settings manually:

org.eclipse.jdt.core.compiler.debug.lineNumber=generate

edit: Further to this, I have noticed that sometimes I can ignore the alert Eclipse gives, and it will still stop at the required place... curioser and curioser... I put this into the bucket of things we learn to deal with when working as dev.

Richard Le Mesurier
  • 29,432
  • 22
  • 140
  • 255
13

I tried almost every solution here and no luck. Did you try clicking "Don't tell me again"? After doing so I restarted my program and all was well. Eclipse hit my breakpoint as if nothing was wrong.

The root cause for me was Eclipse was trying to setup debugging for auto-generated Spring CGLIB proxy objects. Unless you need to debug something at that level you should ignore the issue.

gbshuler
  • 173
  • 1
  • 8
10

This is explained in detail here:

https://github.com/spring-projects/spring-ide/issues/78

Just for future reference, this is the relevant part of the answer (ignore the fact that refers to a Spring Boot application, behavior is the same for lot of other cases):

Whenever you set a breakpoint in Eclipse/STS, the IDE tries to set the breakpoint in the VM if you launch an app. That is what happens in your case when you run the boot app in debug mode.

For each class that gets loaded into the JVM, the IDE checks whether it needs to set a breakpoint or not. If it decides to set the breakpoint, the tries to do so (using the information from the breakpoint definition in the IDE, including its line number, since you usually set line breakpoints on a source file at a given line).

This decision (whether to set the breakpoint on a given loaded class or not) checks the types that you set the breakpoint on, enclosing types, and inner classes. This makes sure that breakpoints for inner classes (even anonymous inner classes) are set to the JVM (and are not ignored).

Spring Boot generates an inner class for your controller at runtime (this is the CGLIB generated inner class that appears in the error message). When the JVM loads that class, it tries to set the line number breakpoint of the enclosing type (for this inner class). Since the generated inner class doesn't have any line number information (it doesn't need to have line number information), setting the breakpoint fails for this inner class with the mentioned error message.

When the IDE loads the enclosing type (your controller class itself), it also tries to set the line breakpoint and succeeds with that. This is visualized with the check marker on the breakpoint marker.

Therefore you can safely ignore the error message that shows up. To avoid this error message to show up, you can go to the preferences (Java -> Debug) and disable "Warn when unable to install breakpoint due to missing line number attributes".

Sampisa
  • 1,487
  • 2
  • 20
  • 28
8

This worked for me:

  1. Under Window --> Preferences --> Java --> Compiler --> Classfile Generation, all options have to be to True.
  2. Made debug="true" in the build.xml <javac> task.
  3. Deploy application in the tomcat by the war generated by ant
  4. Restarted the Tomcat in Debug mode
Dave Clemmer
  • 3,741
  • 12
  • 49
  • 72
8

Dont know if this is still relevant, perhaps another sailor will find this useful.

The message appears when one has a class file compiled the debug flags turned off.

In eclipse, you can turn it on by the afore mentioned options,

Window --> Preferences --> Java --> Compiler --> Classfile Generation: "add line number attributes to generated class file"

But if you have a jar file, then you would get the compiled output. There is no easy way to fix this problem.

If you have access to the source and use ant to get the jar file, you may modify the ant task as follows.

  <javac  destdir="${build.destDir}" srcdir="${build.srcDir}" source="1.6" fork="true" target="${javac.target}" debug="on" debuglevel="lines,vars,source" deprecation="on" memoryInitialSize="512m" memoryMaximumSize="1024m" optimize="true"   >

Happy debugging..

ref: http://doc.sumy.ua/prog/Java/javanut/ch16_04.htm

jayaram S
  • 580
  • 6
  • 13
7

It would help if you did indicate the version of eclipse you are using and the technology (Java JDT, or AJDT for Aspect Java, or C++ CDT for instance), just to be sure.

On the Java side, I suppose your "Ticked the checkbox from Compiler options" refers to this

Under "Window --> Preferences --> Java --> Compiler --> Classfile Generation", all 'Class file' generation options are set to True:

  • (1) add variable attributes,
  • (2) addline numbers,
  • (3) add source file name,
  • (4) preserve unused local variables.

Does your project have those checked only at the global level (windows Preferences) or at project specific level?

And are you sure the class opened (on which you try to set a breakpoint):

  • is one of your sources (and not coming from a third party library)
  • is a .java, not a .class?

Try to clean everything and rebuild all, check for potential jar conflicts.

Mark Storer
  • 15,672
  • 3
  • 42
  • 80
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Hi VonC, I am on Eclpise Ganymede, Java 1.6 Yes I have the settings globally. I am trying to set it on my own Java code written, so yes I do have the .java & .class files. And I did a javap on that class. It generates the line numbers – chandrajeet Jun 05 '09 at 21:34
  • @chandrajeet if you have those settings set globally, I supposed you checked your project does not override them with project specific settings ? If not, the only thing I see right now is to put breakpoints on .class instead of .java... – VonC Jun 05 '09 at 22:34
5

If nothing else works, open debug perspective, clear all existing breakpoints and then set them back again.

Christos
  • 846
  • 3
  • 15
  • 21
4

try to change the jre you use.Set the jre in the folder of JDK instead.

fairjm
  • 1,115
  • 12
  • 26
4

I had this problem while attempting to start Tomcat in debugging mode from Eclipse. I had an ANT build file taking care of the compile and deploy. After setting the debug flag to true (as mentioned in other answers) and redeploying the application it worked fine:

<javac srcdir="./src/java" destdir="./bin" debug="true">

NOTE: if you've just added the debug flag and recompiled you still need to redeploy your application to the server since this is where Eclipse is debugging the class files. Very obvious but easy to spend an hour or so scratching your head and wondering why it's not working (trust me).

chrisjleu
  • 4,329
  • 7
  • 42
  • 55
4

Since I have 6 different versions of Java installed, I had to change my default JDK compliance to match that of the Java version I wanted to use. Eclipse by default had compiler compliance level set to Java 1.7 when everything was built/compiled using Java 1.6.

So all I did was

  1. In eclipse menu, go to Window->Preferences->Java->Compiler
  2. Under JDK Compliance, I changed Compiler compliance level from 1.7 to 1.6

Now Eclipse doesn't complain about the "Unable to insert breakpoint Absent Line Number Information" anymore and the debugging breakpoints actually work!!!

eternalminerals.com
  • 395
  • 1
  • 4
  • 14
2

I had same problem when i making on jetty server and compiling new .war file by ANT. You should make same version of jdk/jre compiler and build path (for example jdk 1.6v33, jdk 1.7, ....) after you have to set Java Compiler as was written before.

I did everything and still not working. The solution was delete the compiled .class files and target of generated war file and now its working:)

pesoklp13
  • 339
  • 2
  • 11
2

Got this message with Spring AOP (seems to be coming from the CGLIB library). Clicking Ignore seems to work fine, I can still debug.

Mike R
  • 4,448
  • 3
  • 33
  • 40
2

I found yet another reason for this message. I was programming Scala. The solution was:

  1. Open Run -> Debug configurations
  2. In the Main tab, on the bottom, beside the "Apply" and "Revert" buttons, there is a text saying which Launcher you are using, and beside it, there is a hyperlink saying "Select other". It is a strange UI element, doesn't look actionable at first glance.
  3. Use the "Select other" link and choose "Scala Application (new debugger) Launcher". The other one doesn't seem to work with Scala.

Now the debugging should work. Notice that I have installed the Scala IDE plugin, this option may not be available if you don't have it.

rumtscho
  • 2,474
  • 5
  • 28
  • 42
2

Above things didn't work for me. Below solutions finally worked. Debug Configurations -> Classpath -> User Entries -> (Add src folder of the project you want to debug.)

Bosco
  • 3,835
  • 6
  • 25
  • 33
2

My situation was similar:

  • I was debugging a JUnit test
  • I was using Mockito to create a spy, as in spyTask = spy(new Task())
  • I put the breakpoint inside of the class that I was spying (inside Task.java)

This breakpoint generates the error in question, every time I run Debug As... > JUnit Test

To address the problem, I moved the Breakpoint 'up' into the actual test (inside TaskTest.java). Once execution stopped, I added the breakpoint back where I had it, originally (inside Task.java).

I still got the same error but after clicking "ok," the breakpoint worked just fine.

Hope that helps someone,

-gmale

gMale
  • 17,147
  • 17
  • 91
  • 116
1

I had the same error with JBoss 7.1.. And I did the same as Zefiro. Just ignored the error and i was able to place breakpoints normally. In my case i was building thought ant builder and this is my javac task:

<javac
        srcdir="${src.dir}"
        destdir="${build.classes.dir}" 
        includeantruntime="false" 
        debug="${debug}"
        verbose="false"
        debuglevel="lines,vars,source"
        source="1.6"
        target="1.6">

        <!-- Sppressing warning for setting an older source without bootclasspath
             (see: https://blogs.oracle.com/darcy/entry/bootclasspath_older_source) -->
        <compilerarg value="-Xlint:-options"/>

        <classpath>
            <fileset dir="${lib.dir}" includes="*.jar" />
            <fileset dir="${jboss.lib.dir}" includes="**/*.jar" />
        </classpath>

    </javac>
Garrafote
  • 11
  • 1
1

I had this same problem when debugging a WAR (constructed from multiple Eclipse project artifacts) deployed to Tomcat.

I am building everything using an ANT build script. If this is what you are doing, make sure that the debug=true flag is set on every javac ant task you've got. This was my only problem - I hope it helps your problem!

ubermensch
  • 902
  • 1
  • 12
  • 21
1

I got the same issue, I spent a lot of time to look for solution but these solutions are unuseful, So I self study all of cases, finally I found out problem it is confliction among JDK versions. Below is steps to resolve problem: 1. Remove all of JDK and JRE version, keep only one version. 2. Set JAVA_HOME system and java compiler in Eclipse is the same. In some cases, the error above will not disappear, but we be able to run at debug model.

Tommy Teo
  • 11
  • 1
1

Once I experienced the same error when I used junit and Mockito, I forgot to add @PrepareForTest for a static class.

Add below code fixed my problem.

@PrepareForTest({XXXXX.class})

Not sure it was the same case.

Infinite Recursion
  • 6,511
  • 28
  • 39
  • 51
Jonathan
  • 51
  • 4
1

My problem was I had 2 JAR's and I was trying to override one with the other based on its order in the Java Build Path => Order & Export tab in Eclipse, because one was for debugging and the other was not (the debugging JAR being first in the order). When I did it this way, I had to manually attach a source.

I tried removing the non-debug JAR and placing the debug JAR in my \WEB-INF\lib\ directory, cleaning, building, etc., and it worked. This time (having removed the attached source), it automatically would let me navigate through the debug code, without having to attach any source manually. Breakpoints and debug also worked.


In case anyone is still having trouble, I also tried all of these particular solutions mentioned in the other answers:

  • Uncheck, apply, and recheck Add line number attributes...
  • Manually editing org.eclipse.jdt.core.prefs as mentioned in another answer: https://stackoverflow.com/a/31588700/1599699
  • Ensuring the JAR was being generated with debug enabled.
  • Changing the JDK compliance level from 1.6 to 1.7 (thereby matching the JDK I was using).

I also did the usual shutting down of the server (and making sure java.exe is actually closed...), deleting the \build\ directories in both projects, restarting Eclipse with the -clean parameter, recreating the debug JAR, refreshing, cleaning, and building the project with the debug JAR in it, starting the server in debug mode, publishing/cleaning, and breakpointing.

Andrew
  • 5,839
  • 1
  • 51
  • 72
1

I was facing the same issue in my eclipse IDE. I read all answers of this question and tried almost all mentioned settings, but no luck.

So, I tried to changes the runtime lib of the project, previously it was JRE - Java SE 1.8 Default runtime

I tried changing the JRE to JDK and it worked for me:

JDK selected

Below are the steps to switch from JRE to JDK :

  • Right click on project
  • Click Properties -> Java Build Path
  • Select tab - "Libraries"
  • Click on "Add Library" button. "Add Library" window will open
  • Select "JRE System Library" -> Click Next button
  • Select "Alternate JRE"
  • Click on Installed JRE button
  • In New window click on "Add". This will open another window "Add JRE".
  • Select "Standard VM". Click Next.
  • Click on Directory button.
  • Choose path of your "JDK" installation directory and click ok. Then Click Finish.
  • Now check on newly added "JDK" Select on JDK

  • Delete all other installed JRE's from the list(Optional)

  • Apply-> OK
  • Select "JDK from alternate JRE dropdown and Click on "Finish" Alternate JRE
  • Now from the list depicted below remove JRE instance Remove unwanted JRE
  • Click Apply -> OK

And you are done!!

Shrirang Kumbhar
  • 363
  • 4
  • 17
1

I had the same error in my Eclipse IDE. But it seems it is an ignorable error. I pressed Ok on the error dialogue box & continued. My breakpoints were reached & i was able to debug further.

shikha singh
  • 498
  • 1
  • 5
  • 10
0

I ran into this problem as well. I am using an ant build script. I am working on a legacy application so I am using jdk version 1.4.2. This used to work so I started looking around. I noticed that under the Debug configuration on the JRE tab the version of Java had been set to 1.7. Once I changed it back to 1.4 it worked.

I hope this helps.

Greg
  • 57
  • 1
  • 2
  • 7
0

I was trying to debug the logging manager and needed to change the jre to a jdk and then to select this jdk in the "main" tab, "Java Runtime Environment" | "runtime JRE" of the debug configuration then all was well.

0

I saw this problem when I annotated a class with @ManagedBean (javax.annotation.ManagedBean). The warning message came up when running the newly complied app on JBoss EAP 6.2.0. Ignoring it and running anyway did not help - the breakpoint was never reached.

I was calling that bean using EL in a JSF page. Now... it's possible that @ManagedBean is no good for that (I'm new to CDI). When I changed my annotation to @Model, my bean executed but the breakpoint warning also went away and I hit the breakpoint as expected.

In summary it certainly looked as though the @ManagedBean annotation messed up the lines numbers, regardless of whether or not it was the wrong annotation to use.

PMorganCA
  • 730
  • 6
  • 24
0

Make sure the project in which the main class of the runtime is, is the same project in which is the class you have breakpoints in. If not, make sure both projects are in the classpath of the run configuration, and appear before any jars and class folders.

Eugene Marin
  • 1,706
  • 3
  • 23
  • 35
0

I had the same issue with one specific project and I kept trying to reset the line number attributes in Window->Preferences... Then I realized each project has it's own settings for line number attributes. Right click the project, go into properties, choose JavaCompiler, and check the box to "Add line number attributes..."

Amber
  • 2,413
  • 1
  • 15
  • 20
0

I did all of what is listed above while compiling/building the jars - still had the same issue.

Eventually, the jvmarg changes listed below while starting the server is what finally worked for me:

  1. Removed/Commented a bunch of jvm args pertaining to javaagent and bootclasspath.

<!-- jvmarg value="${agentfile}" /-->

<!-- jvmarg value="-javaagent:./lib/foobar /-->

<!-- jvmarg value="-Xbootclasspath/a:/foo /-->

  1. Turned on/un-commented the following line:

<jvmarg value="-Xdebug" />

Then when I start the server, I am able to hit my breakpoints. I suspect that the javaagent was somehow interfering with Eclipse's ability to detect line numbers.

Chris
  • 3,400
  • 1
  • 27
  • 41
crazy horse
  • 423
  • 2
  • 10
  • 25
0

If above solution doesn't work and you started to get that problem after you did a spring bean injection, problem can be that you didnt use interface for injected class. Try to do injection with class which implements an interface would solve the problem. For an example follow the link: Unable to install breakpoint problem for bean creation

Mustafa Kemal
  • 1,292
  • 19
  • 24
0

I had similar issue on Spring MVC + Maven project; and spent 2 hours trying to figure out why target folder does not get updated with classes containing information about lines.

I suggest you clean everything and make sure all classes are deleted from the folder before you proceed with any build.

  1. Make sure that in Project's Properties > Java Compiler has "Add line number attributes to generated class fiels (used by the debugger) selected.
  2. Clean all project.. (Menu > Project > Clean...) Make sure that the target folder is empty.
  3. Build project (Menu > Project > Build Project)
  4. Make sure new classes are generated in your target directory.
  5. Run Debug; if running on WebServer - make sure you run your webserver in "Debug" mode.

If in doubt - whether compiled .class files contain line numbers or not - open the .class files in Eclipse. The Eclipse will decompile the files and tell you whether Line numbers exist or not.

enter image description here

Witold Kaczurba
  • 9,845
  • 3
  • 58
  • 67
  • I was facing the same problem, using Spring Boot and trying to debug a test class. Turns out I had not instantiated the class I was trying to inspect, and, therefore, it was accusing this error and throwing a NullPointerException. I'd also recommend checking if your variables are being instantiated correctly. – malvadao Jul 09 '18 at 19:06
0

I tryed most of the previous solutions, and still had the problem. This is what I did next:

  • Removed the application from Eclipse
  • Stoped the server
  • Delete the application folder from webapps
  • Delete content from the temp folder in the server
  • Delete content from the work folder in the server
  • Re-open the application on Eclipse
  • Start the server

May be some of this steps are not needed, but "just in case".

So if the previous solutions still not work for you. Try this. I hope it helps ;-)

Roberto Rodriguez
  • 3,179
  • 32
  • 31
0

For Web project with Tomcat server, I resolved it by using following steps.

  1. Open Window -> Show view -> Other -> Servers.
  2. Double click on the running tomcat server. (Overview of tomcat server will be opened)
  3. Now Click on Launch configuration link.
  4. Click on the sources Tab.
  5. Click on Add.
  6. Choose java project
  7. All your projects will be displayed.
  8. Select the on You want to debug.
  9. Save the configuration and Restart or build the application again.
  • This will get you the debugging (at least it did for me) but be aware that it is debugging the version you have put in your path NOT the "Default" one which is what you have in your editor. You'll need to remove and re-add for any changes made in the editor to be reflected in the debugging. – Scala Enthusiast Jan 18 '19 at 13:18
0

We have very useful information to solve this problem already, but in my specific case, the problem was that as I did an update to my project from the repository, new classes were generated with the compiled source from the newest code. The problem is that I forgot to change the versions of the projects in my POM files and as the breakpoints were set on the new code and the POM files were still pointing to old versions that were available on the JAR files of a previous compilation, the classes from the JAR files were chosen and not the classes from the new code.

In resume, to resolve this I just had to update the versions on the POM file of the main project, clean and recompile the source code and finally refresh the environment. I hope that this can be useful to somebody else.

jfajunior
  • 1,211
  • 1
  • 15
  • 19
0

How to fix breakpoint error when debugging in Eclipse? Replace what you have with this lines only.

    eclipse.preferences.version=1
org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.8
org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve
org.eclipse.jdt.core.compiler.compliance=1.8
org.eclipse.jdt.core.compiler.debug.lineNumber=generate
org.eclipse.jdt.core.compiler.debug.localVariable=generate
org.eclipse.jdt.core.compiler.debug.sourceFile=generate
org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
org.eclipse.jdt.core.compiler.source=1.8
Titi
  • 103
  • 1
  • 3
  • 12
  • This link has a solution https://stackoverflow.com/questions/20344230/how-to-fix-breakpoint-error-when-debugging-in-eclipse/31588700#31588700 – Titi May 21 '19 at 20:38
0

If someone is trying to debug Java's source code, then, this is the only solution that worked for me. Most of the above answers talk about setting the Compiler option to generate line numbers.But, if want to debug Java's source code (say java.util.HashMap), then the above options may not work for you. This is because , the project from where you intend to debug the source code is having the Java Build Path --> Library --> JRE System Library pointing to the jre jar instead of the jdk jar. The classes bundled inside jre jar have already been pre-compiled with a specific option, that will not honor the Compiler option settings. Solution, is to reconfigure your project to have the JRE System Library point to the jdk jar. The classes inside your jdk jar will honour the Compiler option settings. So, once you update your project's JRE System Library to point to the jdk jar, debug on Java source code will start working.

Binita Bharati
  • 5,239
  • 1
  • 43
  • 24
0

First of all I really recommend to make sure if it's issue related to project or to the single test file. Just try running any other test file in debug mode.

If the issue applies to one file only it may be related to self-mocking (as it was in my case). Otherwise compiler/building settings should be changed. All has been already described in previous comments.

I just wanted to stress this out. It's enough I wasted time on fixing project settings while it was completatly unecessary :)

Zaworov
  • 133
  • 1
  • 5
0

Check/do the following:

1) Under "Window --> Preferences --> Java --> Compiler --> Classfile Generation", all options have to be to True:

(1) Add variable attributes...
(2) Add line number attributes...
(3) Add source file name...
(4) Preserve unused (never read) local variables

2) In .settings folder of your project, look for a file called org.eclipse.jdt.core.prefs. Verify or set org.eclipse.jdt.core.compiler.debug.lineNumber=generate

3) If error window still appears, click the checkbox to not display the error message.

4) Clean and build the project. Start debugging.

Normally the error window is not displayed any more and the debugging informations is displayed correctly.

-1

We also have this message when starting the Java EE project with the Spring Tool Suite (STS), but we are in the good position just to ignore this message, as everything works fine.

Sae1962
  • 1,122
  • 15
  • 31