Reviewer and committer request for 7198496

[Paul Sandoz]

On Oct 4, 2012, at 3:37 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> So you are proposing to widen the scope? since i interpret the current JavaDoc to correspond to only the latter two options.
>>> 
>>> I think you are missing the point. If getCCL returns null it returns null - end of story.
>> 
>>> What the caller of getCCL does after that is their business, it has nothing to do with the spec for getCCL.
>> 
>> I think we may be misunderstanding and/or talking over each other. IIUC you are saying what behaviour you would like and i am saying how i interpret the current behaviour.
>> 
>> I interpret the current JavaDoc as normatively stating what the caller of getCCL *must* do if null a value is returned.
> 
> And that is the problem. A spec for a method can not normatively say what the caller of the method must do with the result.
> 

Ah! i understand where you are coming from now, thanks for patience. 

It can say it but cannot enforce it. It's something developers can use to point fingers at each other :-)

In this case I would categorise it as a SHOULD (or RECOMMENDED) rather than a MUST in RFC parlance:

"@return  the context ClassLoader for this Thread, or {@code null} indicating the caller SHOULD use the system class loader (or, failing that, the bootstrap class loader) in place of what would otherwise be the non-null context ClassLoader."

AFAIK i don't think there is any spec in the JDK/JCP on key words to indicate requirement levels.
 

>> A little tweak to the doc might help:
>> 
>> From:
>> 
>> "@return  the context ClassLoader for this Thread, or {@code null} indicating the system class loader (or, failing that, the bootstrap class loader)"
>> 
>> To:
>> 
>> "@return  the context ClassLoader for this Thread, or {@code null} indicating the caller shall use the system class loader (or, failing that, the bootstrap class loader) in place of what would otherwise be the non-null context ClassLoader."
>> 
>> Because TCCL has the annoying property of decoupling behaviour (or "action at a distance") i think i can see why it was documented in such a way.
>> 
>> 
>> So from my perspective you are proposing a change in the specified behaviour, perhaps to something like:
> 
> No I'm not because you can not specify how your caller must behave.
> 
>> @return  the context ClassLoader for this Thread, or {@code null} indicating the context ClassLoader is undefined. It is recommended that ...
>> 
>> Which might be fine, from a backwards compatibility perspective, i am not sure, but i have been on the receiving end of some very tricky bugs due to TCCL, hence a conservative position.
>> 
>> 
>> <snip>
>>>  loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
>>> 
>>> which has the same semantic effect, but leaves some "dead" code internally as now loader can not be null.
>>> 
>> 
>> It can if the system CL is null.
> 
> The system CL can never be null.
> 

I thought that was the case too, my first webrev had the if/else removed but then i updated it after i read the JavaDoc of ClassLoader.getSystemClassLoader():

  Returns: The system ClassLoader for delegation, or null if none

Paul.