Stanley M. Ho wrote:
Andy Piper wrote:
...
1. The ability to express a feature in terms of its constituent
packages. Note that import-by-name doesn't really help here since the
actual packages are distributed across multiple modules. What I
really want is some kind of feature module that exports these
packages to you when you ask for the feature.
Unless I miss something, this is the main use case that import-by-name
would address. Developers can package all the classes related to a
feature (e.g. networking, xml, swing, ejb, etc.) into a module, and it
exports (or reexports from other modules) all the things you need; other
developers who want to use the feature would simply import that module
by name. In fact, this is how we intend to use the module system to
modularize various components in the SE platform.
It certainly is possible to use the import-by-name approach to imitate
some sort of import-by-feature approach, but this assumes that you are
always able to create modules that have a one-to-one correspondence with
some higher level "feature" concept. While this may work in some cases,
e.g., replaceable modules implementing standard XML parsers, it is not
likely to be possible in all cases -- the fact that it is the only
mechanism available virtually guarantees that a majority of modules will
not meet this criterion.
Ultimately, this approach still falls short for the following reasons:
* No matter how you describe it, the import-by-name approach ==
import-by-module, since name == module name in 277. Thus, you are
still saying who gives you what you want, rather than what you want.
* As a byproduct of the above, you are still defining dependencies
too broadly, since import-by-name says that you need everything
from this named module, even though you might only need some very
small subset, which will lead to dependency fanout.
Further, I would say that it is more wishful thinking rather than actual
reality to believe that a higher level concept even helps here, since in
the end for Java it always comes down to importing packages and using
them in your source code. The higher level concept does not exist in
source code nor does the programmer know anything about it; the
programmer does, however, know about packages and the associated API
since this is required to use anything in Java.
The real value of this sort of higher level concept is further
diminished when you introduce tooling support that can pull these sorts
of dependencies from the byte code and automatically generate dependency
metadata, such as BND does for OSGi bundles.
People may like the "import-by-name" approach when they are developing
and need to create a class path for their IDE, but in reality there is
no reason why they should have to do this for their IDE either. Assuming
that a module repository exists, if I start using classes from
Hibernate, for example, there is no reason why my IDE cannot see that
this package is not in my class path and offer to fix it by searching
the module repo for providers of the Hibernate package, similar to how
IDEs currently fix imports in the source code...in this case it could
even allow you to select from multiple versions. Then the issue of "ease
of use" goes away completely.
So, in short, call it what you want, but the solution offered by 277 is
import-by-module with all of the associated shortcomings.
-> richard
