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 246147 - Extended ClassPath by Flags.
Summary: Extended ClassPath by Flags.
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 8.0.1
Hardware: All All
: P3 normal (vote)
Assignee: apireviews
Depends on:
Blocks: 245155
  Show dependency tree
Reported: 2014-07-30 20:36 UTC by Tomas Zezula
Modified: 2014-08-21 12:06 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Diff file (39.98 KB, patch)
2014-07-30 20:40 UTC, Tomas Zezula
Details | Diff
Diff file (47.69 KB, patch)
2014-07-31 10:20 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2014-07-30 20:36:41 UTC
Added ClassPath.getFlags() returning the ClassPath's flags.
Currently just INCOMPLETE flag is defined.
An INCOMPLETE ClassPath is not scanned unless it's resolved and the INCOMPLETE flag is removed.
Comment 1 Tomas Zezula 2014-07-30 20:40:12 UTC
Created attachment 148432 [details]
Diff file
Comment 2 Jaroslav Tulach 2014-07-31 08:59:26 UTC
Y01 I can't find a single test.
Y02 I would add <usecase> tag into arch.xml and describe what this is good for - I mean you asked some questions about proper behavior in an email - adding them and their answers into documentation would imho be ideal.
Comment 3 Tomas Zezula 2014-07-31 09:05:13 UTC
Y01: OK, I will add.
Y02: Unfortunately I don't have the answers ;-)
Comment 4 Tomas Zezula 2014-07-31 10:20:32 UTC
Created attachment 148438 [details]
Diff file

Added Unit Tests
Comment 5 Tomas Zezula 2014-07-31 10:36:19 UTC
Opened questions:
The ClassPath.Flags.ICOMPLETE flag is used to signal the language infrastructure that the classpath is in transient state (e.g. Maven project before build with no downloaded artefacts) and it should not be analysed. Also the directly dependent classpath should not be analysed. The goal is to solve the double scan when a Maven project is opened. The open causes first scan with lots of errors. The second scan comes after the build which downloaded the artefacts, and resolves errors from the first build.
This proposed patch solves the problem. The first scan is not done and a special error is added into beginning of each java file "Missing mandatory ClassPath entries, Resolve Project Problems".

The open question what to do with a transition from INCOMPLETE to COMPLETE state, e.g. users adds a new dependency to pom.xml.
Currently such a transition disables scanning of already scanned root. Errors in the editor are kept and extended by "Missing mandatory ClassPath entries, Resolve Project Problems".
As such a root is unregistered from parsing.api it's not scanned anymore which implies that new types, methods, etc. in such root are not available in code completion and navigation. This seems to me unacceptable.
Comment 6 Tomas Zezula 2014-07-31 10:37:50 UTC
Changing fast API review to regular API review due to opened questions which needs to be resolved.
Comment 7 Jaroslav Tulach 2014-08-04 11:59:50 UTC
When ClassPath changes from COMPLETE to INCOMPLETE, I would prefer to keep as much from previous information and use it up until when it becomes COMPLETE again - then let's update all the internal information:

- if user adds new library dependency
- if user removes JAR of already indexed library

let's continue working with the information available before the user action. Once the JAR of new dependency or old dependency is downloaded (and ClassPath becomes COMPLETE again), re-scan the whole project.
Comment 8 Tomas Zezula 2014-08-21 06:57:42 UTC
I am going to integrate the patch.
Comment 9 Tomas Zezula 2014-08-21 12:06:18 UTC
Fixed jet-main 82910b5636e9