Community
Participate
Working Groups
The Javadoc of IPackageBinding#getName() says: "[..] For unnamed packages, this is a distinctive string that can be used to refer to this unnamed package (since there may in fact be multiple unnamed packages). [..]" How can IPackageBindings refer to different default packages? As I understand it, an IPackageBinding is a compiler-world notion that only knows one default package whose contents are based on a java project's buildpath. Since getName() cannot return different strings, I opt to change the string for the default package from "UNNAMED" to "". This would match IPackageFragment#getElementName() and eliminate the need for special code when comparing an IPackageBinding to an IPackageFragment.
This is trivial to change. Jim, would this be still in line with the specs?
Kent confirms that there are multiple default/unnamed packages at the compiler level (each project has its own). This distinction should be visible at the DOM binding level as distinct package bindings with distinctive names. That way clients can know whether the packages they encounter are from the same or different unnamed package. So the spec is right, and the implementation has a bug.
Jim: Your argument would also apply to named packages. You can have two package fragments with the same name in two projects, and there's no API to differentiate them in the bindings world. AFAIK, bindings are only defined in the context of one project - and there, they're unique. The distinction among package fragments from different projects is only represented in the java model (IJavaElement) world.
Markus, I believe default/unnamed packages are different from named packages. Here's a case that I thought would show off the difference: (1) Set up projects P1 and P2 with P2 depending on P1 (2) Foo.java in default/unnamed package of project P1 (3) Bar.java in default/unnamed package of project P2 Code for Bar references Foo (no import). Bar should not be able to reference Foo. Even though Foo and Bar are both in default/unnamed packages, there are considered to be in different ones. However, when I tried this, it compiled without errors. Kent, What have I got wrong?
It appears I misunderstood. Markus is correct. The compiler's treatment of default/unnamed packages is no different from named packages. I've changed the spec and implementation for IPackageBinding.getName() to always return "" for the unnamed/default package. This API change should not break existing clients because the previous spec did not specify what string would be returned. Olivier, I've fixed tests as well and updated build notes.
Verified in I200409230100.
