RFR: 8026427: deprecate obsolete APIs from java.rmi

[Stuart Marks]

Hi Daniel,

Yes, this round is just deprecation, not removal, so anything that uses 
RMISecurityManager can continue to do so for the near future.

Ideally we should remove all references to RMISecurityManager from the JDK, but 
this can be done later. The only cost is some deprecation warnings. (Such 
warnings are disabled at the moment.)

RMISecurityManager is an empty subclass of SecurityManager, thus there are no 
semantic differences. It's been this way since around 1.3. There are probably 
applications out there that construct RMISecurityManager. At least, some RMI 
tutorials advise doing this (implying that it's necessary for some reason). 
Deprecation should flush out these usages.

I suppose somebody could have written an application that downcasts to 
RMISecurityManager, or does instanceof RMISecurityManager, but there would be no 
point in doing so, since there are no APIs revealed by doing so. Thus I think it 
would be fairly safe to change all usages of RMISecurityManager to 
SecurityManager in the JDK.

s'marks

On 10/22/13 5:58 AM, Daniel Fuchs wrote:
> Hi Stuart,
>
> This looks good to me.
>
> RMISecurityManager:
>
> I see that there are a few places in the JDK where we still
> instantiate an RMISecurityManager.
>
> I assume we must unfortunately keep them for backward compatibility,
> in case some application code would try to downcast
> System.getSecurityManager() to RMISecurityManager?
>
> best regards,
>
> -- daniel (not a reviewer)
>
> On 10/22/13 4:07 AM, Stuart Marks wrote:
>> Hi all,
>>
>> Please review this small spec change to deprecate some obsolete RMI
>> APIs, along with a bit of associated cleanup. There are no functional
>> changes in this changeset.
>>
>> Bug:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8026427
>>
>> Webrev:
>>
>>      http://cr.openjdk.java.net/~smarks/reviews/8026427/webrev.0/
>>
>> Specdiff:
>>
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8026427/specdiff.0/overview-summary.html
>>
>>
>>
>> Thanks,
>>
>> s'marks
>