Summary: | IPackageBinding#getName() should return "" for default package | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | minor | ||
Priority: | P3 | CC: | jeem, kent_johnson, philippe_mulet |
Version: | 3.0 | ||
Target Milestone: | 3.1 M2 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Markus Keller
2004-09-15 03:28:52 EDT
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. |