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
[snip]
Richard S.Hall wrote:
My question below still stands. In general, it seems to me that
resolution consists of:
1. Selection of candidate module/bundles based on import declarations.
2. Class space consistency validation (which may narrow the list if
multiple choices, or result in a
Hi Bryan,
Bryan Atsatt wrote:
...
Rather than surfacing the import-by-package at the API level, I think we
can solve #3 by generalizing the import dependency concept as
import-by-name, and this name can be mapped to superpackage-name in JSR
277 and OSGi-bundle-name or OSGi-exported-package-name
Bryan Atsatt [EMAIL PROTECTED] wrote on 30/05/2007 19:11:02:
Responses inline, and a few clarifications here (I was a bit tired when
I finished this last night :^)...
The main point I was trying to make is that resolution must occur within
a specific context, but I don't think my example
Bryan Atsatt wrote:
Stanley M. Ho wrote:
Glyn Normington wrote:
*Bryan Atsatt [EMAIL PROTECTED]* wrote on 30/05/2007 07:57:59:
...
So the open issue is the richness of the import language: must we
support only lowest-common-denominator, or can we do better without
over-complicating the
On May 31, 2007, at 8:06 PM, Stanley M. Ho wrote:
Hi Richard,
Richard S.Hall wrote:
I don't think I fully understand your concerns around exporting an
entire package. As you mentioned, what's get exported in 277 module
is
in terms of classes and the information is in the module metadata,
and
Adrian [EMAIL PROTECTED] wrote on 25/05/2007 12:44:54:
On Thu, 2007-05-24 at 11:00 +0100, Glyn Normington wrote:
A better approach would be for the Java 7 platform to provide first
class support for JSR 291. This boils down to standardising the
experimental class loader deadlock fix ([1])
Responses inline, and a few clarifications here (I was a bit tired when
I finished this last night :^)...
The main point I was trying to make is that resolution must occur within
a specific context, but I don't think my example APIs showed that well.
I was assuming that ImportResolver had a
Hi,
Glyn Normington wrote:
*Bryan Atsatt [EMAIL PROTECTED]* wrote on 30/05/2007 07:57:59:
...
So the open issue is the richness of the import language: must we
support only lowest-common-denominator, or can we do better without
over-complicating the design?
I for one would like to be
