fix!: Switch oslc:maxSize from int to BigInteger

[berezovskyi]

Description

Switch oslc:maxSize from int to BigInteger as per spec.

Checklist

• This PR adds an entry to the CHANGELOG. See https://keepachangelog.com/en/1.0.0/ for instructions. Minor edits are exempt.
• This PR was tested on at least one Lyo OSLC server or adds unit/integration tests.
• This PR does NOT break the API

Issues

Closes #0; Closes #00

(use exactly this syntax to link to issues, one issue per statement only!)

[berezovskyi]

Too little time to test before the 5.0 release.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[berezovskyi]

@Jad-el-khoury @jamsden I plan to merge this into 6.0.0-SNAPSHOT soon (today, ideally) and release it with 6.0.0 in October(ish). Should give us enough time to test.

For the record, I was floating the idea to use a Long, which would allow to use up to 9,223,372,036,854,775,807 TRS Events but Frej voiced disagreement given that the OSLC TRS Spec requires support of arbitrary length integers. I agreed (mostly), it will be easier to have the main SDK support the spec fully. The performance hit is expected to be small, given that we don't do any arithmetic on those IDs.

[jadelkhoury]

sounds reasonable to me

[berezovskyi]

@jadelkhoury @jamsden I apologize for the confusion, I just went over the PR diff and it seems like a change to Lyo Core, not just to the TRS. More specifically, https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-vocab.html#maxSize

See https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.html#PropertyShape for the shape, it demands an unlimited xsd:integer instead of xsd:int, just as I wrote.

[berezovskyi]

Now that I read the shape definition and https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/String.html#length(), I am not so sure this PR is a great idea (though not immediately against it).

oslc:maxSize property was designed to limit string length of RDF properties. In Java, https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/String.html#length() is an int32. What is important is that int and long are comparable directly in Java, but BigInteger cannot be directly compared to int or long. This means that to use that field for its original purpose, we'd always have to do:

try {
   if (getSomeValue().length() > getMaxSize().intValueExact()) {
      new OslcError(":someValue string exceeds oslc:maxSize");
   }
} catch (ArithmeticException e) {
   new OslcError("oslc:maxSize=%s exceeds max JVM String length".formatted(getMaxSize()));
}

instead of just doing

if (getSomeValue().length() > getMaxSize()) {
   new OslcError(":someValue string exceeds oslc:maxSize"); 
}

The only benefit to this this approach is to be able to catch the ArithmeticException cleanly when downcasting BigInteger to an int32 and produce a corresponding OSLC Error resource.

[berezovskyi]

The TRS BigInteger change was made in Lyo 5.0: https://github.com/eclipse/lyo/blob/master/CHANGELOG.md#changed-2

[Jad-el-khoury]

Given the purpose of maxSize, it there is little motivation to change to BigInteger then. Just close this PR?

[berezovskyi]

The problem is that right now Lyo is non-conformant to the OSLC Core spec (2.0+), which requires a valid implementation to accept xsd:integer, which in Java requires a BigInteger. But I agree on the motivation (or, rather, lack of it).

[Jad-el-khoury]

I see. Maybe we the "Literal Value Types" need to be extended in the specs to also include xsd:int or xsd:long.

How about we wait until a decision is settled on oslc-op/oslc-specs#595, before moving on this PR?

[sonarcloud]

Quality Gate passed

Issues
0 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 SonarCloud

[sonarcloud]

Quality Gate passed

Issues
0 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 SonarCloud

[sonarcloud]

Quality Gate passed

Issues
0 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 SonarCloud

[berezovskyi]

Pulled from my old notes:

1. Keep oslc:maxSize as in the POJO, because both in the spec and Lyo it semantically means the length of the string and in many systems string length is an int (for sure in Java and C#).
2. Keep oslc_trs:order a BigInteger in the POJO, to match the spec and especially to support cases like the use of UUIDv7 as TRS event identifiers / order numbers.
3. Generate oslc_trs:order using an AtomicLong in TRS Server. Rationale: will exceed the limit with 5B events/s for 50y. Also, easy to replace later with Redis INCR or Hazelcast IAtomicLong implementation later for the distributed case.