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.
dev build 200811011401 1) Add http://download.java.net/maven/2/com/sun/jersey/jersey-multipart/1.0.1-SNAPSHOT/jersey-multipart-1.0.1-SNAPSHOT.jar to the library classpath 2) Add http://download.java.net/maven/2/com/sun/jersey/jersey-multipart/1.0.1-SNAPSHOT/jersey-multipart-1.0.1-SNAPSHOT-sources.jar to the library sources 3) The Javadoc comes up for all methods except BodyPart.getHeaders(). 4) When you try code-complete against this method two lines get added to messages.log: INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve: ElementHandle[kind=METHOD; sigs=com.sun.jersey.api.multipart.BodyPart getHeaders ()Ljavax/ws/rs/core/MultivaluedMap; ] WARNING [org.netbeans.api.java.source.JavaSource]: ClassPath identity changed for AbstractFileObject@cea9c8f[com/sun/jersey/api/multipart/BodyPart.java], class path owner: null
The problem is as follows: the BodyPart.getHeaders() method returns a type that is not on the classpath. So, the signature of the method load from the class file is not the same as the signature of the method in the parsed source. I do not think it is a big problem - the code will be likely uncompilable anyway without fixing the classpath.
> The problem is as follows: the BodyPart.getHeaders() method returns a type that is not on the classpath. It is actually on the classpath. It's declared by JAX-RS which ships with Netbeans. Did you mean it's *sources* aren't available? > So, the signature of the method load from the class file is not the same as the signature of the method in the parsed > source. I don't understand what you mean here. > I do not think it is a big problem - the code will be likely uncompilable anyway without fixing the classpath. Okay, by this point I can pretty much say something is off because the code compiles and runs just fine on my end...
[nudge] Still waiting for your reply. I didn't want you to forget about this as you've already flagged the issue as P4 and "future". Let's please agree on the evaluation before setting these two...
I reset the priority to P3 and target milestone to TBD because I just noticed that: - My project contains the JAX-RS 1.0 library as well as Jersey. - When I open BodyPart or any other Jersey class that references MultivaluedMap the editor underlines them in red as if they are not in the classpath, but clearly, they are (in the JAX-RS 1.0 library). This looks to me like a bug in the java parser.
Turns out this was caused by the fact that one of my open projects had two versions of Jersey in its class-path. One version had no associated sources whereas the other did. The duplicate definition seemed to have confused the heck out of Netbeans and led to all sorts of miscellaneous errors. Upon removing one of the versions and regenerating the cache (by deleting the directory and restarting) the problem went away. Is there a way for us to detect such conflicts in the future and at least warn about them? For example, Netbeans could warn if a substantial number of the same classes are declared multiple times within different libraries. What do you think? Perhaps you have a better idea?
Another issue is that code-complete doesn't seem to take the "focused project" into consideration (correct me if I'm wrong). If I have two unrelated projects open, and I invoke code-complete on one, I get shown classes that come from the other project's libraries. This could cause problems if say two open projects use different versions of Jersey.
BTW, the problem was exacerbated by the fact that Netbeans was adding Jersey 1.0 JARs to the project behind my back: issue 155727
Overtake.
Lowering priority, this issue should be affected by indexing of classes. It also can be affected by classpath construction. The reason to lowering priority is non-standard project configuration.
Reassigning all moonko's java/source bugs to myself.
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