Java 2.0 migration planning. JEP's for removal.

[Stuart Marks]

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 
though.

> 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:

   https://cr.openjdk.java.net/~briangoetz/amber/serialization.html

You can also see that some of this thinking is embodied in current JDK releases:

   https://inside.java/2021/03/12/simpler-serilization-with-records/

> 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.

s'marks