Closed aalmiray closed 1 year ago
Thank you @aalmiray and sorry about the late reply.
I don't have much experience with the Java ecosystem, however reading through the link you provided, modules seem like a good idea to me. About the Java version, I don't know that we specifically need Java 8 compatibility, it's a very old version, and both Jenkins and Spinnaker run on Java 11 or more recent, so to be honest I would be inclined to switch to a more recent LTS like Java 11.
@rjalander @adamkenihan @elmsdata wdyt?
In terms of LTS releases:
Yes, Java 8 will be supported for much longer than the next 3 LTS releases after it. So far.
If there are no immediate needs to use syntax and features from newer Java versions I'd say sticking with 8 is the conservative way.
But at the same time I must recognize recommending to sticking to Java 8 is a selfish deal because as it happens JReleaser 1.x must remain Java 8 compatible and I'd love to integrate it with cdevents-java.
Yes, indeed, security support for Java 8 is provided until 2030! I don't know what "active support" means for other releases - it is not available for Java 8, but I don't expect that to be an issue. As long as we have all the language features we need in Java 8, it's fine for me to stay Java 8 compatible.
One of the features that is important that we build soon is code generation - every time we release a new version of the spec it should be possible to automatically have most of the SDK code updated automatically, with some test code/data requiring manual updates. I'm not sure what would be the best way of achieving that in Java, I only hope that using Java 8 won't be an obstacle.
Source code generation should not be a problem when using an external format which I suppose the spec will provide.
Source code generation within the Java language is usually (but not restricted to) annotation processors. This of course requires writing Java code (processor) that takes annotated Java code as inputs to generate yet more Java code.
Thus I suppose choosing an external file template engine that works best with all cdevents sdk targets would be the best option.
🎉 This issue has been resolved in v0.1.2
(Release Notes)
The codebase currently targets Java 8. Java Modules were added in Java 9, providing benefits to both API designers and consumers. It's possible to add a full module descriptor while remaining Java 8 compatible by using the ModiTect plugin.
I've personally help more than a dozen projects to migrate to Java modules in this way. I can prepare a PR if the team agrees to move forward with this idea.