We lose all these mutators because of the mutators removed by default in PIT?

Looks like it, yes. We did lose a lot of mutations operators (see Mutations.java, MutatorApiOfPitTest.java and the list of research mutators). That being said I believe we should take some time to make sure I didn't miss something while upgrading.

@echebbi So creating a new bundle for https://github.com/pitest/pitest-rv-plugin and adding it to our distribution would bring the old mutators back?

Yes, just like we did for the pitest-junit5 plugin. Do you think that we should integrate the pitest-rv plugin after all?

@echebbi maybe we should/could. I'm a bit worried by the fact that people using Pitclipse would have more mutators than those using Maven and ignoring the new pitest-rv, but maybe we can rely on them knowing the Maven plugin as well.

By default we run Pitest's DEFAULT mutator group so our mutators set would still be the same as a bare Pitest configuration. pitest-rv's mutators would only be exposed through the preferences/configuration pages which feels fair to me.

We can even add a column to the mutators table that explicitely states the origin of each mutator:

@echebbi yes that'd be useful; but would such information be easily (automatically) retrieved and easy to maintain?

Moreover, with pitest-rv we would restore the "old defaults" or not?

would such information be easily (automatically) retrieved and easy to maintain?

It might be possible to retrieve/infer the information through reflection. My intuition is that since we have access to the MethodFactoryFactory instances (each mutation operator is implemented as a child of MethodMutatorFactory) we should be able to get the info with something along the lines of:

// maps plugin ID to the name we want to display in the table
//
Map<String, String> pluginIdToContributorName = Map.of(
    "org.pitest", "pitest",
    "org.pitest.pitest-rv-plugin", "pitest-rv"
);
Collection<MethodMutatorFactory> mutators = ServiceLoader.load(MethodMutatorFactory.class, IsolationUtils.getContextClassLoader());

for (MethodMutatorFactory mutator : mutators) {
    //
    // retrieve the contributor through reflection
    //
    Bundle bundle = FrameworkUtil.getBundle(mutator.getClass());
    //
    // update our 'Mutators' enum with the contributor name
    //
    String contributorName = pluginIdToContributorName.get(bundle.getBundleId());
    Mutators.valueOf(mutator.getName()).setContributorName(contributorName);
}

Or, if we want to be really extensible it should be possible to craft a solution based on a custom extension point so that external plug-ins can provide new mutators without having to change a single piece of code in Pitclipse's core. That would require some refactoring though so I believe that such a work would deserve its own PR.

Moreover, with pitest-rv we would restore the "old defaults" or not?

We wouldn't because this group is not related to the research operators and has been completely removed. We may want to somehow support the groups related to research operators though.

@echebbi thanks for the clarification, especially about the old defaults, which are now gone for good. I thought the pitest-rv was related to that so I was reluctant to add pitest-rv right away because that would have required to undo the removal of old defaults, but it's not like that :)

So, shall we address pitest-rv in a new PR and go on with this one?

I would also try to build with Java 21 and have a UI test with Java 21, but we can do that in another PR as well.

shall we address pitest-rv in a new PR and go on with this one?

@LorenzoBettini fine by me!