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.
