Java 2.0 migration planning. JEP's for removal.

[jini at zeus.net.au]

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.

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.

Betting Serialization will be removed at some point too, we will also 
want to remove all Java Serialization as well.

Can we get an indication on what's on the chopping block so we can start 
to consider how to handle it?

Thinking we are going to need to maintain two separate forks of our 
software to support both Java 2.0 and Java 1.8 to 1.17.

We could bundle all the insecure code, such as TCP connections into one 
release without any dependencies on JAAS or SecurityManager, and remove 
all AccessController.doPrivileged etc, to be used on private networks, 
which will later utilise the new security features in later versions of 
Java 2.0 that are yet to be determined, we would also remove all 
Permissions and policy, and remove the ability to transfer a calling 
subject from one JVM to another, so this would be designed to be used on 
local networks behind a firewall, this will have no migration cost for 
users moving to Java 2.0.  Rather than attempt to duplicate current 
security functionality, we would simply remove it.

We would make the other release our secure release, for use on untrusted 
networks, including the internet, which would include our implementation 
of Activation, used as a service watchdog, TLS and Kerberos connections 
that depend on JAAS and SecurityManager and AccessController and 
principles of least privilege.  This won't work on Java 2.0, but people 
who require security would need to continue to use it for the 
foreseeable future, until it becomes clearer what the new best practices 
will be to lock down Java securely, it's possible we may never migrate 
this version to Java 2.0.

This way we could serve both Java markets.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.