Relationship to JSR 291 [was: Re: Bryan's comments]

[Sam Pullara]

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.