JPPF Issue Tracker
Please log in to bookmark issues
OPEN  Task JPPF-565  -  Feature removals
Posted Dec 05, 2018 - updated Dec 09, 2018
lolo4j (lolocohen) has been working on this issue since December 05, 2018 (07:18)
Issue details
  • Type of issue
  • Status
  • Assigned to
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
  • Resolution
    Not determined
  • Priority
  • Targetted for
    icon_milestones.png JPPF 6.1
Issue description
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.