We propose that the following features be either deprecated or dropped altogether:

1. .Net integration

This feature relies heavily on the jni4net framework, which hasn't seen a new version in 4 years. Following the switch to Java 8 (feature request JPPF-548), its .Net proxy generator is no longer fully working, as it doesn't handle new Java 8 constucts such as default methods in interfaces, It is currently not possible to build it with the current code, and I don't see any solution that can be mainained in the long term. I propose to drop this feature from JPPF 6.1 forward. We will still maintain it for prior versiosn.

2. Android integration

The switch to Java 8 requires a lot of changes to the Android port, including, but definitely not limited to, the min Android sdk version and build tools. I haven't evaluated the changes that need to be done to the code itself, and, given the lack of bandwith (I'm just 1 developer), I tend to think it should be dropped so we can focus on more modern features such as job streaming and big data. If anyone volunteers to take this feature on, I'll be happy to assist in any way, In any case, we'll keep maintaining it for versions up to 6.0.

3. Persistent data in NodeRunner

The NodeRunner class provides 3 methods setPersistentData(), getPersistentData() and removePersistentData(), which were intended for tasks to be able to store, access and manage data on the nodes accross job executions. These methods are inherently dangerous, because they can cause the nodes to retain objects and classes from many different class loaders, resulting in class loader leaks and potential out-of-memory conditions. This feature isn't used anymore in the JPPF code, and I believe now's a good time to remove it.

4. Node security policy

I can no longer see the benefit of the security policy in the node configuration. We haven't touched this code in years, the default node security policy in the node distribution is no longer close to being useful or even accurate, and this can be easily replaced with a standard SecurityManager and associated security policy file. This feature should definitely be removed.

5. JMXMP JMX remote connector

Since JPPF 6.0, we use the new nio-based connector, which allows the JMX port to be the same as the server port, and thus simplifies the configuration. Itis still possible to switch to the JMXMP connecotr, via a configuration property. However, there isn't much of a point in keeping the JMXMP connector as part of the JPPF distribution, since it is not used and simple adds a useless dependency. I propose that we drop it from the distro, and perhaps set it up as a separate project/Github repo.