Community
Participate
Working Groups
Steps to reproduce: 1. In the Eclipse IDE, have a dummy 'Hello world' project 2. export as executable jar with a Main. 3. In your IDE, modify the code so it says something else ("Hello Universe"), so the IDE content is now different from the content of the jar. 4. run `java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044 HelloWorld.jar` 5. Place a breakpoint on HelloWorld main() method 6. Remote debug app (monitoring Hello World project and port 1044) and see breakpoint hit. 7. Click "continue" POSSIBLE EXPECTATION: (without more context and by habit) Hello Universe GOT: Hello World The local change in my IDE are not hot releaded until I make a modification in the file. As this is a corner-case, I don't think we should try to match the expectation and automatically hot-reload the class when breakpoint is hit; but it would be great to find a way to warn the user about such inconsistency, and propose them to either "ignore and continue" or "hot-reloard and continue" when hitting the breakpoint and class differs in debug vs target.
Can you describe - >> The local change in my IDE are not hot reloaded until I make a modification in the file.
I mean that the local change I made in my code before the debugger is attached are not propagated, and there is no information about it nor a easy way to force reload from IDE to debugged application.
Not sure, but it will actually depend if JVM gets any information about agent library change.
We can have the case in Quarkus where reference build (mvn) modifies the classes and start a debug session. Then attaching the debugger results in erroneous debugging because .class in IDE and at runtime are different, and there is no good information about this, so users get very confused.
(In reply to Mickael Istria from comment #0) > 3. In your IDE, modify the code so it says something else ("Hello > Universe"), so the IDE content is now different from the content of the jar. I'm right in the assumption, that your remote app uses *jar* files, and you want Eclipse debugger to replace the content of those files on the fly in the remote application? I don't see how we can do this. In the past as I've worked with WebLogic based Java app I wrote FileSync plugin (http://andrei.gmxhome.de/filesync/index.html) to doing exactly that: on resource changes, automatically re-deploy (copy) changed assets to the target server directory. If the server loader is clever enough, it will then do a hot re-deploy and you would see the changed classes matching those in debugger. From my POV, this is won't fix. Debugger can't help with deployment issues and can't know at which version of sources the remote application was compiled.
(In reply to Andrey Loskutov from comment #5) > I'm right in the assumption, that your remote app uses *jar* files, and you > want Eclipse debugger to replace the content of those files on the fly in > the remote application? I don't want the IDE/debugger to modify anything beyond what it already can do. As mentioned in the title, I'd like the IDE to verify that the content of the editor (or its local .class files or whatever it uses internally) isn't in sync with what's being debugged; and to at least warn about it.
(In reply to Mickael Istria from comment #6) > (In reply to Andrey Loskutov from comment #5) > > I'm right in the assumption, that your remote app uses *jar* files, and you > > want Eclipse debugger to replace the content of those files on the fly in > > the remote application? > > I don't want the IDE/debugger to modify anything beyond what it already can > do. As mentioned in the title, I'd like the IDE to verify that the content > of the editor (or its local .class files or whatever it uses internally) > isn't in sync with what's being debugged; and to at least warn about it. Sorry, had a different impression. So debugger should verify if the loaded class is compiled from the current source state in the workspace, and if not, report a warning? Note the class will also differ if only one empty line was added or class compiled with a different JLS level or by a different compiler from same source (maven vs ecj). So the "stable" solution would be only to compare binaries byte wise. Of course one will not do this for all loaded classes, so let say only for classes with breakpoints. So one would need to have an agent that knows which classes were loaded from where by the JVM so that it can check the corresponding workspace classes or a breakpoint listener or source lookup code that will do this on breakpoint hit / source lookup. Something in bug 506149 (advanced source lookup) direction.
