סוגי נתונים

בהינתן קובץ ממשק HIDL, הקצה האחורי של Java HIDL מייצר ממשקי Java, Stub וקוד Proxy. הוא תומך בכל סוגי ה-HIDL הסקלאריים ([ u ] int { 8,16,32,64}_t, float, double, ו- enum s), כמו גם מחרוזות, ממשקים, סוגי safe_union, סוגי struct ומערכים ווקטורים של נתמכים סוגי HIDL. הקצה האחורי של Java HIDL אינו תומך בסוגי איחוד או סוגי fmq . אנדרואיד 11 מוסיפה תמיכה בסוגי memory handle .

מכיוון שזמן הריצה של Java אינו תומך במושג של מספרים שלמים לא חתומים באופן מקורי, כל הטיפוסים הלא חתומים (והמנופים המבוססים עליהם) מטופלים בשקט כמקבילים החתומים שלהם, כלומר uint32_t הופך ל- int בממשק Java. לא מתבצעת המרת ערך; המיישם בצד Java חייב להשתמש בערכים החתומים כאילו הם לא חתומים.

תקצירים

Enums אינם יוצרים מחלקות Java enum אלא מתורגמים למחלקות פנימיות המכילות הגדרה קבועה סטטית עבור כל מקרה enum. אם מחלקת ה-enum נובעת ממחלקת enum אחרת, היא יורשת את סוג האחסון של המחלקה הזו. ספירות המבוססות על סוג מספר שלם ללא סימן נכתבות מחדש למקבילה החתומה שלהן. מכיוון שהטיפוס הבסיסי הוא פרימיטיבי, ערך ברירת המחדל עבור שדות/משתנים של enum הוא אפס גם כאשר אין מונה אפס.

לדוגמה, SomeBaseEnum עם סוג של uint8_t :

enum SomeBaseEnum : uint8_t { foo = 3 };
enum SomeEnum : SomeBaseEnum {
    quux = 33,
    goober = 127
};

… הופך ל:

public final class SomeBaseEnum { public static final byte foo = 3; }
public final class SomeEnum {
    public static final byte foo = 3;
    public static final byte quux = 33;
    public static final byte goober = 127;
}

וגם:

enum SomeEnum : uint8_t {
    FIRST_CASE = 10,
    SECOND_CASE = 192
};

… נכתב מחדש כ:

public final class SomeEnum {
    static public final byte FIRST_CASE  = 10;  // no change
    static public final byte SECOND_CASE = -64;
}

מחרוזות

String ב-Java הן utf-8 או utf-16 אך מומרות ל-utf-8 כסוג ה-HIDL הנפוץ בעת העברה. בנוסף, אסור String להיות null כשהיא מועברת ל-HIDL.

ידית וזיכרון

אנדרואיד 11 מציגה תמיכה ב-Java עבור סוגי handle memory . הם מתורגמים ל- android.os.NativeHandle ו- android.os.HidlMemory , בהתאמה. ידית אפס נחשבת חוקית, בעוד שזיכרון ריק לא.

בקוד השרת שנוצר, ארגומנטים של הזיכרון והטיפול שהתקבלו תקפים רק בטווח של הפקת השיטה. אם יישום השרת רוצה להאריך את חייו, יש לשכפל אותם באמצעות שיטות dup() הספציפיות שלהם. ניתן להשתמש במופע המוחזר מעבר להפעלת השיטה ויש לסגור אותו כראוי כשמסיימים איתו.

בקוד הלקוח שנוצר, אין צורך לשכפל או לשמור על תקפות פעולות ומופעי זיכרון שנשלחים כארגומנטים קלט של המתודה הנקראת לאחר החזרת השיטה. עם זאת, ידיות ומופעי זיכרון המתקבלים כארגומנטים של פלט משוכפלים אוטומטית על ידי הקוד שנוצר אוטומטית וחייבים להיסגר כהלכה בסיום. זה נכון בין אם ארגומנטים ההחזרה הללו מופיעים כערכי החזרה של השיטה (במקרה של ערך החזרה בודד) או באמצעות סגנון החזרה סינכרוני (המשמש במקרה של ערכי החזרה מרובים).

למידע נוסף על שכפול וסגירה, עיין בתיעוד של מחלקות Java.

מערכים ווקטורים

מערכים מתורגמים למערכים של Java ווקטורים מתורגמים ל- ArrayList<T> כאשר T הוא סוג האובייקט המתאים, אולי עוטף סוגים סקלרים כגון vec<int32_t> => ArrayList<Integer> ). לדוגמה:

takeAnArray(int32_t[3] array);
returnAVector() generates (vec<int32_t> result);

… הופך ל:

void takeAnArray(int[] array);
ArrayList<Integer> returnAVector();

מבנים

מבנים מתורגמים לשיעורי Java עם פריסה דומה. לדוגמה:

struct Bar {
 vec<bool> someBools;
};
struct Foo {
 int32_t a;
 int8_t b;
 float[10] c;
 Bar d;
};

… הופך ל:

class Bar {
 public final ArrayList<Boolean> someBools = new ArrayList();
};
class Foo {
 public int a;
 public byte b;
 public final float[] c = new float[10];
 public final Bar d = new Bar();
}

סוגים מוצהרים

כל סוג ברמה עליונה המוצהר ב- types.hal מקבל קובץ פלט .java משלו (כפי שנדרש על ידי Java). לדוגמה, קובץ types.hal הבא מביא ליצירת שני קבצים נוספים (Foo.java ו-Bar.java):

struct Foo {
 ...
};

struct Bar {
 ...

 struct Baz {
 };

 ...
};

ההגדרה של Baz חיה במעמד פנימי סטטי של בר (ב-Bar.java).