RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes

[Michael McMahon]

Chris,

Okay, I think it's fine then. The term "default package" is used, but I 
accept
it's not referred to as such, in the JLS.

Thanks,
Michael

On 09/04/14 12:42, Chris Hegarty wrote:
> Thanks for looking at this Michael,
>
> On 09/04/14 11:51, Michael McMahon wrote:
>> Is there potential for confusion there? <system default package> really
>> just
>
> I just took the wording from the URL spec. I guess it was agreed upon 
> at some point.
>
>> means an "implementation defined" package rather than the Java
>> language's "default package"?
>
> Just on this, there is no such term as "default package" in the JLS, 
> it is the "unnamed package". But I accept that this is probably a 
> subtle difference that may not be widely known.
>
> I'm happy with the wording as is, but if you think we should change it 
> then we should probably change URL too.
>
> -Chris.
>
>
>>
>> Michael
>>
>> On 08/04/14 20:03, Chris Hegarty wrote:
>>> java.net.URLConnection.getContent() incorrectly specifies the default
>>> location of content handler classes as sun.net.www.content. ( this
>>> location is implementation specific )
>>>
>>>    "If no content handler factory has yet been set up, or if the
>>> factory's createContentHandler method
>>>      returns null, then the application loads the class named:
>>>           sun.net.www.content.<contentType> "
>>>
>>> This should be changed to something like:
>>>      <system default package>.<contentType>, similar to what is done
>>> in URL [1]
>>> Trivial specDiff:
>>> http://cr.openjdk.java.net/~chegar/8039470/URLConnection-report.html
>>>
>>> -Chris.
>>>
>>> [1]
>>> http://docs.oracle.com/javase/8/docs/api/java/net/URL.html#URL-java.lang.String-java.lang.String-int-java.lang.String- 
>>>
>>>
>>>
>>