Add API support for Semeru "Editions"

[AdamBrousseau]

Is your feature request related to a problem? Please describe.
IBM Has released 2 versions of the Semeru Runtimes, Open Edition and Certified Edition. Open Edition is released under the standard GPL v2 +CE License and Certified Edition is released under IBM Commercial License. We would like to have both versions be available via the API.

Describe the solution you'd like
My initial thought is to add a "filter" or parameter similar to heap_size called edition. Initially it would likely have 3 values, default for all non-Semeru builds, open and certified. This parameter could likely be reused in the future if needed by another variant or vendor.

Describe alternatives you've considered
I also thought about using license filter since the 2 editions are released under different licenses, but I think I like edition more.

Additional context
https://developer.ibm.com/languages/java/semeru-runtimes/downloads?license=GPL
https://developer.ibm.com/languages/java/semeru-runtimes/downloads?license=IBM

[AdamBrousseau]

@johnoliver looking for feedback please.

I have started down the path of copying from the heap_size code. I assume I'll need to add some metadata to the build json too.

[johnoliver]

To be clear here, I assume what you are asking is that we add support for this usecase in our api so that you can take advantage of it, but not that the Adoptium(or adoptopenjdk) API actually distribute these commercial binaries?

So thinking forward to how we can allow for more freedom for others to extend our API and add additional fields easily. The complexity here is to add a new field we need to:

1. Add that field to the appropriate model (i.e add Binary.license)
2. Add parameters to the appropriate endpoints
3. Update filters to allow filtering Releases/Binaries based on parameters given to an endpoint

RE issue 1.. To some extent is already supported as we allow in the build logic to switch between models, this is how we have a different implementation of Vendor between adoptopenjdk and adoptium.

RE issue 3..I am not 100% how I would do it right now, this is a bit more complex as the current logic (at https://github.com/adoptium/api.adoptium.net/blob/main/adoptopenjdk-frontend-parent/adoptopenjdk-api-v3-frontend/src/main/kotlin/net/adoptopenjdk/api/v3/filters/BinaryFilter.kt#L41) does rely on knowing what fields are required up front, however I believe there could be some way around this, possibly using something like Binary::class.memberProperties rather than explicitly listing them, then if you add something to Binary it will be picked up.

RE issue 2...This is actually the difficult one, we have a fair few endpoints and adding a mechanism to allow you to add arbitrary parameters to them would not be easy. Thoughts here would be, you could have a total free form map of values i.e something like "tags" that you could add. I.e:

• add to Binary: private val tags: List<String>
• Add parameter to the endpoints a parameter that takes "tags" to include
  You could then add the tag of commercial.

The tag route would allow you total freedom to add anything you like. However the main drawback is it would be almost totally undocumented when looking at the swagger-ui/openapi and you would have to manually document in your openapi what tags are available. A possibility is we type the tags i.e tags:List<Tag>, you can then in your own distribution easily implement your own Tag list, and this would get documented on openapi. The main drawback with that being you will have to make sure the API knows all tags that need to exist otherwise they will be ignored. This idea may be somewhat similar to your "filter" idea just with the name "tag". It could be possible

[AdamBrousseau]

Another possibility we thought of was to add 2 vendors. ibm_oe and ibm_ce for Open Edition and Certified Edition respectively. We thought that even though it may not be the most correct solution, it could be the least disruptive option for users of both Adoptium and OpenJ9/Semeru. @johnoliver what are your thoughts on this vs what you proposed?

edit:

add support for this usecase in our api so that you can take advantage of it, but not that the Adoptium(or adoptopenjdk) API actually distribute these commercial binaries?

Correct.

[AdamBrousseau]

Since this was closed (which is fine), I'll provide an update on what we did with the Semeru API. We ended up implementing using the multiple vendor method I mentioned in my last comment. Users can continue to use the same queries as they were before and simply update the vendor to ibm for Open Edition and ibm_ce for Certified Edition.

[tushev]

@AdamBrousseau Could you please provide an API for this?

I checked https://api.adoptium.net/q/swagger-ui/#/Assets/getLatestAssets but there's only eclipse there as vendor. Also tried https://api.adoptium.net/v3/assets/latest/17/hotspot?vendor=ibm , not works.

[AdamBrousseau]

@tushev the IBM Semeru Runtimes API is hosted at https://ibm.com/semeru-runtimes/api/v3
We have not yet had an official launch so there is no public doc yet. It is a fork of Adoptium's so it should be the same schema other than the ibm and ibm_ce vendors.

[krismarc]

Hi, is it live/public? Where I could actually fetch versions info and their download urls?

It redirects to https://developer.ibm.com/languages/java/semeru-runtimes/api/v3 and never responses.

[krismarc]

Ah, it's all described here :)
https://www.ibm.com/support/pages/semeru-runtimes-getting-started