Java 2.0 migration planning. JEP's for removal.
stuart.marks at oracle.com
Wed May 26 18:38:59 UTC 2021
On 5/23/21 6:09 PM, jini at zeus.net.au wrote:
> Will RMI and the RMI registry be put up for removal soon?
> Just seeing the writing on the wall here, with other components being removed, I was
> wondering when will RMI be proposed for removal.
> We still use some RMI interfaces and exceptions in our API's but don't use the RMI
> implementation (except for the RMI registry that occurs over TLS sockets on the
> local machine), same for Activation.
There are no plans for removing "core" RMI at present (as opposed to RMI
Activation), but if you wanted to make a case for their removal, be my guest.
Note that even though RMI Activation is "newer" than core RMI, Activation never got
much traction, and so has seen extremely little use. It also has a larger
maintenance overhead than core RMI. These combined made it a candidate for removal.
There is still some use of core RMI by legacy applications, so we're leaving it in
the platform for the time being. As we've discussed earlier, all of this stuff is
essentially obsolete. Maybe at some point there will be so little use of any part of
RMI that it will eventually be removed. I don't think we're at that point quite yet
> I'm guessing if we need to make a breaking release of our software, we might as well
> get all the breaking code out of the way in one go, rather than make multiple
> breaking releases as Java removes parts of its API's.
I'll just observe that there are mechanism such as multi-release jars that might
help with this situation.
> Betting Serialization will be removed at some point too, we will also want to remove
> all Java Serialization as well.
There are many reasons we'd like to get rid of serialization, but in fact it's
heavily used today, so it won't be deprecated or removed anytime soon. (I'm talking
specifically about the serialization mechanism in the JDK, as in java.io.Serializable.)
Serialization as a general concept is very important and is likely never going to go
away. To this end we're thinking of a long-term path to upgrading the platform to
provide better language support for serialization in general, which we hope will
eventually produce a mechanism that supersedes the existing Java serialization
mechanism. Some of our thoughts are here:
You can also see that some of this thinking is embodied in current JDK releases:
> Can we get an indication on what's on the chopping block so we can start to consider
> how to handle it?
In general, deprecation-for-removal is the indication of what's on the chopping
block. Currently deprecated stuff *might* be upgraded to for-removal at some point,
though that doesn't apply to everything. In general, we don't provide advance notice
of deprecation-for-removal, because deprecation-for-removal is already advance notice.
More information about the jdk-dev