abapLanguageVersion

[larshp]

The field abapLanguageVersion is really difficult

In other programming languages, the actual version of the language is rarely(?) part of the actual source code. Instead the author states the version requirements in a README (I'm thinking about Java/JavaScript/TypeScript/C++)

There is also "integrated Steampunk" which will be out sometime and do something 😄 Will a 5 year old integrated steampunk have the same languageversion as the latest cloud steampunk? I'm afraid that the list will keep increasing over time unless the purpose of the field is defined very clearly.

[schneidermic0]

I don't see a way, how we could change the behaviour of the ABAP language version. It is stored per object and indicates which syntax can be used for the object.

But maybe, I did not get your point.

[larshp]

Say, I develop a CLAS on my local ABAP dev edition, serialize it, it gives language = standardUnicode

I then import the CLAS into steampunk, serialize it, now the language becomes cloudDevelopment(?)

After this, it will be impossible(?) for me to continue developing the object in my local ABAP dev edition, as it does not support language cloudDevelopment, even though the actual ABAP code is identical

stored, yea, its also something to consider, but IMHO first priority is having clean files

[schneidermic0]

I see your point. However, I still think the ABAP language version is a property of a particular object which, therefore, should also be part of the object content.
I don't see (with the current implementation of the ABAP language version) any other way to calculate the value.

BTW: In new versions of on-premise systems, ABAP language version = cloudDevelopment is allowed.
In lower releases, I agree, it can only be set to standard. :(

[larshp]

Say there is one package with 2 CLAS'es, one with version cloudDevelopment and one with standard, would it work?

Does cloudDevelopment check the API allow list, or does it behave different in on-prem systems?

The setting could be on package level and inherited, set on global level in the repository(allowing users to override), or a local repository setting. 🤷‍♂️

And I guess if its exported from Steampunk cloudDevelopment, it does not necessarily import into an older on-prem cloudDevelopment ?

[schneidermic0]

Say there is one package with 2 CLAS'es, one with version cloudDevelopment and one with standard, would it work?

Yes

Does cloudDevelopment check the API allow list, or does it behave different in on-prem systems?

It will consider the API allow list which is available in the on-premise system.

The setting could be on package level and inherited, set on global level in the repository(allowing users to override), or a local repository setting. 🤷‍♂️

Actually, in the latest release, there is an option to specify the default ABAP language version on package level. Still, at least - as of now - the ABAP language version is a property of the specific object.

And I guess if its exported from Steampunk cloudDevelopment, it does not necessarily import into an older on-prem cloudDevelopment ?

Here, we have to define a behaviour. If nobody has a better idea I suggest to set the value to standard if ABAP language version does not support cloudDevelopment.

[larshp]

Okay, one step back

As I see it, we are designing file formats, which in most(all?) cases do not equal the actual data stored in a SAP ABAP system. Ie. tooling must be built to take care of serializing and deserializing data.

This opens for a very large range of design choices.

One of the goals, IMHO, is to make it easy for developers to move code between systems on various releases and platforms. I don't know the exact semantics for the abapLanguageVersion field, but it feels like it can cause some trouble if following how its stored currently.

And that might be okay, just have to be aware what the limitations are, and the design goals.

[larshp]

Its the circle of life 🐅 🌞

Some customers will move their code to Steampunk
Some from Steampunk to integrated Steampunk
Some from integrated Steampunk to on-prem
Some from on-prem to serverless ABAP
(^probably missed a few scenarios)

Comparing with other languages, the above is just the runtime, and assuming the syntax and APIs exists, then something like JavaScript can move verbatim between runtimes. Much like some javascript runs in the browser, some run on node, sometimes on both.

[esjewett]

I'd agree. I don't know of any other language that stores language version information at the file/object level. When no one does it, I start to think maybe that's because it's a bad idea. 😂 I don't see how this will play out when I am collaborating on a class with 10 other collaborators in 10 other systems. Some on Steampunk, some on 7.31, some on 7.54, some running the code and tests on Node.js using abapLint's interpreter. What abapLanguageVersion would this code have?

[xtough]

I don't see how this will play out when I am collaborating on a class with 10 other collaborators in 10 other systems. Some on Steampunk, some on 7.31, some on 7.54, some running the code and tests on Node.js using abapLint's interpreter. What abapLanguageVersion would this code have?

I like concrete examples. In that particular case, the abapLanguage version would also have to be the least common denominator, i.e., 7.31. If you would use newer language features, the code simply would not run on the older platforms.

Talking about other languages: In node.js or Java you would have some sort of a component model in place, which defines which language version is commonly used for all sources in that component. Alas, in ABAP we don't have such a component model yet. APACK is the nearest thing to it that comes to my mind.

[esjewett]

@xtough Is it actually possible to identify a least-common denominator? I thought there were quite a few 7.31 language constructs that have been removed in Steampunk. I think you'd have to specify a list of supported language versions, just as JavaScript projects will specify a list of supported Node versions in their package.json files.

[larshp]

take https://github.com/sbcgua/abap-string-map as an example, it can run most likely run on anything 702+, see https://abaplint.app/stats/sbcgua/abap-string-map/statement_compatibility

if its the least common denominator, then there is no field to store this in a ABAP AS(which is okay)

SAP uses the REPOSRC-UCCHECK field to enable and disable different features in the syntax check(?), eg on Steampunk for customer objects(Z*) its set to something(don't remember the value, and I don't have access to check it)

in NodeJS the javascript files does not contain any information about the runtime, but in package.json its possible to define a engine version

[xtough]

in NodeJS the javascript files does not contain any information about the runtime, but in package.json its possible to define a engine version

This is exactly what I meant with my reference to APACK: If we had an established component model in ABAP, we could define the required target environment there. But until then, we need to store the minimum language version either with every object or somewhere out of band.

Maybe the problem could be mitigated if all participating development systems would honor this least common denominator as originally written in the file and not increase it upon first change. But I see that this would be hard to accomplish in ABAP because AFAIK I could not configure a Steampunk system to write 702 code. Whereas in Java, I could still use Java11 to write and compile and run Java 1.6 code...

[esjewett]

Again though, I don't believe that ABAP has a concept of a least-common-denominator language version. That is to say, I think that every version has syntax that is not supported in another version.

I think the "proper" solution will be for the language version field to support multiple values to indicate that the object uses language features that are only in the intersection of the listed versions, which I doubt the ABAP runtime supports. Without that, and as currently implemented, abapLanguageVersion means semantically "This will run on this runtime and may or may not run on other runtimes".

[schneidermic0]

I agree, the ABAP language version does not specify which releases (like 7.02, 7.50, 7.55) are supported. I don't know any location where this can be specified in ABAP. Therefore, we cannot use it whether software will run on a specific release.

With the ABAP language version, it is "just" possible to specify which language elements and which external objects you can use in you development object. (for details refer to the ABAP keyword documentation; for other object types like data dictionary the behaviour is the same).

The ABAP language version ABAP for Cloud Development is basically a subset of standard ABAP. Certain statements are not allowed any you can only use objects in your own software component or other objects which are released.

[larshp]

A: What should happen if an object is installed into a system that does not support the language version specified in the file
Example: I develop a framework in Steampunk, I'd like to reuse it on-prem

B: What should happen if an object is installed into a system that only supports a different language version than specified in the file
Example: I develop a framework on-prem, I'd like to reuse it in Steampunk

For both examples, it would be nice if development of the framework in the other system without git diffs. From a developer perspective, its the same object, but the runtime changes. Like running a Java file on different JVMs does not cause the source Java file to change.

Depending on the scope, #86, we can consider the language version to be "transport process metadata", and specified on clone/installation locally by the developer instead of persisted in each object file.

Example: abapGit in Steampunk pulls a file, as it knows its steampunk it always sets the language version to ABAP for Cloud Development(I guess it already does this today?)

I don't know the design decisions for Embedded/Integrated Steampunk on-prem, will it be possible to have a mix of different ABAP language version objects call each other? What will the separation be?

[schneidermic0]

Maybe, let me first add some more general information about the ABAP language version to this issue:

As mentioned before the ABAP language version is a property of an object to restrict ABAP (syntax-wise and which other objects can be used/called). It can be set by the user per object in on-premise releases. To see how it is used today, you might want to refer to the following blogs:

• https://blogs.sap.com/2020/07/23/restricted-abap-and-sap-s-4hana-on-premise/
• https://blogs.sap.com/2020/06/03/restricted-abap-for-sap-cloud-platform-abap-environment/

Since it is a property that can be potentially changed by the user per object, I think we have to keep it as a property in the file formats. For me it is no data related to the deployment only, because it also specifies whether the restricted ABAP shall be used or not (for sure if it is supported in a specific release).

Let's see what this could mean to some of your questions:

B: What should happen if an object is installed into a system that only supports a different language version than specified in the file
Example: I develop a framework on-prem, I'd like to reuse it in Steampunk

In Steampunk, all custom code will be set to ABAP language version cloudDevelopment for each object. This is, how it is implemented, today. I don't expect it to be changed.

A: What should happen if an object is installed into a system that does not support the language version specified in the file
Example: I develop a framework in Steampunk, I'd like to reuse it on-prem

I agree we need a solution for this, because we cannot use the ABAP language version in old on-premise releases. Maybe, the following could be a solution for this:

• If the ABAP language version existed in the on-premise system, I would keep it. This means, I can continue to develop with the same rules I have to consider in cloud development and you can keep on developing "cloud-compatible". Still, you might face issues, because in Steampunk more APIs are already released than in your actual on-premise system. This is basically the same as I would use a functionality which does not exist in the lower release.
• If the language version did not exist in the on-premise system, I would set it to default. You can use it there, but you might get syntax-errors if you use it again in Steampunk, because you used another API in on-premise which is not released in the cloud.

For both examples, it would be nice if development of the framework in the other system without git diffs. From a developer perspective, its the same object, but the runtime changes. Like running a Java file on different JVMs does not cause the source Java file to change.

Yes, I can understand your use case from a developer perspective of an abapGit repository. I understand you want to mark a whole development project (let's say a whole repository created by abapGit) with a specific ABAP Language Version.

I am wondering whether this cannot still be added (e.g., by abapGit) so that it is possible to specify which ABAP language version shall be set during serialization of the files for a specific repository. During import/deserialization it would behave as I mentioned it in my answers to your questions A and B.

Even if this were not the simplest solution for your use case (but we have to keep other use cases in mind, too), wouldn't this cover also your use case?

[esjewett]

Would there be any downside to ABAPGit just deserializing to default language version everywhere, as an example?

[larshp]

I'm thinking of having abapGit serializing it to empty(not having it in the json file), always ignore what is in the system

with a possibility of setting it as a local setting per repository

[schneidermic0]

Would there be any downside to ABAPGit just deserializing to default language version everywhere, as an example?

I see following potential disadvantage: In on-premise systems, in which ABAP language version is supported (and only there), the user might have set the ABAP language version to restrict so that the code can be used in the cloud. If abapGit would not consider this during deserialization, he might use statements or objects which are not allowed to be used in the cloud.

[larshp]

I see that as a problem to be tackled in CI.

Example: abapGit is targeted for 702, if someone suggests a change with syntax that is not compatible with 702 it gives an error, and the change cannot be merged.

[schneidermic0]

I see that as a problem to be tackled in CI.

OK, I see. I was just writing down my question how you would handle the local setting in the repository. ;)
Now, I understand that you want to check the restricted ABAP statements and the released objects within the repository.

[schneidermic0]

I'm thinking of having abapGit serializing it to empty(not having it in the json file), always ignore what is in the system

I will check with the team, whether we don't serialize abapLanguageVersion (in our implementation, which is used by ADT and planned to be used by gCTS in the future) when it is set to standard.

[larshp]

Assuming embedded steampunk is released to on-prem sometime, then abapLanguageVersion = cloud will not be enough anyhow, as allowed/released statements/objects will(?) differ between versions.

Someone developing a library in embedded steampunk version on-prem 9999, might not be compatible with embedded steampunk version 8888

Something like https://abaplint.app/stats/cavabap/batch-input-helper/statement_compatibility will be the solution, check against all versions to determine if its compatible

[schneidermic0]

Assuming embedded steampunk is released to on-prem sometime, then abapLanguageVersion = cloud will not be enough anyhow, as allowed/released statements/objects will(?) differ between versions.

Yes, you are right this is the same as some objects or statements do not exist in old releases. Therefore, they differ in on-premise releases.

[larshp]

If we change abapLanguageVersion to always be optional, then I think it will work for abapGit

[schneidermic0]

OK, I will check it with the team.

[schneidermic0]

I have talked to the team.

Our suggestion is: abapLanguageVersion is optional in the file formats. We specify a default value standard. I.e., If abapLanguageVersion is not specified in the file, the version stored in a repository will be considered as "abapLanguageVersion": "standard" which is the same as the default.

During serialization, implementations can decide whether thy specify it or not.

During deserialization, ABAP systems might change the ABAP language version to the value needed in this context.

Examples

• The ABAP language version will be set to cloudDevelopment in cloud ABAP systems (aka Steampunk).
• The ABAP language version might be set to standard if the system does not support the specified value, yet (e.g. in a lower release)

[larshp]

👍

not specified: its deserialization/system dependent. We should not document that it is considered as "standard", then all files where its not specified will not be cloud compatible, by "not specified is standard" definition, even though they might be

[larshp]

Suggest the following tasks,

• Update documentation
• Adopt CHKC
• Adopt CHKO
• Adopt CHKV
• Adopt CLAS
• Adopt ENHS
• Adopt FUGR
• Adopt INTF
• Adopt NROB

[larshp]

example = abapGit/abapGit#5921, code developed in Steampunk, importing in 740/750 systems