Replace univocity parsers with JSaPar for handling fixed-width files

[rolnico]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?
No

What kind of change does this PR introduce?
Change of dependency

What is the current behavior?
PowSyBl uses univocity-parsers for handling fixed-width files (parsing and writing), but this lib is abandoned since 2021.

What is the new behavior (if this is a feature change)?
PowSyBl now uses JSaPar for handling fixed-width files.

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

[geofjamg]

I don't think it is a good idea to replace a mature and robust CSV parser like univocity (even if avandonned it is still working very well and do not need any evolution) by a ramdom young library not really popular with only 2 releases. The risk to move is much greater that keeping univocity.

[rolnico]

I don't think it is a good idea to replace a mature and robust CSV parser like univocity (even if avandonned it is still working very well and do not need any evolution) by a ramdom young library not really popular with only 2 releases. The risk to move is much greater that keeping univocity.

There are more than 2 releases: if you look at the tags or on https://mvnrepository.com/artifact/org.tigris.jsapar/jsapar, you'll see more.

I'll still do the performance comparison to know how this "new" lib works compared to univocity

[rolnico]

I did some tests to compare the performances of this version vs main. Each test consisted of importing an IEEE-CDF test file and then exporting the model. Each operation was performed 10000 times consecutively, and the results are based on the last 9950 draws.

Operation	File	main (ms)	JSaPar (ms)	Difference (ms)	Difference (%)
Import	ieee9cdf.txt	0,795	0,102	-0,693	-87,17 %
Export	ieee9cdf.txt	0,482	0,243	-0,239	-49,58 %
Import	ieee14cdf.txt	1,094	0,110	-0,984	-89,93 %
Export	ieee14cdf.txt	0,509	0,297	-0,212	-41,65 %
Import	ieee14cdf-solved.txt	1,088	0,109	-0,979	-89,96 %
Export	ieee14cdf-solved.txt	0,556	0,293	-0,263	-47,30 %
Import	ieee30cdf.txt	1,008	0,190	-0,818	-81,15 %
Export	ieee30cdf.txt	0,638	0,427	-0,211	-33,08 %
Import	ieee57cdf.txt	1,130	0,341	-0,789	-69,82 %
Export	ieee57cdf.txt	0,846	0,582	-0,264	-31,19 %
Import	ieee118cdf.txt	1,674	0,754	-0,920	-54,96 %
Export	ieee118cdf.txt	1,476	1,069	-0,407	-27,58 %
Import	ieee300cdf.txt	2,247	1,796	-0,451	-20,08 %
Export	ieee300cdf.txt	2,815	2,142	-0,673	-23,91 %
Import	ieee9zeroimpedancecdf.txt	0,722	0,069	-0,653	-90,45 %
Export	ieee9zeroimpedancecdf.txt	0,429	0,267	-0,162	-37,76 %

Thanks to the change of dependency, we could have a major gain in performances.

Note: exported files have changed a bit, but they are now closer to IEEE-CDF standard. The models created from the files are however unchanged.

[sonarqubecloud]

Quality Gate failed

Failed conditions
5.5% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[rolnico]

Replaced by #3660