Hi Adrian, I am particularily interested in this statement:
" * It isn't really that difficult to support " What do you exactly mean ? What is the current mechanism for supporting it ? Also I would like to mention that even if we do not allow cyclic dependencies it will still be possible to migrate the old code. All the classes from a cycle should be contained in a single module. I am afraid that if we allow cyclic dependencies in the specification it will be widely abused and the outcome will be negative. We had such bad experience in the past. From my point of view the specification should encourage the people to create good designs not bad ones with the excuse for backward compatibility. Best Regards, Pavel Genevski Deployment Team SAP Labs Bulgaria Tel. +359 2 9157 133 -----Original Message----- From: Java Community Process JSR #277 Expert List [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Wednesday, 5. December 2007 14:53 To: [EMAIL PROTECTED] Subject: Re: Thread context class loader... We already discussed the cyclic dependencies issue. If I remember the summary correctly: * We decided it is a problem that always exists including in the JDK itself. * Not supporting it would be a barrier to migration for existing code. * It isn't really that difficult to support * We should discourage its use, in the spec but also an implementation could have something like a system property that disallows it. On the "RI" Stanley posted this back in June: " Hi experts and observers, We have just made an early snapshot of the JSR 277 and 294 implementation available through the Modules project on openjdk: http://openjdk.java.net/projects/modules/ This snapshot basically covers the basic features described in the updated specification in JSR 277, and the reflective APIs defined in JSR 294. You should expect the snapshot will be updated periodically going forwards, as we continue to evolve the implementation and adding many more functionalities in the next few months. We will continue to focus our discussions in this EG mailing list for the JSR 277 specification. For those of you interested in discussing the implementation in the Modules project, we have made two discussion lists available to the Java community: * [EMAIL PROTECTED] Technical discussion about the implementation of the Modules project * [EMAIL PROTECTED] General discussion of the Modules project and how to use modules If you are interested in discussing the Modules project with its developers, or in discussing how to use JSR 277 and JSR 294, be a subscriber today! - Stanley " On Wed, 2007-12-05 at 13:48 +0100, Genevski, Pavel wrote: > Hi, > > Do you have any comments on my suggestions below ? > And in addition, can you point me to the source code locations of the > reference implementation of this JSR ? > > > Best Regards, > Pavel Genevski > Deployment Team > SAP Labs Bulgaria > Tel. +359 2 9157 133 > > -----Original Message----- > From: Java Community Process JSR #277 Expert List > [mailto:[EMAIL PROTECTED] On Behalf Of Genevski, Pavel > Sent: Wednesday, 17. October 2007 11:41 > To: [EMAIL PROTECTED] > Subject: Re: Thread context class loader... > > Hi, > > While we are talking about classloading I would like to add a few > comments about the cyclic dependencies mentioned in section 8.3.4 of the > spec. How do you imagine the classloading with cyclic dependencies? What > are the benefits of allowing cyclic dependencies ? > > In my opinion cylcic dependencies occur mostly because of bad system > architecture and are always hard to handle. The tough questions that > emerge with them are for example: > > - what should be built first > - which classloader should be created first. > > One obvious runtime solution for classloading of modules with cyclic > dependencies is to have a common classloader for all the modules in the > cycle, but are there enough benefits that come from cyclic dependencies > that are worth doing this and breaking module isolation? > > > Best Regards, > Pavel Genevski > Deployment Team > SAP Labs Bulgaria > Tel. +359 2 9157 133 > > > > -----Original Message----- > From: Java Community Process JSR #277 Expert List > [mailto:[EMAIL PROTECTED] On Behalf Of Andy Piper > Sent: Tuesday, 18. September 2007 12:44 > To: [EMAIL PROTECTED] > Subject: [LIKELY JUNK]Re: Thread context class loader... > > At 03:55 18/09/2007, Bryan Atsatt wrote: > >Thoughts? > > Given our experience with OSGi I agree that this needs addressing. We > have found, though, that the notion of a "thread of execution" is > somewhat more amorphous in a non-JEE environment. In using > Spring-OSGI we have found we often have to force the client > classloader to be a delegate of the target bundle's, but there are > issues with trying to actually make this switch happen. I'm wondering > whether we actually need some VM-level support to make this work well. > > 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. -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx
