Signals with struct type parameters generate invalid Java

[zugaldia]

When generating Java code with InterfaceCodeGenerator version 5.2.0 on the https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.GlobalShortcuts.xml file, the following signal produces incorrect code:

<signal name="ShortcutsChanged">
  <arg type="o" name="session_handle" direction="out"/>
  <annotation name="org.qtproject.QtDBus.QtTypeName.Out1" value="QList&lt;QPair&lt;QString,QVariantMap&gt;&gt;"/>
  <arg type="a(sa{sv})" name="shortcuts" direction="out"/>
</signal>

Problematic generated code:

public static class ShortcutsChanged extends DBusSignal {

    private final DBusPath sessionHandle;
    private final List<org.freedesktop.dbus.Struct<String>, Map<String, Variant<?>>> shortcuts;

    public ShortcutsChanged(String path, DBusPath sessionHandle, List<org.freedesktop.dbus.Struct<String>, Map<String, Variant<?>>> shortcuts) throws DBusException {
            super(path, sessionHandle, shortcuts);        this.sessionHandle = sessionHandle;
            this.shortcuts = shortcuts;
    }

    public DBusPath getSessionHandle() {
        return sessionHandle;
    }

    public List<org.freedesktop.dbus.Struct<String>, Map<String, Variant<?>>> getShortcuts() {
        return shortcuts;
    }

}

Build error:

Execution failed for task ':sdk:compileJava'.
> Compilation failed; see the compiler output below.
  /[redacted]/stargate/sdk/src/main/generated/org/freedesktop/portal/GlobalShortcuts.java:98: error: type Struct does not take parameters
          private final List<org.freedesktop.dbus.Struct<String>, Map<String, Variant<?>>> shortcuts;
                                                        ^

I believe the same type of error happens with https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.Usb.xml in DeviceEvents.

The exact setup can be seen here (Stargate is a Kotlin library that provides JVM applications with access to XDG Desktop Portals on Linux).

I've seen other generation errors with other XDG Portals related XML files. Opening separate tickets for easier tracking. Related: #302 and #303.

[hypfvieh]

This issue and also #302 and #303 should be fixed in next 6.0.0 Snapshot.

[zugaldia]

Great, thank you for the quick response! Are you publishing v6 releases or snapshots somewhere that I could use to retest? Maybe I missed it but I don't see anything on the README.

[hypfvieh]

6.0.0-SNAPSHOT is automatically deployed to Sonatype Snapshot Repository as soon as the build/test action was successfully performed by Github Actions.

A release of 6.0.0 is not planned yet. If required I may take a look backporting the changes to 5.x if I have some more spare time doing so.

[zugaldia]

Understood. I just re-tested with the latest snapshot and I can confirm that #302, #303, and #304 are now resolved and the code correctly builds for all portals 🎉

The bad news is that I encountered a different small issue on a separate portal (Notifications). I opened a ticket here: #306.

For a final release we would indeed need a stable 6.0 release but this is not urgent on my side (is there a rough timeline?). I can test meanwhile with snapshots.

[hypfvieh]

I don't have a real time line. Version 6 is the newst iteration and requires a more recent Java which may causes problems for some projects. The earliest date-range would be end of summer or fall this year - but it can also be later.

I think I should take some more time to give the InterfaceCodeGenerator a bigger update. The code is a mess, contains duplicated code and definitely needs some attention and clean-up. I'm pretty busy currently so I don't know when I'm able to invest the required time to do so.

[zugaldia]

Understood. For Stargate in particular, I believe I found a path forward that lets me take advantage of the V6 code generation fixes while still using V5 for the public API zugaldia/stargate#21. Essentially I only use V6 for code generation with avoidUsingTuple = false. As far as I can tell, the generated code this way is compatible with V5. (I understand this is not ideal, and there might be other changes in the V6 generator in the future that might not be compatible with V5. But for now, I'm committing the generated code so I have some control over future V6 updates.)

[zugaldia]

Ah, just one small issue. The v6 generator creates getVersion instead of getversion but then the code would fail at runtime (DBusExecutionException: No such property “Version”). The fix I believe is straightforward, adding @DBusBoundProperty(name = "version") to those methods.

[hypfvieh]

I refactored the InterfaceCodeGenerator code and added some more tests. It would be great if you can check if this version still has any of your reported issues or has introduced any new issues

[zugaldia]

@hypfvieh I just opened a PR zugaldia/stargate#27 and regenerated the bindings using the latest snapshot. That should give you a good sense of the full differences I'm seeing. The build passes, but it still fails at runtime. Looks like in this latest version, the full @DBusBoundProperty(name = "version") is still missing.

[hypfvieh]

@zugaldia thanks a lot. I checked you changes and saw some issues with indention and with creation of Tuples as well.
I also fixed the missing "name" attribute in DBusBoundProperty annotation if needed (which is only the case, if property name is different than method name without get/is/set prefix).

Would be great if you can re-generate your classes.
I guess that there should only be changes in Tuple classes. The setter Methods arguments now have a better name instead of arg and the field name in setters are prefixed with this. to avoid clashes with argument names.

[zugaldia]

@hypfvieh I did 1 more regeneration of the Java bindings now with a10c08c in zugaldia/stargate@23f52cb. I can confirm I see the @DBusBoundProperty annotation now (you will not see it in the PR diff because this is something I manually added). The build passes and I'm able to run the demo app with no apparent issues.