Alexei Fedotov wrote:
every module already depends on luni module
I found luni dependencies in the following modules:archive auth, awt,
imageio, nio, prefs, security, sql, suncompat, text, x-net. Others
does not seem to depend from luni. Looking deeper into these
The dependency I mean include both public API and internal API, so no
one could escape from luni ;) , and I agree with you that the dependent
of internal API should be removed first.
dependencies I convinced myself that it might be a good idea to
separate generic java helpers which resided in
org.apache.harmony.luni.util into a separate helper module. I believe
+1
Does "misc" module do for this?
this should not apply to the PriviAction: this secure utility should
be moved to the security module instead to keep things properly
packed.
This just move the dependency from luni to security module, if we still
use PriviAction. I didn't look implementation of PriviAction deeply, but
if it was mess as Nathan said, we can clean it up first :)
Most packages use java.lang.* but not necessarily internal
undocumented helpers. This allows plugging our library modules into
different VMs using standard interface.
Thanks.
On Tue, Dec 23, 2008 at 8:36 AM, Regis <[email protected]> wrote:
Nathan Beyer wrote:
On Mon, Dec 22, 2008 at 11:15 PM, Kevin Zhou <[email protected]>
wrote:
Nathan, thanks for your comments.
Nathan wrote,
This would create a dependency on every module to an implementation
package in LUNI.
Yes, that would be.
I'd suggest each module create one helper class, as needed, and reuse
that
internally.
Adding an internally-used helper class can improve modularity. But I
doubt
that it may bring redundant codes.
For example, both LUNI and Security needs to access the system
properties.
In fact, PriviAction implements PrivilegedAction and only provides
services
to get system properties, security properties and so.
I understand, but eliminating redundant code isn't an absolute value
-- it's not always a good thing. Reuse must be balanced with the
requirements of modularity and the needs of isolation.
Yes, it's trade off, but seems every module already depends on luni module,
another helper class may could not help more.
-Nathan
As I recall, PriviAction is quite an ugly class - it's rather a mess.
What about improving this helper class instead of adding an internal
helper
classes in each module?
--
Best Regards,
Regis.
--
Best Regards,
Regis.
