Verify JDK 9 classes.

[He-Pin]

Motivation:
Use Scala-cli to verify the resulting jar can be used in JDK 9, I think this can be a more complete solution than unzip ...find.
refs: #1040

Result:
Can be tested with scala-cli at nightly job, which was verified with https://github.com/apache/incubator-pekko/actions/runs/7684565710/job/20941211960?pr=1064

ping @Roiocam too

[mdedetrich]

As an alternate suggestion, wouldn't it be simpler to just check the header for some specific .class file that we know should be compiled with JDK9?

[He-Pin]

@mdedetrich Do you mean unzip | find?

[He-Pin]

[He-Pin]

@pjfanning I only added this to the nightly build, which I think should be enough, if you like, I think we can add a dedicated job to test this, and it was tested with a dedicated job.

[mdedetrich]

@mdedetrich Do you mean unzip | find?

Yup, even an awk ontop just to parse out the bytecode header in the .class file to see if it matches the JDK 9 bytecode version

[He-Pin]

@mdedetrich
The difference is that this approach can test whether the final product really works properly, rather than just checking if xxx.class exists using grep. I think this is a relatively advantageous point. In addition, it can expand to test multiple platforms' products, while if you use grep xxx.class in the end, can only determine whether xxx.class exists, right? At least I saw that Dotty uses this approach as well.

[He-Pin]

Because I'm going back to my hometown the day after tomorrow, I want to help resolve some blocker issues for 1.1.0-M1. At least I think this solution can solve the issues associated with it, and it's not such a strange solution because there is already a VersionGenerator now.

[mdedetrich]

@mdedetrich The difference is that this approach can test whether the final product really works properly, rather than just checking if xxx.class exists using grep. I think this is a relatively advantageous point. In addition, it can expand to test multiple platforms' products, while if you use grep xxx.class in the end, can only determine whether xxx.class exists, right? At least I saw that Dotty uses this approach as well.

I understand and I will accept either solution. My main reason for suggesting the simpler approach is that our issue is quite black and white, either the JDK 9 classes don't get generated at all or they get generated with the correct JDK version and if they do its completely correct.

Hence I think that checking whether it works is a bit excessive because at that point we are basically checking the scalac compiler is working where as what our historic issue has been is that the misconfiguration of sbt-osgi/multijvm/etc etc means that certain classes don't get compiled/included

[He-Pin]

I understand you too. But in another post, you said we still need to support Java 8 for a while. If we eventually migrate to only supporting Java 11, then this can naturally be deleted, as the project is still in incubation. I think we can bear this cost to ensure our products don't become a laughing stock and to ensure supply chain security, right?

[mdedetrich]

I understand you too. But in another post, you said we still need to support Java 8 for a while. If we eventually migrate to only supporting Java 11, then this can naturally be deleted, as the project is still in incubation. I think we can bear this cost to ensure our products don't become a laughing stock and to ensure supply chain security, right?

Sure, as I said I will accept either solution.

I think there may be a more elegant/simpler one we can talk about/do later.

[Roiocam]

I have reviewed this for a while, i am kind of understand why this PR does.

A simple grep pipeline connected to unzip results only checks some of the classes, once these class names change or delete, we have to upgrade the CI too.

Another way that parse out the bytecode header, I think it was too complex.

[Roiocam]

LGTM, Thanks. I am glad we have a double insurance for these JDK9 check.

[He-Pin]

@mdedetrich @pjfanning I have rebased.

[nvollmar]

lgtm