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.

Bug 27853 - Do not expose public packages transitively from modules
Summary: Do not expose public packages transitively from modules
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Jesse Glick
Keywords: API
Depends on:
Reported: 2002-10-07 18:40 UTC by Jesse Glick
Modified: 2008-12-23 08:36 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-10-07 18:40:48 UTC
Currently if A exposes some (or all) public
packages, and B depends on A and maybe exposes
some of its own packages, then if C depends on B,
it can use classes from either A or B. In
practice, this is not desirable because it forces
B's dependency on A to be a part of its effective
API, whether it wants this to be true or not.

This issue proposes to change the semantics, so
that C could only use classes from A if it
declared an explicit dependency on A as well as on B.

For example, the ant module provides a small API
in*. It also
*currently* depends on
org.netbeans.modules.javahelp, so that it can
programmatically show help sometimes. But this
dependency is an implementation detail. It is
undesirable for every module depending on the ant
module to automatically have an "invisible"
dependency on JavaHelp. Currently this could only
be solved by splitting up the intermediate module
(B = ant) into B1 with an ant API and B2 with an
impl of the module, incl. showing help, so that
other modules depending on B1 would not have their
namespaces "polluted" by JavaHelp.

Another example would be a module which both
provides an API and depends on e.g. some Xerces
impl. You definitely do not want modules using
this API to automatically see Xerces - for one
thing, they would be unable to directly use their
own private Xerces impl without classloader tricks.

For compatibility reasons, modules like C with old
API spec dependencies would be assumed to
effectively depend on the transitive closure of
their declared dependencies, permitting C here to
use classes from A until it asks for new APIs, in
which case it would need to either stop using
classes from A or declare that dependency
explicitly. Although the Modules API was never
very clear on this question, for safety it is best
to assume that some modules were depending on the
old behavior.
Comment 1 Jesse Glick 2002-10-07 18:41:33 UTC
Already have a unit test demonstrating the current behavior (with a
Comment 2 Jesse Glick 2002-10-08 21:19:33 UTC
In directory core:
committed   * Up-To-Date  1.6         core/
In directory core/src:
In directory core/src/org:
In directory core/src/org/netbeans:
committed   * Up-To-Date  1.8        
committed   * Up-To-Date  1.9        
In directory core/src/org/netbeans/core:
committed   * Up-To-Date  1.162      
In directory core/src/org/netbeans/core/modules:
committed   * Up-To-Date  1.38       
committed   * Up-To-Date  1.7        
committed   * Up-To-Date  1.44       
committed   * Up-To-Date  1.49       
In directory core/test:
In directory core/test/unit:
In directory core/test/unit/src:
In directory core/test/unit/src/org:
In directory core/test/unit/src/org/netbeans:
In directory core/test/unit/src/org/netbeans/core:
In directory core/test/unit/src/org/netbeans/core/modules:
committed   * Up-To-Date  1.22       
committed   * Up-To-Date  1.4        
committed   * Up-To-Date  1.3        
added       * Up-To-Date  1.1        
committed   * Up-To-Date  1.14       
In directory core/test/unit/src/org/netbeans/core/modules/jars:
committed   * Up-To-Date  1.2        
added       * Up-To-Date  1.1        
added       * Up-To-Date  1.1        
added       * Up-To-Date  1.1        
added       * Up-To-Date  1.1        
added       * Up-To-Date  1.1        
In directory
In directory
added       * Up-To-Date  1.1        
added       * Up-To-Date  1.1        
In directory openide:
committed   * Up-To-Date  1.75        openide/
In directory openide/api:
In directory openide/api/doc:
In directory openide/api/doc/changes:
committed   * Up-To-Date  1.99       
In directory openide/api/doc/org:
In directory openide/api/doc/org/openide:
In directory openide/api/doc/org/openide/doc-files:
committed   * Up-To-Date  1.5        
committed   * Up-To-Date  1.37       
Comment 3 pzajac 2002-11-05 16:13:09 UTC
verified in nb 200210300100. It looks fine. No class loaded on
transitive depedency.