GitHub Community
How do I learn which versions of Java are supported by CodeQL? #22425
-
|
I followed the instructions in Configuring code scanning - GitHub Docs to set up code scanning for my public repo. I used CodeQL with GitHub Actions. At first it didn’t work, saying that auto build failed to detect how to build my code. I suspected this was because I was using a mono repo. I moved my code to a new repo where it was at the top level. But now CodeQL says it can’t build it with an error message that looks like it can’t build it because it’s Java 17: …
I wasn’t able to find a list of supported versions of programming languages in the documentation. Where can I find this information? Also, I’m confused about why CodeQL needs my Java code to be compiled. I was under the impression it worked by looking for patterns in source code. Why would my source code need to be compiled? What use would it have for the compiled class files? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
|
I think it might compile the code so it can run it. As for the compile failure, try compiling it with |
Beta Was this translation helpful? Give feedback.
-
|
That did the trick. I replaced the autobuild step with bringing in the setup-java action and adding a step immediately after that where I ran the |
Beta Was this translation helpful? Give feedback.
-
|
I’m glad your problem was resolved. For some context, CodeQL wants to observe a build process mainly such that it can know exactly which code is part of the project and which complation flags are used with it. This is especially important in the C/C++ world where compilation flags can radically change what the code does, and where it is not uncommon to generate some source files mechanically during the build process. Even though these are less pressing considerations for Java, we use the same procedure for all compiled languages, to avoid the madness of having slightly different requirements for different languages. (And some Java projects still do create analyzable code on the fly, or compile different implementations of the same classes in different configurations). We don’t actually run the code being built, though. The autobuilder is a kind of best-effort attempt to provide a one-click setup process for maintainers who want to try out Code Scanning on their repo. Once you’ve gone to the trouble of setting up a definite build command in the scanning workflow, that generally works more robustly and predictably than the autobuilder. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for explaining. I can see how that would be important even for Java code. I’ve seen annotation processors and Protobuf compilers used to generate Java code as part of a build. |
Beta Was this translation helpful? Give feedback.
I’m glad your problem was resolved.
For some context, CodeQL wants to observe a build process mainly such that it can know exactly which code is part of the project and which complation flags are used with it. This is especially important in the C/C++ world where compilation flags can radically change what the code does, and where it is not uncommon to generate some source files mechanically during the build process. Even though these are less pressing considerations for Java, we use the same procedure for all compiled languages, to avoid the madness of having slightly different requirements for different languages. (And some Java projects still do create analyzable code on the fly, or co…