This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 240278 - Cannot start debugging while scanning sources from an unrelated project
Summary: Cannot start debugging while scanning sources from an unrelated project
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 8.0
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Tomas Zezula
Depends on:
Reported: 2014-01-11 14:14 UTC by IrianR
Modified: 2014-07-28 17:53 UTC (History)
2 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description IrianR 2014-01-11 14:14:24 UTC
[ BUILD # : 201401091443 ]
[ JDK VERSION : 1.7.0_45 ]

   1 - Open a random test project.
   2 - Open a big project that requires scanning completely unrelated to the
previous test projects (The 2 projects from the Debugging During Source
Indexing test suite should be fine).
   3 - Invoke the Debug project action.

   Please wait classpath scanning in progress popup appears.

   debugging starts normally.

NOTE: I'm fine with the current behavior when the project being scanned is
related in some way with the debuggee, but if the 2 projects are not related in
any way the background scanning of one should not block debugging of the other.

Debugging During Source Indexing test suite URL:
Comment 1 Ondrej Vrabec 2014-07-16 08:30:19 UTC does not allow to debug or even run the project:if (getJavaModelActions().contains(command) || (isCompileOnSaveEnabled
Comment 2 Ondrej Vrabec 2014-07-16 08:30:51 UTC
... stupid login. So again: does not allow to debug or even run the project:
if (getJavaModelActions().contains(command) || (isCompileOnSaveEnabled && getScanSensitiveActions().contains(command))) {
    //Always have to run with java model
    ScanDialog.runWhenScanFinished(action, commandName(command));

so this may actually be an issue with the BaseActionProvider, however i have no idea this is supposed to work. BTW it works when Compile On Save is off for the project so the ability to run scanning and debug in parallel may be limited only to the option being turned off.
Martin or Jirka Kovalsky (author of the test spec?) needs to evaluate and tell what behavior is correct.
Comment 3 Jiri Kovalsky 2014-07-16 11:17:29 UTC
I guess you meant "...the option being turned on." not off.

This behavior comes from the fix of issue #206137 i.e. since NetBeans 7.2 so from that point of view there is not regression. If "Compile on Save" is turned OFF it's both possible to start debugging and step through code while the other project is being scanned. However, for "Compile on Save" option turned ON it's not possible to start debugging even though there is no relation between the two projects. This should be possible so this is a valid bug.

Product Version: NetBeans IDE 8.0 (Build 201403101706)
Updates: NetBeans IDE is updated to version NetBeans 8.0 Patch 2
Java: 1.7.0_65; Java HotSpot(TM) 64-Bit Server VM 24.65-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_65-b17
System: Linux version 3.13.0-24-generic running on amd64; UTF-8; en_US (nb)
Comment 4 Martin Entlicher 2014-07-23 06:28:05 UTC
Apparently, this concerns Run action as well. In BaseActionProvider, it's out of scope for debugger, and it should be solved in general for all scan-sensitive-actions.
Moving to Java to evaluate whether the logic can be modified not to consider class path scanning running in unrelated projects.
Comment 5 Tomas Zezula 2014-07-28 17:53:05 UTC
The debugger cannot be started when project uses Compile On Save (CoS is on).
The reason is that runtime classpath (runtime dependency) may differ from compile time dependency and may contain some not yet scanned project which implies that the class files do not exist yet. One of the thing the scan is doing is creating class files for Compile On Save.
Another case is dynamic class loading using URLClassLoader.
While the first case can be solved by comparing the runtime classpath with scanned roots + dependencies.
The second cannot be solved at all. But the second case is not common.