On 4/10/2012 9:56 PM, Paul Sandoz wrote:
On Oct 4, 2012, at 12:37 PM, David Holmes<[email protected]> wrote:
Paul,
On 4/10/2012 7:53 PM, Paul Sandoz wrote:
On Oct 4, 2012, at 11:34 AM, David Holmes<[email protected]> wrote:
These parts of the javadoc for get/setContextClassLoader are simply wrong.
Wrong or not because of such JavaDoc developers have been coding using TCCL with certain
expectations of "null" different to that of just meaning the bootstrap CL.
How would you propose to fix it?
I don't see anything that actually needs fixing (apart from the javadoc).
Anyone using getCCL has to expect null as a possibility and they are then free
to proceed however they like. The obvious ways to proceed are as I outlined
earlier:
- use current classloader
- use system loader
- use bootstrap loader
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.
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.
David
-----
Paul.
