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.


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.


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.


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.


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.


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.


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.


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..."


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


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


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 ;-)


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.


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.


how to fix breakpoint error when debugging in eclipse? replace what you have with this lines only.



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.


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 :)


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!


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:


        <!-- sppressing warning for setting an older source without bootclasspath
             (see: -->
        <compilerarg value="-xlint:-options"/>

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



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.


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.


not sure it was the same case.


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:
  • 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.


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!!


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.


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

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 once execution stopped, i added the breakpoint back where i had it, originally (inside

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

hope that helps someone,



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:)


got this message with spring aop (seems to be coming from the cglib library). clicking ignore seems to work fine, i can still debug.


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.


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.)


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).


try to change the jre you use.set the jre in the folder of jdk instead.


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!!!


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


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.


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="${}" debug="on" debuglevel="lines,vars,source" deprecation="on" memoryinitialsize="512m" memorymaximumsize="1024m" optimize="true"   >

happy debugging..



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


this is explained in detail here:

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".


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.


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:


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.


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.

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();

public class testserviceimpl implements testservice {
   public void dosomething() {
      system.out.println("hello testserviceimpl");


this fixed my issue:

  1. window -> preferences -> server -> runtime environments
  2. apache tomcat -> edit
  3. select a jdk instead of jre


  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


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 :)

Related Query

More Query from same tag