My aghast reaction to Andy's mail is that if we aren't solving this
simple issue, what is it that we are solving? This use case is far
more like what I would want in the real world. If we don't get
something out of this JSR and the language JSR that approximates a
runtime version of 'gem' (from the ruby camp) we might as well open
up the next JSR for really solving the problems that we have. People
want to import functionality, not packages, e.g. import ejb3, not
org.hibernate.*, javax.ejb.*, etc.
Sam
On Jun 8, 2007, at 1:53 AM, Andy Piper wrote:
At 00:53 08/06/2007, Bryan Atsatt wrote:
I truly believe that the Java world will be far better served by
having
277 support ONLY import-by-package!
But there has been this background fear that import-by-package is
somehow terribly complex. I can certainly believe that the union
of all
the OSGi features *does* result in a lot of complexity.
Just to express a usage datapoint here. Having used OSGi for a while
now I am finding import-by-package too hard to use in certain
circumstances (but in general it is a nice flexible model), but its
not an issue that import-by-name really fixes in my opinion.
The basic issue is that to use something I am interested in the union
of packages that make up the "feature". I actually don't care about
the individual packages. Take my current bugbear, cglib in Spring for
example, to use this "feature" the *proxied* class bundle needs to
import the following packages:
net.sf.cglib.proxy,
net.sf.cglib.core,
net.sf.cglib.reflect,
org.aopalliance.aop,
org.springframework.aop.framework,
org.springframework.aop,
not an obvious set, nor a set of packages that I care much about.
Worse, the proxied class does not know ahead of time that it needs to
import these packages (this is I believe because cglib tries to
create the proxy in the classloader of the proxied class by default).
Ideally to solve this I would like two things:
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.
2. Some way of augmenting a module *after* the fact with a particular
set of packages, so that the module doesn't need to do dynamic-import
* everywhere.
I don't think either if these is possible in OSGi right now (I would
be happy to be corrected!). I don't think JSR 277 solves these either
(but again I would be happy to be corrected).
Just a datapoint from real-world usage.
andy
Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries
and affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely for
the use of the individual or entity named in this message. If you
are not the intended recipient, and have received this message in
error, please immediately return this by email and then delete it.
