Closed szabado-faire closed 6 months ago
An alternative is just updating to all
. That'll only break any users of tempest that are on Java 7; aws has dropped support for Java 6
Java 7 has entered EOL and no longer gets security updates, so it's probably fine to drop support for
Increasing compatibility on the library is probably the right move, but as the note says
This usually means that you need a proper library versioning, for example, major version increase in SemVer.
Unfortunately tempest does not use SemVer, so the only way to release a major version is to create a tempest3
version. This would also require that we introduce separate build steps for each version.
Or we could release as-is and be ready to rollback... I hate our versioning strategy. I would much rather be on SemVer.
Or we could release as-is and be ready to rollback...
I think this is probably the easiest path forwards here. If it breaks something we can roll back
I think I finally cracked https://github.com/cashapp/tempest/issues/171. It turns out the issue is kotlin related.
It seems the root of the problem was that our project has the
-Xjvm-default=all
compiler flag set. Commenting it out eliminates this issue.Seems like there's some subtle backwards incompatibility around annotations on pre-Java 8 interfaces with default implementations. Before Java 8, interfaces didn't support default implementations and would have a
DefaultImpls
static class declared to emulate that behaviour. Kotlin defaults to that pre-Java 8 behaviour (docs), and generates DefaultImpl objects. It seems like tempest using the pre-java-8 style here causes in projects that enable the post-java 8 behaviour.all-compatibility
seems like the correct setting to apply to solve this, based on these docs:Hopefully this will fix my side without breaking other users of tempest.