Bug ID: JDK-8256863 Several java/foreign tests fail on x86

Type: CSR
Component: tools
Sub-Component: jextract

Priority: P3
Status: Closed
Resolution: Approved
Fix Versions: 16

Submitted: 2020-11-23
Updated: 2020-11-25
Resolved: 2020-11-25

Summary
-------

Specify what happens on unsupported platforms when using the foreign linker (`CLinker`) API.

Problem
-------

The behavihour of `jdk.incubator.foreign.CLinker` on unsupported platforms is currently unspecified.

Solution
--------

Specify that class initialization of CLinker on unsupported platforms will fail.

Specification
-------------
```
diff --git a/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java b/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java
index 0c29f115aa6..d9b53c742e6 100644
--- a/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java
+++ b/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java
@@ -94,6 +94,8 @@
  * {@link #asVarArg(MemoryLayout)} is used to create the memory layouts for each parameter corresponding to a variadic
  * argument in a specialized function descriptor.
  *
+ * <p>On unsupported platforms this class will fail to initialize with an {@link ExceptionInInitializerError}.
+ *
  * @apiNote In the future, if the Java language permits, {@link CLinker}
  * may become a {@code sealed} interface, which would prohibit subclassing except by
  * explicitly permitted types.
```

Moving to Approved.
25-11-2020
I've changed the statement to be normative and added the specific exception that is thrown as well.
25-11-2020
Providing a dummy CLinker implementation is not really possible since we have several static final MemoryLayout fields that need to be filled in based on the current platform. We are currently throwing an ExceptionInInitializerError for unknown platforms: https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java#L47 After some discussion with Maurizio, we thought that rather than trying to handle unsupported platforms by throwing an UnsupportedOperationException from a handful of static methods and putting some kind of default value in the static final fields, it would be okay if the class failed to initialize in the way it currently does.
24-11-2020
Moving to Provisional. The clause "Note that..." typically indicate an informative statement rather than a normative one. In that case, I believe you want to make a normative statement that "the class will fail to initialize" on unsupported platforms. I suggest specifying some particular way an unsupported platform would be manifested in terms of (existing) exceptions thrown or other behavior, dummy CLinker that throws "UnsupportedOperation" for every method, etc.
24-11-2020
[~psandoz] - while we can mention the type of exception being issues, I'm not sure we'd want to add a _new_ exception type just for this. Note that, to some extent, the problem of platforms which do not support a linker implementation is a transient one. Of course, now that the API is merely an incubating API, many platform might decide to wait - but when the API will eventually land as a SE API, then I think there will be less room for an OpenJDK implementation not to have a foreign linker implementation. For this reason, I'd prefer avoid dedicating too much API surface to this specific issue.
23-11-2020
Is there any specific exception worth mentioning as to the cause of the initialization error?
23-11-2020