Fw: JSR 291 interoperation status
Hi Stanley Please could you provide an update on your work on interoperation between JSR 277 and JSR 291? If the work is still in progress, how's it coming along and roughly when might there be a strawman proposal to review? Thanks, Glyn - Forwarded by [EMAIL PROTECTED] on 06/09/07 04:12 PM - [EMAIL PROTECTED] wrote on 21/06/2007 09:59:02 AM: > > Hi Stanley > > Thanks for the status. Please could you indicate roughly when the > strawman will be ready for initial review by this EG? Hopefully > early feedback from the Expert Group would be a help... > > Glyn > > "Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 20/06/2007 11:43:14 PM: > > > Hi Glyn, > > > > That strawman is in progress. As you mentioned, it has significant > > challenges, so it takes more time to produce compared to other > > strawmans. Please stay tuned. ;-) > > > > - Stanley > > > > > > Glyn Normington wrote: > > > Please could you give us an update on your work on interoperation with > > > JSR 291 and some idea of when a strawman is likely to be available for > > > initial review by the JSR 277 Expert Group? > > > > > > Like I said when we spoke at JavaOne, the approach you are planning on > > > taking *might* work, but it has significant challenges, so I'd like to > > > hear how it's coming along. > > > > > > Thanks, > > > > > > Glyn > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Module system notification mechanism
Hi Stanley You wrote on 17/07/2007 02:08:39 AM: > Do you have examples that using custom import > policy is not sufficient for performing initialization? Take the common example where a custom import policy is being avoided because of its disadvantages ([1]), but a module initialiser is still needed. Glyn [1] http://underlap.blogspot.com/2007/06/representations-of-module-dependencies.html Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Module system notification mechanism
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 25/06/2007 06:00:12 PM: > It seems simple enough to put the module in a failed state if a > module-init event handler throws an exception. Is this not sufficient? No, I don't think so. What state would a module be in when its module-init event is published? If potential consumers of the module listen for the event, then they'll be interested in the module being initialised (ideally meaning its activator has already completed successfully) and ready for use. But the module can't be in the initalised state if it might transition to a failed state if one of the event handlers calls the module's activator and that fails. Also, why should the failure of a 3rd party listener put the module in a failed state? One buggy or malicious module could impact the whole system. > > The lazy init feature sounds like a nice optimization, but doesn't > strike me as a must-have. Have you seen use-cases that require it? Are > they init order issues? I agree it's not a must have as JSR 291 handles that. > > > (I am sensitive to your meta point here, but... If 277 is going to > exist, there are some rather obvious, desirable features which it will > need, just as OSGi needed them. I _don't_ like the fact that we are > re-inventing rather than re-using OSGi, but that is how it has played > out, despite all protestations. As long as we can still attain the goal > of meaningful interoperation, it seems irresponsible to leave out > features like this. And yes, we must nail down the interoperation model > before we go much/any farther.) We *have* to find some way of JSR 277 being able to 'delegate' some responsibilities to JSR 291 rather than having to reproduce the whole shooting match which would literally take years (to produce something as good). I'd like to see JSR 277 providing some kind of basic support -- at least the repository -- with JSR 291 providing the bells and whistles. Glyn > > Glyn Normington wrote: > > > > Yes, but my point was that separating lifecycle out in that way would > > make it harder to enforce constraints like "if a module's state is > > initialised, the module's activator completed successfully". > > > > JSR 291 solved this problem with additional module states and error > > handling. It also supports lazy module initialisation triggered by the > > first class load from a module. How much of this should JSR 277 re-invent? > > > > Glyn > > > > *Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 22/06/2007 06:12:48 PM: > > > > > I think that is part of Stanley's point here: the module system isn't > > > responsible, as it merely generates the events. Some *other* system > > > could then take on lifecycle based on these events. > > > > > > Glyn Normington wrote: > > > > > > > > Hmmm. I thought so too (apart from reinventing the OSGi lifecycle > > event, > > > > of course), but I wonder if the module system needs to be directly > > > > responsible for driving an activator in case it fails to terminate (in > > > > which case the module needs to enter some kind of error or inactive > > state)? > > > > > > > > Glyn > > > > > > > > *"Richard S. Hall" <[EMAIL PROTECTED]>* wrote on 22/06/2007 > > 01:21:48 PM: > > > > > > > > > I think your suggestion is reasonable. > > > > > > > > > > -> richard > > > > > > > > > > Stanley M. Ho wrote: > > > > > > Hi JSR 277 experts, > > > > > > > > > > > > Since we have been discussing some issues around the module > > instances' > > > > > > lifetime lately, I think it's probably a good time to bring up a > > > > related > > > > > > topic for discussion. > > > > > > > > > > > > As I reviewed the feedbacks from the EDR comments, from our > > previous > > > > > > discussions, as well as from my discussions with the teams in SE > > > > and EE, > > > > > > there were a few suggestions related to the module > > instances'lifetime: > > > > > > > > > > > > 1. The module system shall provide a way to monitor various > > events, > > > > e.g. > > > > > > module initialized, module released, etc. > > > > > > 2. The module system shall allow a module to have activator > > code. Th
Re: Module system notification mechanism
Hi Stanley "Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 25/06/2007 10:04:08 PM: > Hi Glyn, > > Glyn Normington wrote: > > > > Yes, but my point was that separating lifecycle out in that way would > > make it harder to enforce constraints like "if a module's state is > > initialised, the module's activator completed successfully". > > The mechanism I suggested is simply for informing the application that > something has happened. This is a notification only and does not change > the state of the module system in any way. That's what I expected. > > If we want to enforce constraints like you mentioned, one approach is to > execute the activator code in the custom import policy. If this is not > sufficient, then we'll probably need a different mechanism to handle > this use case. I don't think calling the activator from the custom import policy would work. The main problem is that it would require any module needing an activator to supply a custom import policy, which we want to avoid in most cases. Also, the custom import policy runs in a peculiar 'half-resolved' state (the module is unresolved at the start and hopefully fully resolved at the end, so on average, it's half-resolved ;-) ) and we wouldn't want application code proper, such as an activator, to have to support this state. > > - Stanley Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Module system notification mechanism
Yes, but my point was that separating lifecycle out in that way would make it harder to enforce constraints like "if a module's state is initialised, the module's activator completed successfully". JSR 291 solved this problem with additional module states and error handling. It also supports lazy module initialisation triggered by the first class load from a module. How much of this should JSR 277 re-invent? Glyn Bryan Atsatt <[EMAIL PROTECTED]> wrote on 22/06/2007 06:12:48 PM: > I think that is part of Stanley's point here: the module system isn't > responsible, as it merely generates the events. Some *other* system > could then take on lifecycle based on these events. > > Glyn Normington wrote: > > > > Hmmm. I thought so too (apart from reinventing the OSGi lifecycle event, > > of course), but I wonder if the module system needs to be directly > > responsible for driving an activator in case it fails to terminate (in > > which case the module needs to enter some kind of error or inactive state)? > > > > Glyn > > > > *"Richard S. Hall" <[EMAIL PROTECTED]>* wrote on 22/06/2007 01:21:48 PM: > > > > > I think your suggestion is reasonable. > > > > > > -> richard > > > > > > Stanley M. Ho wrote: > > > > Hi JSR 277 experts, > > > > > > > > Since we have been discussing some issues around the module instances' > > > > lifetime lately, I think it's probably a good time to bring up a > > related > > > > topic for discussion. > > > > > > > > As I reviewed the feedbacks from the EDR comments, from our previous > > > > discussions, as well as from my discussions with the teams in SE > > and EE, > > > > there were a few suggestions related to the module instances'lifetime: > > > > > > > > 1. The module system shall provide a way to monitor various events, > > e.g. > > > > module initialized, module released, etc. > > > > 2. The module system shall allow a module to have activator code. The > > > > activator code would be executed right before the module is fully > > > > initialized and when the instance is released. > > > > 3. A module shall have a way to be stopped. > > > > > > > > Having these suggestions don't mean we have to do all of them, and I > > > > would like to get your inputs. > > > > > > > > > > > > From my perspective, having a way to monitor module system's events > > > > (i.e. #1) seems very reasonable and useful, especially the use > > cases are > > > > very common. In fact, many teams in SE have expressed the needs in > > > > monitoring the module system's events in their class libraries in some > > > > degrees, so these libraries would react and behave appropriately. There > > > > are also other class libraries sitting on top of the JRE that have > > > > similar needs. > > > > > > > > For #2, this is a use case I gathered from EE, and this would be used > > > > mainly for registering and unregistering services when a module has > > been > > > > initialized or is released. Not that I think this is unimportant, but I > > > > am not yet convinced this is something we need to support directly at > > > > the module system level. For instance, if the module system > > notification > > > > mechanism (i.e. #1) is available, it should be possible for the EE > > > > server (or other apps that require similar functionality) to build a > > > > simple activator layer on top of the module system. > > > > > > > > For #3, the use case is that some EE servers might want to have the > > > > ability to "stop" a module by disabling the module's classloader when > > > > the module instance is released. In general, disabling a classloader is > > > > an uncommon and dangerous operation to perform, and it also > > violates the > > > > current classloading spec. While I agreed we should make this use case > > > > possible, I don't think this is something we want to push into the > > > > module system.; I believe there are alternatives we could consider to > > > > achieve the same result. For example, suppose there are APIs available > > > > to disable a classloader (might come from the classloading project) and > > > > the module system n
Re: Module system notification mechanism
Hmmm. I thought so too (apart from reinventing the OSGi lifecycle event, of course), but I wonder if the module system needs to be directly responsible for driving an activator in case it fails to terminate (in which case the module needs to enter some kind of error or inactive state)? Glyn "Richard S. Hall" <[EMAIL PROTECTED]> wrote on 22/06/2007 01:21:48 PM: > I think your suggestion is reasonable. > > -> richard > > Stanley M. Ho wrote: > > Hi JSR 277 experts, > > > > Since we have been discussing some issues around the module instances' > > lifetime lately, I think it's probably a good time to bring up a related > > topic for discussion. > > > > As I reviewed the feedbacks from the EDR comments, from our previous > > discussions, as well as from my discussions with the teams in SE and EE, > > there were a few suggestions related to the module instances' lifetime: > > > > 1. The module system shall provide a way to monitor various events, e.g. > > module initialized, module released, etc. > > 2. The module system shall allow a module to have activator code. The > > activator code would be executed right before the module is fully > > initialized and when the instance is released. > > 3. A module shall have a way to be stopped. > > > > Having these suggestions don't mean we have to do all of them, and I > > would like to get your inputs. > > > > > > From my perspective, having a way to monitor module system's events > > (i.e. #1) seems very reasonable and useful, especially the use cases are > > very common. In fact, many teams in SE have expressed the needs in > > monitoring the module system's events in their class libraries in some > > degrees, so these libraries would react and behave appropriately. There > > are also other class libraries sitting on top of the JRE that have > > similar needs. > > > > For #2, this is a use case I gathered from EE, and this would be used > > mainly for registering and unregistering services when a module has been > > initialized or is released. Not that I think this is unimportant, but I > > am not yet convinced this is something we need to support directly at > > the module system level. For instance, if the module system notification > > mechanism (i.e. #1) is available, it should be possible for the EE > > server (or other apps that require similar functionality) to build a > > simple activator layer on top of the module system. > > > > For #3, the use case is that some EE servers might want to have the > > ability to "stop" a module by disabling the module's classloader when > > the module instance is released. In general, disabling a classloader is > > an uncommon and dangerous operation to perform, and it also violates the > > current classloading spec. While I agreed we should make this use case > > possible, I don't think this is something we want to push into the > > module system.; I believe there are alternatives we could consider to > > achieve the same result. For example, suppose there are APIs available > > to disable a classloader (might come from the classloading project) and > > the module system notification mechanism (i.e. #1) is available, it > > should be possible for the EE servers to hook into the notification > > mechanism, and disable the specific classloader it wants when a module > > instance is released from the module system. > > > > > > To keep things simple, I suggest we should support #1, and I hope this > > should be sufficient to enable other applications (e.g. EE servers) to > > support #2 and #3. I would like to hear what your thoughts are. > > > > - Stanley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: JSR 291 interoperation status
Hi Stanley Thanks for the status. Please could you indicate roughly when the strawman will be ready for initial review by this EG? Hopefully early feedback from the Expert Group would be a help... Glyn "Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 20/06/2007 11:43:14 PM: > Hi Glyn, > > That strawman is in progress. As you mentioned, it has significant > challenges, so it takes more time to produce compared to other > strawmans. Please stay tuned. ;-) > > - Stanley > > > Glyn Normington wrote: > > Please could you give us an update on your work on interoperation with > > JSR 291 and some idea of when a strawman is likely to be available for > > initial review by the JSR 277 Expert Group? > > > > Like I said when we spoke at JavaOne, the approach you are planning on > > taking *might* work, but it has significant challenges, so I'd like to > > hear how it's coming along. > > > > Thanks, > > > > Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
JSR 291 interoperation status
Hi Stanley Please could you give us an update on your work on interoperation with JSR 291 and some idea of when a strawman is likely to be available for initial review by the JSR 277 Expert Group? Like I said when we spoke at JavaOne, the approach you are planning on taking *might* work, but it has significant challenges, so I'd like to hear how it's coming along. Thanks, Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Strawman: Services and service-providers support
Hi Stanley "Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 14/06/2007 05:53:58 PM: > Hi Glyn, > > The existing service/service-provider model has been used in various SE > components for loading available providers from JARs in the installed > optional packages and classpath. Since JSR 277 will define a set of > repositories that allow multiple versions of modules to coexist and > these modules may define services and/or service-providers, what the > strawman describes is basically how JSR 277 will fit into this existing > service/service-provider model and provide support for it. > > While I agreed with you that enhancing the existing > service/service-provider model is desirable (like #1 and #2 you pointed > out), it is outside the scope of JSR 277 (i.e. JSR 277 is not chartered > to change the service/service-provider model.) Therefore, I suggest we > should focus our discussion on issues around how to support the existing > service/service-provider model. Fine. > > #3 you mentioned is somewhat related to another topic I would like to > bring up, and I will start the discussion in another thread. For #4, it > is unclear to me what the issues are, could you elaborate? Maybe it's just a matter of presentation in the strawman, but it confused me somewhat and the net effect was that I wasn't sure what pieces JSR 277 will be providing and what pieces are upgrades of existing facilities (since I'm not familiar with the existing service/service-provider model) to take advantage of JSR 277. 1. The opening paragraph of the Background section defines a service as "a well-known set of interfaces and (usually abstract) classes" - no mention of instances, 2. The third paragraph of the same section say "a service is represented by a single type ...". Again no mention of instances. 3. The requirements section talks about the module system making services available to the Java platform. This is using 'service' in the above sense, but I'm not sure what it means to make an interface "available to the Java platform" unless it means "available for modules to import". 4. Section 6 talks about an application module importing a service module if and only if there is at least one suitable service provider. I guess the rationale is to make the application module fail to resolve if it hasn't a (current) hope of obtaining the service it needs. But from my perspective this is odd. The service provider could be available without it being possible to obtain a service instance, which is the thing the application really needs. So rather than being an import-time check, the availability of critical services should be checked when the application module starts (for static applications that don't need to react dynamically to services coming online, that is). Glyn > > Thanks, > - Stanley > > > Glyn Normington wrote: > > > > I am very concerned that the scope of JSR 277 is being expanded > > considerably without much attention being paid to the state of the art > > (particularly Spring-OSGi and Declarative Services). If we could > > implement good interoperation with JSR 291, we could delegate the > > complexities of supporting services to JSR 291 and technologies like > > Spring-OSGi that layer nicely on top of JSR 291. > > > > Apart from that, the support for services in the strawman has some > > obvious holes, so I don't think it is ready to be incorporated into the > > JSR 277 specification: > > > > 1. It seems to be lacking any form of dependency injection. > > > > 2. The namespace of services is global, but not partitioned by service > > interface version. The effect of this is that a module could import v1 > > of a service interface class and obtain an instance of the service that > > implements v2 of the service interface and get a class cast exception. > > > > 3. There is no support for dynamic updates of service providers and > > notification of service updates to service consumers. (This is > > consistent with JSR 277's static nature, but I point it out as this is > > an obvious future requirement based on our experience in OSGi.) > > > > 4. There seems to be some confusion in the strawman between loading of > > service interfaces/implementations and construction and publication of > > service instances. > > > > I wonder what other Expert Group members think of this strawman. Silence > > does not necessarily indicate happiness, so it would be good to have > > more feedback. > > > > Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Strawman: Services and service-providers support
http://jcp.org/en/eg/download/jsr-277-service-provider-strawman-05222007.pdf?id=277&fileId=3438 Glyn Andy Piper <[EMAIL PROTECTED]> wrote on 14/06/2007 12:43:45 PM: > I share Glyn's concerns, but can someone remind me where the strawman is?! > > Thanks! > > andy > > At 11:07 AM 6/14/2007, Glyn Normington wrote: > > >"Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 13/06/2007 07:19:10 PM: > > > > > Since I have not heard any further input on the services and > > > service-providers strawman, I suppose the EG is fine with the strawman > > > overall except the issue raised by Richard. Unless I hear any objection, > > > I will incorporate the appropriate portion of the strawman based on the > > > feedback you have provided into the next revision of the specification. > > > >I am very concerned that the scope of JSR 277 is being expanded > >considerably without much attention being paid to the state of the > >art (particularly Spring-OSGi and Declarative Services). If we could > >implement good interoperation with JSR 291, we could delegate the > >complexities of supporting services to JSR 291 and technologies like > >Spring-OSGi that layer nicely on top of JSR 291. > > > >Apart from that, the support for services in the strawman has some > >obvious holes, so I don't think it is ready to be incorporated into > >the JSR 277 specification: > > > >1. It seems to be lacking any form of dependency injection. > > > >2. The namespace of services is global, but not partitioned by > >service interface version. The effect of this is that a module could > >import v1 of a service interface class and obtain an instance of the > >service that implements v2 of the service interface and get a class > >cast exception. > > > >3. There is no support for dynamic updates of service providers and > >notification of service updates to service consumers. (This is > >consistent with JSR 277's static nature, but I point it out as this > >is an obvious future requirement based on our experience in OSGi.) > > > >4. There seems to be some confusion in the strawman between loading > >of service interfaces/implementations and construction and > >publication of service instances. > > > >I wonder what other Expert Group members think of this strawman. > >Silence does not necessarily indicate happiness, so it would be good > >to have more feedback. > > > >Glyn > > > > > > > >-- > > > > > >Unless stated otherwise above: > >IBM United Kingdom Limited - Registered in England and Wales with > >number 741598. > >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > > > > > > > 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Strawman: Services and service-providers support
"Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 13/06/2007 07:19:10 PM: > Since I have not heard any further input on the services and > service-providers strawman, I suppose the EG is fine with the strawman > overall except the issue raised by Richard. Unless I hear any objection, > I will incorporate the appropriate portion of the strawman based on the > feedback you have provided into the next revision of the specification. I am very concerned that the scope of JSR 277 is being expanded considerably without much attention being paid to the state of the art (particularly Spring-OSGi and Declarative Services). If we could implement good interoperation with JSR 291, we could delegate the complexities of supporting services to JSR 291 and technologies like Spring-OSGi that layer nicely on top of JSR 291. Apart from that, the support for services in the strawman has some obvious holes, so I don't think it is ready to be incorporated into the JSR 277 specification: 1. It seems to be lacking any form of dependency injection. 2. The namespace of services is global, but not partitioned by service interface version. The effect of this is that a module could import v1 of a service interface class and obtain an instance of the service that implements v2 of the service interface and get a class cast exception. 3. There is no support for dynamic updates of service providers and notification of service updates to service consumers. (This is consistent with JSR 277's static nature, but I point it out as this is an obvious future requirement based on our experience in OSGi.) 4. There seems to be some confusion in the strawman between loading of service interfaces/implementations and construction and publication of service instances. I wonder what other Expert Group members think of this strawman. Silence does not necessarily indicate happiness, so it would be good to have more feedback. Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: JSR 277 EG observer mailing list
Hi Stanley Any chance of updating the public part of the JSR 277 page? Don't forget your blog links to it the observer list, as does mine now. ;-) Glyn "Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 06/06/2007 10:51:26 PM: > Hi Bryan, > > Bryan Atsatt wrote: > > How are people supposed to find this? Shouldn't there be an easily > > spotted link somewhere on the public 277 page? > > Yes, it is mentioned in the JSR 277 community update page: > > http://jcp.org/en/egc/view?id=277 > > but unfortunately it requires JCP member login. > > It is also mentioned in the OpenJDK project which will cover the > reference implementation (RI) of JSR 277 and JSR 294, and hopefully > people will be able to find it: > > http://openjdk.java.net/projects/modules > > - Stanley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 04/06/2007 20:21:29: > Stanley M. Ho wrote: > > Hi Bryan, > > > > I don't think I will have time to response to all your comments this > > week, so my response would focus on the import-by-package discussion. > > > > First, the only import dependency we have consensus in this EG so far is > > import-by-module-name (or import-by-superpackage-name), and this was > > also what's in the EDR. That said, it is by no mean that we can't > > consider other import dependency granularities (e.g. > > import-by-package-name, or import-by-contract) in addition to > > import-by-module-name. I would like to focus this discussion more on > > whether it makes sense for JSR 277 to support additional import > > dependency granularity, mainly import-by-package-name, and if so, in > > what context. > > > > There are three cases we should consider: > > > > 1. 277 module imports another 277 module by package name > > > > I think our consensus so far is that this is nice-to-have or > > non-critical, given we already have support for import-by-module-name. > > To keep this discussion in focus, let's not dive into > > import-by-package-name v.s. import-by-module-name, and let's assume > > there is no support for #1 for now. > > Agreed. > > > > > 2. OSGi module imports 277 module by package name > > > > As I discussed this with Richard in previous emails, majority of the > > works for this fall under the OSGi framework if it wants to enable this > > kind of wiring, but we could probably make the implementor's life easier > > by provide the appropriate 277 reflective API if necessary. > > Yes, the API would be useful. > > > > > 3. 277 module imports OSGi module by package name > > > > If I understand you correctly, I think what you really want is the > > support for this case, so the existing OSGi bundles can be leveraged by > > 277 modules in a nature way. > > > > Let me say it up front that I don't oppose the idea of #3 in the context > > of interoperability. If #3 is what you really want, I think where we > > diverge is simply how to make it possible. > > > > Do you agree so far? > > Yes. > > > > > Bryan Atsatt wrote: > >> ... > >> I want 277 to explicitly expose the concept of import-by-package through > >> appropriate APIs. > >> > >> It would be very nice if the 277ModuleSystem implementation itself > >> directly supports import-by-package (case #3). But this is less critical > >> to me than case #4... > >> > >> I want a 277ModuleDefinition to be able to import-by-package an > >> OSGiModuleDefinition (i.e. a bundle exposed via the 277 APIs). I believe > >> this case will be a particularly important one. By the time SE 7 ships, > > ... > > > > As I described several emails back: > > > > > This doesn't mean supporting the notion of import by package is > > > impossible. What OSGi will expose from its repository is simply module > > > definitions, and module definition is basically an abstraction. > > > Therefore, it should be possible to treat an OSGi bundle as a module > > > definition, as well as to treat each exported package in an OSGi > > > bundle a module definition as well. The dependency supported in JSR > > > 277 is import-by-module. In the JSR 277 module system, this is mapped > > > to import-by-superpackage. In the OSGi module system, this can be > > > mapped to import-by-OSGi-bundle or import-by-package. If other module > > > systems want to support different import granularity or if OSGi > > > evolves to add new import granularity in the future, this model should > > > still work. > > > > 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 in OSGi (i.e. > > exposing OSGi bundles and exported packages through implementing > > OSGiBundleModuleDefinition and OSGiPackageModuleDefinition). I think > > this is also what you intended to say at one point (correct me if I > > misunderstand you) by suggesting to change > > ImportDependency.getModuleName() into something like > > ImportDependency.getName(). > > I believe we are now thinking along the same lines. > > I just sent an email on the topic of generalizing the import dependency > concept, with the subject "Import constraints". With the approach I > suggest there, the distinctions between module-name and package-name are > mostly transparent to the runtime (declarative support for package-name > is not addressed). > > That isn't to say that there aren't resolution issues to be worked out > for package-name, but its a start. > > > > > We expect the module-aware compiler would somehow recognize the import > > dependency defined in 277. In other words, if the OSGi framework exposes > > the module definitions appropriately, you'll get the compiler support. > > Since the import dependency is generic, the
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
After writing:
>I think ResolutionContext doesn't need any detail
I remembered the class in the interoperation kernel prototype did have a
little detail (but not much):
public interface ResolutionContext extends KernelRelated {
/**
* Notify completion.
*/
void complete();
}
I blogged ([1]) the README and class diagrams from the prototype for ease
of reference.
Glyn
[1]
http://underlap.blogspot.com/2007/06/module-system-interoperation-kernel.html
[EMAIL PROTECTED] wrote on 31/05/2007 17:15:19:
>
> 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 APIs showed that
well.
> > I was assuming that ImportResolver had a ModuleContext as a field, but
> > we can make this much cleaner and easier to understand by passing it
as
> > an argument:
> >
> > public abstract class ImportResolver {
> > public abstract Module resolve(ModuleDefinition def,
> > ModuleContext ctx);
> > }
> >
> > And we can really tie this together by adding a convenience method to
> > ModuleContext:
> >
> > public abstract class ModuleContext {
> > ...
> > public Module resolve(ModuleDefinition def) {
> > return getImportResolver().resolve(def, this);
> > }
> > }
> >
> > Now resolution becomes simply:
> >
> > context.resolve(definition);
> >
> >
> > (I also left out any use of the ImportPolicy, as it isn't yet clear to
> > me that it should remain a separate type in this model.)
> >
> > // Bryan
> >
> > Glyn Normington wrote:
> > >
> > > *Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007
07:57:59:
> > >
> > > > Andy Piper wrote:
> > > > > At 23:19 25/05/2007, Stanley M. Ho wrote:
> > > > >> Anyway, it seems the EG consensus so far is to not add
> import package
> > > > >> support. If any EG member disagrees, please speak up.
> > > > >
> > > > > Well, it depends on what the solution for enabling
interoperation
> > > > > with JSR 291 is.
> > > > > Our requirement is that there must be a solution, if that
requires
> > > > > import package, so be it. If not then not.
> > > >
> > > > Exactly.
> > > >
> > > > I think we can all agree that, at minimum, interoperation means
that
> > > > classes and resources are sharable *across* ModuleSystems at
runtime.
> > > >
> > > > Which implies that *import dependencies must be resolvable across
> > > > multiple ModuleSystem instances*. (BTW, I think we should change
the
> > > > state name "PREPARING" to "RESOLVING" in 7.2.1.)
> > >
> > > Agreed. We must avoid the trap of thinking that module system
interop.
> > > can be achieved by exposing class loaders (as loadClass will happily
> > > load unexported classes).
> > >
> > > >
> > > > 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 able to have a single module express
> > > > dependencies on modules from both the same and different
ModuleSystems,
> > > > *using the standard semantics of each*. This may be reaching too
far,
> > > > but we should at least explore it seriously while we figure out
what
> > > > interop means here...
> > >
> > > At this point, I feel that is likely to be reaching too far, but I'm
> > > happy to play along and see what we can learn along the way.
> > >
> > > >
> > > >
> > > > BASICS
> > > >
> > > > So far, we only know of two different import semantics:
> module-name, and
> > > > package-name. For discussion, let's call these:
> > > >
> > > > a. import-module
> > > > b. import-package
> > > >
> > > > So, to start, we could:
> > > >
> > > > 1. Support declaration of both import types. If 294 supports
imports at
> > > > all, it should b
Re: Module isolation
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 31/05/2007 23:52:08:
> I'd like to continue this discussion separately from the
> 291/import-by-package thread :^).
>
> To recap, the spec (sections 1.2, 6.1, 6.4) talks about using separate
> Repository instances as a means to provide isolation for environments
> like EE and Applets.
>
> I believe this is an oversight--actually, a holdover from the ideas I
> put forth in the prototype, where Repository cached Module instances.
>
> But in the current design, that is no longer the case. Repositories hold
> ModuleDefinitions, not Modules, so they are not a suitable isolation
> mechanism. It is *Module* instances with their associated loaders that
> may require isolation.
Yes, I think you're right.
>
> The current design also assumes that ModuleSystems cache Module
> instances. This certainly makes more sense than Repository. However, it
> means that systems that require isolation must arrange for separate
> ModuleSystem instances. This seems quite awkward, and a poor
abstraction.
>
> So I think we need to introduce an explicit notion of an isolation
> context that:
>
> 1. Acts as a cache for Module instances.
> 2. Enables multiple instances, each forming a separate Module namespace.
> 3. Provides out-of-the box instances for bootstrap and "system" modules.
> 4. Provides a delegation model to link instances.
> 5. Provides a lookup mechanism identical to that of Repository.
>
> Any given resolution would take place within a single context. That is,
> an initial context is selected, and while existing instances can be
> retrieved from delegated contexts, *new* instances must be created in
> the initial context.
This seems like a module analogue of a class loader except that new module
instances are created in the initial context, which seems a bit peculiar.
Wouldn't this mean that Java platform module instances could get created
in an application context?
>
> To enforce this model, and to simplify the api, I believe the context
> should directly expose a "resolve" convenience method (which simply
> delegates the actual implementation).
>
> Here is a strawman API, with a simple parent-first delegation model:
>
> public abstract class ModuleContext {
>
> // Get the context used to resolve JRE modules.
> public static ModuleContext getBootstrapContext(){...};
>
> // Get the context used to resolve the main module.
> public static ModuleContext getSystemContext(){...};
>
> // Get all contexts.
> public static List getContexts() {...};
>
> // Add a new context.
> public static void addContext(ModuleContext ctx) {...}
>
> // Remove a context (error if == default).
> public static boolean removeContext(ModuleContext ctx) {...}
>
> // Get the parent context (null if bootstrap).
> public ModuleContext getParentContext(){...}
>
> // Get the name of this context.
> public String getContextName() {...}
>
> // Add a new Module instance to the cache. Throw an error
> // if an existing module contains the same definition.
> public abstract void addModule(Module module);
>
> // Find cached Module instances. Must check parent first.
> public abstract List findModules(Query query);
>
> // Remove a Module.
> public abstract boolean remove(Module module);
>
> // Remove all Modules created from the specified definition.
> public static void removeAll(ModuleDefinition def) {...}
>
> // Resolve a definition.
> public Module resolve(ModuleDefinition def) {
> ModuleSystem ms = def.getModuleSystem();
> return ms.resolve(def, this);
> }
Using module context as a resolution context seems to imply that
concurrent resolutions need to be serialised to avoid interference and so
some synchronisation needs adding. Or maybe the idea is to use a module
context instance per resolution, but that wouldn't fit with a module
context being a cache spanning multiple resolutions.
>
> // Set the context used for JRE modules.
> static void setBootstrapContext(ModuleContext ctx){...}
>
> // Set the context used to define the main module.
> static void setSystemContext(ModuleContext ctx){...}
> }
>
> The JVM would create an appropriate subtype and call
> setBootstrapContext(). JRE module instances would be cached here.
>
> The launcher would create a child context and call setSystemContext().
> The main module and any of its dependencies would be resolved here.
>
> An EE/Applet (or similar) environment can create/remove/use new contexts
> as needed for application isolation. Note that the these new contexts
> need not have the system context in their parent chain. But they do need
> the bootstrap context so the code should enforce that.
>
> The resolve() method here assumes that ModuleSystem.getModule() is
> replaced by:
>
> ModuleSystem {
> ...
> public abstract Module resolve(ModuleDefinition def,
>M
Re: Exported resources
Some feedback from an observer which may help:
> Bryan misses the need for extender model to load internal impl classes
ala
> Bundle.loadClass in OSGi.
>
> You do not want to have to export the service impl class from a module.
> You want to hide the class from others' casual loading. However an
> extender bundle (e.g. ServiceLoader) will need to be able to load that
> class to make it instances of it available to others under the service
> interface class.
Glyn
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 30/05/2007 21:21:36:
> I've been assuming that Module private resources should not be visible
> to *any* class outside of the module. Including ResourceBundle, or any
> other existing framework classes that do resource lookups (e.g.
> ServiceLoader, JSF, etc). If resources need to be visible to these
> existing classes, they must be exported. The very simple check I
> proposed (immediate caller) is sufficient to make this assertion.
>
> I believe your point is that if we used the permission model instead, it
> would become possible for a module to invoke an external class (e.g.
> ResourceBundle.getBundle()) and enable *it* to successfully load a
> private resource from the module.
>
> Aside from the permission *grant* mechanism this model would rely on, it
> is an entirely different model than that used for classes! (Though we
> haven't explicitly defined this in 294, it seems extremely unlikely that
> we will rely on permissions--none of the other access modes do so.) Such
> asymmetry is very disconcerting to me, and, I believe, just plain
wrong...
>
> Consider that you could grant the ServiceLoader, for example, access to
> a resource that names a class that it could not instantiate. That class
> would have to be exported. I believe the resource should be as well.
>
> // Bryan
>
>
>
>
> Stanley M. Ho wrote:
> > Hi Bryan,
> >
> > Those resource-related methods in ClassLoader can be called by anyone,
> > including code that is part of the module, code that is from other
> > modules, or code that is part of the platform libraries (e.g.
> > ResourceBundle). The approach you described would require walking the
> > stack to get the caller's Module, but the real issue is that it is
> > difficult to determine who the actual caller is from the stack.
> >
> > Treating the immediate caller on the stack as the actual caller
wouldn't
> > be sufficient because the immediate caller could be called by someone
> > else who is the one actually making the call. On the other hand,
> > treating the originated caller on the stack as the actual caller would
> > be the right semantic, but this is basically the same as the security
> > permission approach.
> >
> > - Stanley
> >
> >
> > Bryan Atsatt wrote:
> >> Both solutions require stack walking (unless there is some new
> >> implementation of the java security model I've not yet seen!).
> >>
> >> The permission check does much more work than is necessary here. Take
a
> >> look at AccessController.checkPermission() to see what I mean.
> >>
> >> And actually there is a very simple API to get the stack, which I've
> >> used for years:
> >>
> >> private static class StackAccessor extends SecurityManager {
> >> public Class[] getStack() {
> >> return getClassContext();
> >> }
> >> }
> >>
> >> private static final STACK_ACCESSOR = new StackAccessor();
> >>
> >> Now the enclosing class can simply call STACK_ACCESSOR.getStack().
> >>
> >> // Bryan
> >>
> >>
> >>
> >> Stanley M. Ho wrote:
> >>> Hi Bryan,
> >>>
> >>> Bryan Atsatt wrote:
> 1. Definitely agree that resource search order should be identical
to
> class search order.
> >>>
> >>> Glad to hear!
> >>>
> 2. Using permissions to limit access to private resources seems
like
> overkill to me. The prototype implemented this in a very simple
> fashion:
>
> a. If resource is exported, return it, else
> a. Get the caller's Module (get class from stack, get module from
it)
> b. If callerModule == this, return resource, else return null.
> >>>
> >>> The issue is that this approach still requires stack walking and
there
> >>> is no public API in the SE platform that let you implement this.
> >>>
> >>> If stack walking is required for the check anyway, I think the
security
> >>> permission approach is better that it is implementable with the
existing
> >>> API in the SE platform.
> >>>
> >>> - Stanley
> >>>
> >
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
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 APIs showed that well.
> I was assuming that ImportResolver had a ModuleContext as a field, but
> we can make this much cleaner and easier to understand by passing it as
> an argument:
>
> public abstract class ImportResolver {
> public abstract Module resolve(ModuleDefinition def,
> ModuleContext ctx);
> }
>
> And we can really tie this together by adding a convenience method to
> ModuleContext:
>
> public abstract class ModuleContext {
> ...
> public Module resolve(ModuleDefinition def) {
> return getImportResolver().resolve(def, this);
> }
> }
>
> Now resolution becomes simply:
>
> context.resolve(definition);
>
>
> (I also left out any use of the ImportPolicy, as it isn't yet clear to
> me that it should remain a separate type in this model.)
>
> // Bryan
>
> Glyn Normington wrote:
> >
> > *Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007 07:57:59:
> >
> > > Andy Piper wrote:
> > > > At 23:19 25/05/2007, Stanley M. Ho wrote:
> > > >> Anyway, it seems the EG consensus so far is to not add import
package
> > > >> support. If any EG member disagrees, please speak up.
> > > >
> > > > Well, it depends on what the solution for enabling
interoperation
> > > > with JSR 291 is.
> > > > Our requirement is that there must be a solution, if that
requires
> > > > import package, so be it. If not then not.
> > >
> > > Exactly.
> > >
> > > I think we can all agree that, at minimum, interoperation means
that
> > > classes and resources are sharable *across* ModuleSystems at
runtime.
> > >
> > > Which implies that *import dependencies must be resolvable across
> > > multiple ModuleSystem instances*. (BTW, I think we should change
the
> > > state name "PREPARING" to "RESOLVING" in 7.2.1.)
> >
> > Agreed. We must avoid the trap of thinking that module system interop.
> > can be achieved by exposing class loaders (as loadClass will happily
> > load unexported classes).
> >
> > >
> > > 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 able to have a single module express
> > > dependencies on modules from both the same and different
ModuleSystems,
> > > *using the standard semantics of each*. This may be reaching too
far,
> > > but we should at least explore it seriously while we figure out
what
> > > interop means here...
> >
> > At this point, I feel that is likely to be reaching too far, but I'm
> > happy to play along and see what we can learn along the way.
> >
> > >
> > >
> > > BASICS
> > >
> > > So far, we only know of two different import semantics:
module-name, and
> > > package-name. For discussion, let's call these:
> > >
> > > a. import-module
> > > b. import-package
> > >
> > > So, to start, we could:
> > >
> > > 1. Support declaration of both import types. If 294 supports
imports at
> > > all, it should be relatively easy to support both, since a
superpackage
> > > name is a module name, and it contains member package names.
(Compiler
> > > support is clearly the critical issue here, but it will obviously
> > > require use of the 277 runtime, so the import *type* should be
> > > transparent to it.) At worst, we'd need two new annotation types.
> >
> > A superpackage name is a deployment module name in the JSR 277 model
of
> > one superpackage per deployment module, but I don't see any reason why
a
> > JSR 291 deployment module should not contain more than one
superpackage.
> > So if 294 were to support import, then its import-module would really
be
> > a superpackage import rather than a development module import.
>
> If we end up with nested superpackages, might it make sense to model
> multiple superpackages by enclosing them in a single top-level one?
That is an option, but of course each
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 30/05/2007 07:57:59: > Andy Piper wrote: > > At 23:19 25/05/2007, Stanley M. Ho wrote: > >> Anyway, it seems the EG consensus so far is to not add import package > >> support. If any EG member disagrees, please speak up. > > > > Well, it depends on what the solution for enabling interoperation > > with JSR 291 is. > > Our requirement is that there must be a solution, if that requires > > import package, so be it. If not then not. > > Exactly. > > I think we can all agree that, at minimum, interoperation means that > classes and resources are sharable *across* ModuleSystems at runtime. > > Which implies that *import dependencies must be resolvable across > multiple ModuleSystem instances*. (BTW, I think we should change the > state name "PREPARING" to "RESOLVING" in 7.2.1.) Agreed. We must avoid the trap of thinking that module system interop. can be achieved by exposing class loaders (as loadClass will happily load unexported classes). > > 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 able to have a single module express > dependencies on modules from both the same and different ModuleSystems, > *using the standard semantics of each*. This may be reaching too far, > but we should at least explore it seriously while we figure out what > interop means here... At this point, I feel that is likely to be reaching too far, but I'm happy to play along and see what we can learn along the way. > > > BASICS > > So far, we only know of two different import semantics: module-name, and > package-name. For discussion, let's call these: > > a. import-module > b. import-package > > So, to start, we could: > > 1. Support declaration of both import types. If 294 supports imports at > all, it should be relatively easy to support both, since a superpackage > name is a module name, and it contains member package names. (Compiler > support is clearly the critical issue here, but it will obviously > require use of the 277 runtime, so the import *type* should be > transparent to it.) At worst, we'd need two new annotation types. A superpackage name is a deployment module name in the JSR 277 model of one superpackage per deployment module, but I don't see any reason why a JSR 291 deployment module should not contain more than one superpackage. So if 294 were to support import, then its import-module would really be a superpackage import rather than a development module import. > > 2. Provide API for both import types (e.g. ImportDependency has > getModuleName() and getPackageName() methods, one of which will return > null on a given instance). > > However, we know these are necessary but not sufficient. Leaving aside > the resolution issue for a moment, support for import-package also > suggests that we: > > 3. Enable a single module to declare different versions for each of its > member packages. > > 4. Enable efficient Repository lookup by package name. > > I think these are relatively easy (but *could* be considered optional). > > We also need: > > 5. Standard Query types for lookup by module and package name. > > > EXISTING DEPENDENCY RESOLUTION MODEL > > The more interesting issue is dependency resolution. But this hasn't > been discussed in any real detail, so lets do so before talking further > about import-package. To simplify this discussion, I'm ignoring > bundled/custom import policies for now... > > Resolution in the current spec is delegated to the associated > ModuleSystem instance (7.2.2 #8). While the details are not spelled out, > the expectation appears to be that > ModuleSystem.getModule(ModuleDefinition) must: > > - Select an initial repository. Call getRepository() on the input parameter. > > Then, for each ImportDependency of the definition: > > - Select a matching definition. Construct a Query from the > ImportDependency and use Repository.find() to lookup a matching > ModuleDefinition. > > - Get an instance. Use def.getModuleSystem().getModule(def). The > ModuleSystem is expected to return a cached instance if available, or > create/cache/return one if not. I think there also needs to be some 'resolution context' object which explicitly denotes a particular resolution so that each module system can keep track of the state of a resolution. This is required when two or more imports of a given module from another module system need to resolve to the same module instance. A resolution context may also be needed for back-tracking when a set of module instances created earlier in resolution turn out not to satisfy all the necessary constraints. > > > (TBD: The PlatformBinding must be taken into account somehow during > selection. ModuleDefinition must include an accessor for it, and either > Repository.find() should implicitly filter them, or the caller must > construct a Query which will do so. I thi
Re: ClassLoader Deadlock fix was: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
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]) > > Fixing the deadlock just moves the problem. > > You'll still get ClassCircularityErrors when competing threads > try to load classes using locks other than the classloader > synchronization or they don't synchronize on the loadClass() > or they release the lock during the classloading request > to let others have a go (again to avoid the deadlock). > > This is because of the way the dictionary class determines > whether a circular load is occuring. > > Although I haven't tried it with OpenJDK so maybe the > dictionary class contains some other fixes to workaround the > problem? > > The simple form of the problem: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4699981 > has been fixed in recent JDKs, but spurious CCEs > still exist in other cases. > e.g. the testAbstractFactoryConcurrent() here: > http://viewvc.jboss.org/cgi-bin/viewvc. > cgi/jbossas/projects/microcontainer/trunk/classloader/src/tests/org/jboss/test/classloader/delegate/test/DelegateUnitTestCase. > java?revision=62792&view=markup > will show CCEs in the log if you enable TRACE logging. > > 1445 TRACE [ClassLoaderManager] Run failed with exception > java.lang.ClassCircularityError: > org/jboss/test/classloader/delegate/support/b/TestFactoryImplementation > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) Some spurious CCEs were indeed fixed before the experimental deadlock fix was introduced, but there may be more to do to make this fix robust and complete. If you raise a sunbug for the above testcase, best to report it here so that class loader rearchitecture folks can take it into consideration for Java 7. Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
I haven't lost interest in this thread but I'm going on leave now returning on Wednesday, so please don't misinterpret my silence in the interim. :-) Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Relationship to JSR 291 [was: Re: Bryan's comments]
Bryan Atsatt <[EMAIL PROTECTED]> wrote on 23/05/2007 20:52:47: > Stanley M. Ho wrote: > >> I think we need to think hard about this issue. The OSGi model of import > >> by *package name* decouples the importer from any explicit binding to a > >> bundle/module name. Refactoring under that model is *much* cleaner, and > >> far more natural. As is the usage model. After all, Foo.java import > >> statements contain package/class names, *not* module names. Programmers > >> think in terms of classes and packages. > >> > >> Peter makes this point pretty strongly, and I have to say I agree > >> wholeheartedly: > >> > >> http://www.aqute.biz/Blog/2006-04-29 > > > > I agreed that in some situations it is much better to have dependency > > that is loosely coupled. You may want to check out the service-providers > > strawman that I just sent out, and it deals with the exact issue around > > API vs implementation. > > That's great, but sort of beside the point :^). > > I am specifically referring to the syntax and semantics of "import" > declarations. At the moment, 277 supports only the "Reguire Bundle" > style semantics defined by OSGi. This model is is inherently > tightly-coupled, and its use is greatly discouraged in the OSGi world. > It was not even present in the initial releases. > > I strongly believe that it would be a huge mistake for 277 to support > only this model. If we want to simplify things and support only one > model, then we should choose import by package name/version, *not* > import by module name/version. Of course "import package" is superior to "require bundle" in many situations, but I think it would be a vast waste of time for JSR 277 to play "catch-up" with JSR 291. 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]) and enabling JSR 291 to exploit JSR 277's repositories and JSR 294's superpackages. The features in JSR 277 which are already provided by JSR 291 could be ditched (!) or could be retained for users wanting a module system "out of the box" or for exploitation by the JRE itself as a properly architected sequel to the consumer JRE. But if we retain these features, it is essential we provide first-class interoperation with JSR 291 as we have discussed many times in the past but which still looks pretty challenging (see [2]). Glyn [1] http://underlap.blogspot.com/2006/11/experimental-fix-for-sunbug-4670071.html [2] http://underlap.blogspot.com/2007/05/designing-module-system-interoperation.html Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Query...
If Query is made Serializable, let's make sure it declares a serial version UID to enable serial compatibility of future versions. Glyn Bryan Atsatt <[EMAIL PROTECTED]> wrote on 23/05/2007 19:14:41: > When I designed the Query/Repository model in the prototype, I had it > firmly in my mind that Query should be Serializable, so that it could be > sent over the wire to a remote repository. I've described it this way to > a number of people. But apparently I forgot to actually declare it. :^) > > And we haven't done so in the spec, either. I think we should. > > // Bryan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Strawman: Services and service-providers support
Hi Stanley "Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 23/05/2007 18:30:03: > Hi Glyn, > > This strawman was developed based on the updated JSR 277 specification > which has undergone significant changes since the EDR, so ideally the > updated specification is required in order for the readers to have the > proper context to fully understand the strawman; otherwise, this could > lead to misunderstanding or confusion. Agreed. It would be good to make both available to the general public. > > That said, I have already received requests from a few observers since > yesterday, and I think it may indeed be helpful to have the strawman > available alone. However, it is unclear what the JCP rules are for > making material like this available outside the EG, and I have already > contacted the JCP PMO for clarification. Fair enough, but I think this should be ok since the JCP rules seem to encourage transparency. For example, section 2.1.1 of JCP 2.6 ([1]) says: "While Spec Leads are free to operate Expert Groups in whatever style they feel is most appropriate, they are encouraged to choose a style that provides maximal transparency to the Expert Group, community, the EC members and the public. The PMO provides Spec Leads with tools and techniques for making the actions of their Expert Groups transparent, and the EC members expect Spec Leads to carefully choose which tools are best for their Expert Groups and commit to using them. Transparency is valuable to everyone in the community, especially the Expert Group, because it offers broader feedback to the group and helps build broader support for the final spec." So the JCP is, at least in spirit, fully supportive of the kind of transparency needed by JSR 277. It's just a shame we can't simply expose the Expert Group private page to the public, although this is something the JCP should really consider supporting soon. Section 2.3.1 of [1] says: "If the Expert Group makes major revisions to the draft during Early Draft Review, the Spec Lead should send the revised draft, along with a synopsis of the changes, to the PMO. The PMO will notify Members of any updated drafts and change synopses received and make them available for download by Members and the public." This allows for multiple early draft specifications. I guess the JCP's main concern here is appropriate notification to JCP Members that a draft has been issued. This is sensible as not everyone who is interested will have the time to follow the mailing list. I doubt that it would be appropriate to notify JCP Members of interim strawman documents though. Then there's the precedent of the JSR 294 strawman appearing in a blog even before the EG was formed. The JCP didn't object to that, AFAIK. Also, I forwarded at least one of the JSR 291 drafts to the publicly viewable mailing list and again the JCP didn't object. Anyway, let's hope the JCP clarify this quickly. :-) > > - Stanley > > > Glyn Normington wrote: > > > > Hi Stanley > > > > Don't you think we should make the strawman available to observers of > > this list so they have the context to follow subsequent discussion of > > the strawman and send in any insights they may have? > > > > Glyn Glyn [1] http://jcp.org/en/procedures/jcp2 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Strawman: Services and service-providers support
Hi Stanley Don't you think we should make the strawman available to observers of this list so they have the context to follow subsequent discussion of the strawman and send in any insights they may have? Glyn "Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 22/05/2007 23:54:42: > Hi JSR 277 experts, > > I've been working with Peter von de Ahe and Dave Bristor in the Java SE > Tools and Libraries team to come up with a strawman for the services and > service-providers support. This strawman was developed based on the > initial requirements we discussed in the EG several weeks ago, and it > defines how the module system will support the service/service-provider > model defined in the java.util.ServiceLoader API. > > I have uploaded the strawman [1] to the expert group home page for > download. If you prefer to receive them in email, please let me know and > I'll send it to you directly. > > I would like to get your inputs by 6/5/2007, so we can determine how to > refine the strawman further. > > Thanks, > - Stanley > > [1] Services and service-providers strawman > http://www.jcp.org/en/eg/download/jsr-277-service-provider- > strawman-05222007.pdf?id=277&fileId=3438 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
