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.
I have an interface with some methods defined. When I check on the explorer it says that these methods have default (package) access, while the default access in a interface should be public. That is, in an interface the method: void test() is public, while in a class is default (package) I noticed this because the Autocomment feature makes the same mistake, but I assumed the mistake should be in some parser that then feeds the information to all other components in NetBeans.
Sorry, you are mistaken. "Default access" does not mean "package private" - at least not by definition in the JLS. It means "package private" for class members and "public" for interface members. The IDE displays the access restrictions recorded in the source code; what you are asking for is displaying effective access rights.
It seems we use different names... :-) Many books (ex. Thinking in Java) call the "package private" access "default" access. I'll use your definition. So, you agree that default access in an interface means public, and not package private. Now, try to autocomment an interface, in which you have a method that you left default. In AutoComment you have to select package to have it displayed. It seems to me that throughout the IDE there are some inconsistencies on this subject. The icons in the explorer are correct, since the manual says that the golden lock is for default access, and not package access. But the debugger uses the golden lock on a button that has a tooltip that says "package private". The autocomment has the same button, but with a tooltop that says "package". But the golden lock in the explorer is "default". I haven't checked, but the Object browser might behave in the same way. I think that fixing all of this shouldn't be considered an enhancement. But I'll let you decide... :-)
Well, my terminology comes from language spec :-) and it indeed defines different access for class members when access modifier is omitted than for interface members. I have put Hanz on CC:, he's responsible implementation in the debugger. Object browser and explorer use the same visual code, so they are consistent.
Cleaning up before 4.0 planning
See also issue #24405.
Target milestone was changed from not determined to TBD
*** This issue has been marked as a duplicate of 18206 ***