[SPIKE] Investigate supporting Java 8

[skeet70]

Java 8 seems to be the common target for libraries. We're currently using Java 20+ features in our generated code. Investigate and report here on what features we'd need to lose, what can be polyfilled, and what functionality we would lose.

Discuss the tradeoffs, create tickets if we decide to support it.

[BobWall23]

Could figure out the effort to support back to Java 17 - that is likely to be a problem because we are using Records, and they are new after 17. If we can get to 17, getting back to 11 or 8 is probably not too difficult.

[gtrak]

Curious if you have some more details about the compatibility, since I'd really like to use uniffi in my JVM project, but would like to avoid the kotlin runtime dependency.

What are all the features this uses that require > java 8?

Is it possible to target java 8 by just selectively not using those features?

Are they bytecode compatibility limitations, or source level like specific API availability?

[skeet70]

What are all the features this uses that require > java 8?

None of the current users use Java 8 and don't really have a desire to. This spike was to investigate it at a surface level to see if it'd be an easy thing to do, but I doubt it is. I don't have a list of all the features this uses that requires > Java 8. I know we use record and I'm pretty sure we're using record patterns as well.

Is it possible to target java 8 by just selectively not using those features?

I don't know, but you could try and post in this issue if it is!

Are they bytecode compatibility limitations, or source level like specific API availability?

As far as I'm aware they're source level. It's quite likely that since performance is important in our use case, as part of #25 that we'd use Project Panama/JEP 424 which was stabilized in Java 22 in a future version of the library.

Feel free to take on this SPIKE if you'd like and

Investigate and report here on what features we'd need to lose, what can be polyfilled, and what functionality we would lose.

Even if we're likely headed to Java 22 in the future, you could always fork this with a Java 8 version if you desired.

[mainrs]

Even if we're likely headed to Java 22 in the future, you could always fork this with a Java 8 version if you desired.

Does it make sense to provide a common API via interfaces or the like to provide both the Java 8 and Java 17/22 generators? I require Java 6/8 and 17 support for my project. Therefore, I have to write the generators anyway. Maybe we can work together and define a common layer that one can implement for the specific Java version.

[gtrak]

My usage has evolved, I both need to support down to java 8 (for basic stuff like records) and to integrate with async rust and virtual threads (JDK 21+), ideally with the same artifact. So far, I've been sticking to the kotlin generator and hand-rolling more components than I would like.

I am thinking about whether I should try to make it work with the java generator, which probably requires adding some templates, config flags (eg passing a virtual threads executor into the CompleteableFuture parts), but haven't gotten around to trying it yet.

[skeet70]

Even if we're likely headed to Java 22 in the future, you could always fork this with a Java 8 version if you desired.

Does it make sense to provide a common API via interfaces or the like to provide both the Java 8 and Java 17/22 generators? I require Java 6/8 and 17 support for my project. Therefore, I have to write the generators anyway. Maybe we can work together and define a common layer that one can implement for the specific Java version.

@mainrs I'd still like whatever version the library directly supports to be the default case that doesn't require work from a library consumer.

I could see an optional config value for the Java version that switches to predefined template overrides/alternatives for that version, where necessary? We'd need good integration/unit test coverage, I could see issues with updates to a template breaking its compatibility with older Java versions that previously didn't need changes, as well as duplicating changes when adding features to the default code.

Anything to reduce the maintenance load of adding those different templates would be good to include in a PR for it, updates to this library already require a decent amount of effort as is (particularly reloading the context of working in it).