JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
task_small.png
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
    Task
  • Status
     
    New
  • Assigned to
     lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Integration
  • Resolution
    Not determined
  • Priority
    Normal
  • 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.