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 state of j2ee/utilities API during j2ee review (issue 52155) was horrible so much that the reviewers agreed on a separate review for this module, which in opinion of several reviewers acts as a trashcan for everything that does not fit anywhere else and as such should not be exposed to public. As the module is already in codebase, the review shall happen as soon as possible.
Agreed. The module should not have any public packages. Could we make the modules that have used these "public packages" implementation dependedent on j2ee/utilities as a short term solution. Is there any other solution, that doesn't involve a lot of file copy operations?
One other comment we go in the review was to try to either eliminate the impl dependecies or at least isolate the code that other modules depend on into separate package -- to make it clear what is the private contract and what really should not be used (see 54471). I would prefer to create friend API for anything that is used by multiple clients and should stay there (perhaps some UI code) and remove/refactor the rest (move it in the modules that use it). If we (me, Vince, ?) do not find time for this in the next 2-3 weeks or so then I agree with Vince to use impl dep as a backup solution (54471 is not TCR, only TCA).
Jarda and devrev agrees with P2. The friend API is not targeted for external users (outside enterprise cluster).
Asking for waiver for 4.1. Friend API, not targeted for users outside of enterprise cluster. Needs significant work before parts of it can become a valid API, the rest should not be an API.
I have submitted a separated api review Issue #57556 regarding the api cleanup.
57556 is fixed so the only thing that remains is to change the public packages to friend and list the users explicitly.
fixed - see commit log in issue 54471
v.