I keep thinking about this from an overall project perspective, it is a bit random to bless a few types, but yes this one would work kinda well...

@ktoso Hm, imo this project exists to provide a seamless Swift/Java interop story. Since we are generating Java code meant to be used on Java platforms, perhaps also by Java developers, I think it makes sense to bridge any matching types, such as UUID, Date,URL etc...

The alternative is that the developer has to use a generated type Swift.Date like we do for Data in FFM. That will probably often (for these kind of "utility" types") result in the developer having to convert their Java types to the Swift wrapped types. I understand why it makes sense for Data because of memory copying etc, but not sure that its the same motivation for the above types.

Hm, imo this project exists to provide a seamless Swift/Java interop story.

Primarily it must be: correct, safe, and then seamless. We must not sacrifice correctness just because it's convenient. The conversion is lossy, and could result in bugs in practice, e.g. if you're trying to key anything off the date.

Such echo function showcases how this is a lossy conversion:

import Foundation

public func echoDate(_ date: Date) -> Date {
  return date
}

and in Java + jextracted Date-as-Instant:

        Instant now = Instant.now();
        Instant back = MySwiftLibrary.echoDate(now);

        if (!now.equals(back)) {
            System.out.println("NOT EQUAL! " + now + " != " + back);
        } else {
            System.out.println("EQUAL");
        }

gives:

NOT EQUAL! 2026-01-14T05:45:55.764682Z != 2026-01-14T05:45:55.764682054Z
DONE.

That's not something we should be just doing by default.

Instead I propose:

• import Foundation.Date as a wrapped type, same as we do Data
• add a method on it called Instant toJavaInstant() which performs the conversion so people don't have to do it manually.

Sounds good?