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.
The freeform project returns different ClassPath instances for single file & single type. It violates the ClassPath contract, the ClassPath is a live object the clients listen on. When you return the other isntance the clients still listen on the old instance. Steps to reproduce: 1) Download freeform project: http://download.java.net/media/java3d/bugs/nb-bugs/113765.zip 2) Open j3d-core project 3) Open VirtualUniverse class, there is some error complaining about VersionInfo 4) oldBootCP = ClassPath.getClassPath (VirtualUniverse,BOOT) 5) Open project customizer, remove the build/default/debug/gen/classes/ from ClassPath and add it to SourcePath 6) Error: the ClassPath.getClassPath (VirtualUniverse,BOOT) != oldBootCP.
Milan, reproducible for you?
Yes, I'm working on it.
Lowering priority to P3 as agreed upon with Tomas.
:-)
The problem is that if new source root is added/removed to/from CU new MutableClasspathImpl is created for the List of CU source roots and the new CP is then returned for the same FO and then others listening on original CP are not notified.
Not sure offhand how to fix. Perhaps it is possible to change Map<String,Map<List<String>,MutableClassPathImplementation>> mutablePathImpls to Map<String,Map<String,MutableClassPathImplementation>> mutablePathImpls and have several keys map to the same value? Then Classpaths.getPath would look for a match in keys of mutablePathImplsByType among _any_ of packageRootNames, and store the path back in _all_ of them. I think that would address the problem in this issue. This would however not work if you split apart a single CU into two CUs, etc. Fundamentally I don't see how the "ClassPath contract" (which I do not see written anywhere) could possibly be honored in all such cases. What is the actual problem that gave rise to this bug report? If it is just that the old ClassPath instances do not continue to fire changes when expected, that should be more easily addressed: currently the listener is Classpaths (see pathsChanged method), but I think it could just as easily be MutableClassPathImplementation, which would ensure that changes are fired regardless of whether a given ClassPath object is the currently "official" one. Such a fix would be desirable in any case.
*** Issue 46791 has been marked as a duplicate of this issue. ***
See last comment in issue #46791. If there were some definite contract for the behavior of ClassPath, it sounds to me like that would be violating it, but I guess so long as java/source is happy with that behavior then use it.
We (java/source) don't have much problems with current state. It works in nearly all cases, the only problem was when someone removed the source root from the compile classpath (don't know why it was there when the javac doesn't complete sources on the compile classpath) and readd it into source path. In this case we know only about the old classpath not about the new one which was created and we didn't know about next changes. After restart everything was OK.
*** Issue 128711 has been marked as a duplicate of this issue. ***
moving opened issues from TM <= 6.1 to TM=Dev
Changing the default component owner to tzezula.
Bug prior to 7.0, not touched for the last 2 years --> P4.
Definitely not P4 as it is a source of several scanning problems.
(In reply to comment #13) > Bug prior to 7.0, not touched for the last 2 years --> P4. Sorry, I do not think that this could be a valid reason for P4.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss