On Wed, Dec 12, 2012 at 10:05 AM, Peter Levart <peter.lev...@gmail.com> wrote: > On 12/12/2012 04:51 PM, Zhong Yu wrote: >> >> If a class loader is declared fully concurrent, yet >> getClassLoadingLock() is invoked, what's the harm of returning a >> dedicated lock anyway, exactly like what's done before? > > To encourage people to not use locking in the first place ;-)
In that case throwing an exception is probably better than returning a null. > No, seriously, to be able to remove the deprecated feature in the future, > perhaps. > Peter > >> >> On Tue, Dec 11, 2012 at 7:40 PM, David Holmes <david.hol...@oracle.com> >> wrote: >>> >>> On 11/12/2012 9:58 PM, Peter Levart wrote: >>>> >>>> On 12/11/2012 12:27 PM, David Holmes wrote: >>>>> >>>>> Peter, >>>>> >>>>> You are convincing me that all superclasses must be fully concurrent >>>>> too. Otherwise we are just trying to second-guess a whole bunch of >>>>> what-ifs. :) >>>> >>>> >>>> If you think some more, yes. The superclass might not use >>>> getClassLoadingLock() but rely on the fact that findClass() is allways >>>> called under a guard of per-class-name lock, for example. It's a matter >>>> of how far to go to prevent such miss-behaving fully-concurrent >>>> subclasses. So far to also prevent fully-concurrent subclasses that >>>> would otherwise be perfectly correct? >>>> >>>> Maybe not. Creating custom ClassLoaders is not an average programmer's >>>> job. Those that do this things will of course study the implementations >>>> of superclasses they extend and do the right thing. And it's reasonable >>>> to expect that they more or less will only extend JDK's ClassLoaders - >>>> but on the other hand if they only extend JDK's class loaders, they are >>>> not prevented to be fully-concurrent either way. Hm... >>> >>> >>> Again I think it is just too hard to try and second-guess how a >>> parallel-loader might rely on the per-class locks (I actually don't see >>> any >>> reasonable use for them beyond flow-control), and then how a concurrent >>> loader subclass might need to modify things. >>> >>> If we simply disallow this then we can relax that constraint in the >>> future >>> if valid use-cases turn up for that capability. Of course if someone has >>> a >>> valid use-case during this discussion phase then of course that will >>> influence the decision. >>> >>> Thanks, >>> David >>> >>>> Peter >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 11/12/2012 7:44 PM, Peter Levart wrote: >>>>>> >>>>>> On 12/11/2012 10:29 AM, David Holmes wrote: >>>>>>> >>>>>>> On 11/12/2012 7:20 PM, Peter Levart wrote: >>>>>>>> >>>>>>>> On 12/11/2012 03:55 AM, David Holmes wrote: >>>>>>>>>> >>>>>>>>>> Question on the source code: registerAsFullyConcurrent has >>>>>>>>>> confusing >>>>>>>>>> comment - >>>>>>>>>> do the super classes all need to be parallel capable? Or do the >>>>>>>>>> super >>>>>>>>>> classes all need >>>>>>>>>> to be FullyConcurrent? I assume the latter, so just fix the >>>>>>>>>> comments. >>>>>>>>> >>>>>>>>> >>>>>>>>> Actually it is the former. There's no reason to require that all >>>>>>>>> superclasses be fully-concurrent. Of course a given loaders degree >>>>>>>>> of >>>>>>>>> concurrency may be constrained by what it's supertype allows, but >>>>>>>>> there's no reason to actually force all the supertypes to be >>>>>>>>> fully-concurrent: it is enough that they are at least all parallel >>>>>>>>> capable. >>>>>>>> >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> There is one caveat: if ClassLoader X declares that it is >>>>>>>> fully-concurrent and it's superclass Y is only parallel-capable, >>>>>>>> then X >>>>>>>> will act as fully-concurrent (returning null from >>>>>>>> getClassLoadingLock()). superclass Y might or might not be coded to >>>>>>>> use >>>>>>>> the getClassLoadingLock(). X therefore has to know how Y is coded. >>>>>>>> To be >>>>>>>> defensive, X could ask for Y's registration and declare itself as >>>>>>>> only >>>>>>>> parallel-capable if Y declares the same so that when Y is upgraded >>>>>>>> to be >>>>>>>> fully-concurrent, X would become fully-concurrent automatically. To >>>>>>>> support situations where the same version of X would work in two >>>>>>>> environments where in one Y is only parallel-capable and in the >>>>>>>> other Y >>>>>>>> is fully-concurrent, there could be a static API to retrieve the >>>>>>>> registrations of superclasses. >>>>>>> >>>>>>> >>>>>>> I don't quite follow this. What code in the superclass are you >>>>>>> anticipating that the subclass will use which relies on the lock? Or >>>>>>> is this just an abstract "what if" scenario? >>>>>> >>>>>> >>>>>> This is more or less "what if". There might be a subclass Y of say >>>>>> java.lang.ClassLoader that overrides loadClass or findClass, declares >>>>>> that it is parallel-capable and in the implementation of it's >>>>>> loadClass >>>>>> or findClass, uses getClassLoadingLock() to synchronize access to it's >>>>>> internal state. Now there comes class X extends Y that declares that >>>>>> it >>>>>> is fully-concurrent. Of course this will not work, X has to declare >>>>>> that >>>>>> it is parallel-capable, because Y uses getClassLoadingLock(). >>>>>> >>>>>> What I suggested in the next message is to not change the registration >>>>>> API but rather provide getClassLoadingLock() that returns non-null >>>>>> locks >>>>>> when any of the superclasses declare that they are only >>>>>> parallel-capable, not fully-concurrent. >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Or, to have less impact on future deprecation of old >>>>>>>> parallel-capable >>>>>>>> registration API, the fully-concurrent registration API: >>>>>>>> >>>>>>>> protected static boolean registerAsFullyConcurrent() >>>>>>>> >>>>>>>> might take a boolean parameter: >>>>>>>> >>>>>>>> protected static boolean registerAsFullyConcurrent(boolean >>>>>>>> downgradeToPrallelCapableIfAnySuperclassIsNotFullyConcurrent) >>>>>>>> >>>>>>>> >>>>>>>> and provide no accessible API to find out what the registration >>>>>>>> actually >>>>>>>> did (register as parallel-capable or fully-concurrent - return true >>>>>>>> in >>>>>>>> any case). >>>>>>>> >>>>>>>> Since all JDK provided ClassLoaders will be made fully concurrent, >>>>>>>> this >>>>>>>> might only be relevant if there is vendor A that currently provides >>>>>>>> only >>>>>>>> parallel-capable ClassLoader implementation and there is vendor B >>>>>>>> that >>>>>>>> subclasses A's loader and wants to upgrade and be backward >>>>>>>> compatible at >>>>>>>> the same time. >>>>>>>> >>>>>>>> Does this complicate things to much for no real benefit? >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >
