Could it be that the 8 and 9 are derived from the last part of Royale's recent version numbers: 0.9.8 and 0.9.9?
In your tutorialspoint link, it prints 1.6.0_25, so I can see why you think it might always be the Java version. However, I suspect that's specifically because tutorialspoint is calling getImplementationVersion() on the java.lang package, so the result will match whichever JDK it is from, since it is a core language class. I think that getImplementationVersion() is based on the version of the .jar file where the class/package is located. So, for Royale classes, it should return something like 0.9.8 or 0.9.9. Anyway, it seems like the differing build numbers between CI and your local machine means that you have a different version of the compiler checked out locally than what the CI has. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Wed, Feb 23, 2022 at 10:04 AM Yishay Weiss <yishayj...@hotmail.com> wrote: > The typedef swcs produced on my machine are different to the ones produced > on CI which breaks the build process. I noticed this difference in the > catalog (though it’s not the only one) > > <compiler name="Apache Royale: Compiler: Compiler-Common" > version="0.9" build="8"/> > <compiler name="Apache Royale: Compiler: Compiler-Common" > version="0.9" build="9"/> > > Can somebody explain why the build# is different? > > I had a look at SWCTarget.java in the compiler and it looks like it’s > getting its information from VersionInfo which ultimately relies on Java’s > getImplementationVersion() [1]. > > I checked java -version both on my machine and on the CI and they both > output 1.8.0_201, so I don’t understand why the version is different. > > Any clues? > > [1] Java.lang.getImplementationVersion() Method (tutorialspoint.com)< > https://www.tutorialspoint.com/java/lang/package_getimplementationversion.htm > > > >
