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
