Multi Language Program Support

[TwoOfTwelve]

This PR adds the capability to parse multiple languages with JPlag in on run.

A new language module is added, which identifies a module for each file and delegates the parsing to that module. The resulting tokens are concatenated and passed back to JPlag. This does not allow comparing different languages with each other, but it allows for projects that contain multiple languages (multi-language projects).

The languages are discovered on runtime using the same mechanism as the cli. This made it necessary to move the LanguageLoader class from the cli module to the language-api module.
The language modules are identified using the suffixes defined in the individual language modules. This matches the way JPlag already identifies code files in a submission.
The user has to select all language modules that should be used manually using a language specific option.

If multiple language modules are selected for the same suffix, a module is chosen arbitrarily.

Future considerations:

• Change Cli to allow configuration for multiple language-modules. Right now it's not possible to set language specific options for the selected languages. Changing that would be a major change to the cli though.
• Allow implicitly selecting all languages. This would make JPlag easier to use, since a user would not have to select a language module anymore, but makes handing language modules with the same suffix harder
• Find a better way to identify the correct language module. This could be done by adding priorities to language modules, or by adding function to analyze the contents of a file before.

Usage example:

jplag multi --languages java,cpp <path to submissions>

[uuqjz]

Looks good. Just found two small things.

[uuqjz]

LGTM

[robinmaisch]

Neat!

[uuqjz]

@TwoOfTwelve could you adress the Sonar issues please?

[tsaglam]

For conceptually larger PRs, PRs that add a lot of new functionality, or PRs that are research-related, the PR description should be more detailed. It should sufficiently describe the intent of the PR and how it works. Also, edge cases like the one mentioned below. Note that the PRs are linked in the release note, so we should write them as intended for someone external.

As an example, for this PR, write:

• What is the intent (parsing programs with code from multiple languages)
• How is it implemented (language module that passes the files to the language-specific ones and receives tokens)
• Design decisions (e.g., loading languages dynamically instead of dependencies)
• Edge cases (e.g. see below)

[tsaglam]

This will currently pick the first language for cases where multiple languages support the same file type. Have you discussed this behavior? This affects the C/C++ modules and also the EMF modules.

[tsaglam]

(also in future Java vs. Java-CPG)

[TwoOfTwelve]

I have discussed this with Robin, Nils and Sebastian. Currently it's not that big of an issue, since the user has to select the modules manually. If there are multiple selected modules for the same file, the module is chosen arbitrarily.

This should be addressed in the future, maybe by adding priorities to language modules or by distinguishing files in more detail than just the suffix. I think it should be done separately though.

[tsaglam]

Ah I understand; I overlooked that the users specify the languages when using the module.
In the long run, I considered making the language module the default, but that would only be user-friendly if users do not need to specify languages. This would mean the multi-language module automatically parses all code that JPlag supports. Then we need prioritization.

With the current solution, we add yet another cli argument, which is less likely to be used by many users. For now, let us leave it as is, but before the release, we need to think about which mode we truly want. If we want more people to try out the language module, we probably need to implement the unparameterized version. However, in all cases, I would not make it the default language straight away.

[tsaglam]

Looks good; we should discuss in the future if we prefer specifying languages or if all supported languages should be used by default.

[TwoOfTwelve]

@tsaglam Can you look at the sonar issue with the cyclic dependency? I think it's fine in this case.

[tsaglam]

Can you look at the sonar issue with the cyclic dependency? I think it's fine in this case.

I briefly looked at the cycles.
The multi-language cycle could be resolved by avoiding the .class comparison and adding a method to the language interface. However, I would not do that, as this could also be resolved when changing the things discussed above in a later PR. So let us leave that cycle as is.

The other one was not immediately clear to me, I will have a look at it later.

[TwoOfTwelve]

I didn't expect the other one either. I'll take a look at it too

[tsaglam]

I think the other one is: Submission --> JPlagOptions --> SimilarityMetric --> JPlagComparison --> Submission.
Which is not mentioned by Sonar. It should be fine as well; I think structurally SimilarityMetric is the culprit and needs a redesign; I think it takes over the responsibility of the JPlagComparison class via the method references. But this has been part of the code for a long time. I would say, fix only the public modifier, and we ignore the cycles for now.

EDIT: I have an idea how to fix this cycle in a future PR, but this is not time-sensitive at all.

[sonarqubecloud]

Quality Gate passed for 'JPlag Plagiarism Detector'

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud