feat: Implement java-jar-mapper tool
#4640
Conversation
This tool is used to modify a `.pyroscope.yaml` file with source code mappings for 3rd party libraries from a given jar. It uses heuristics and 3rd party APIs to try to resolve discovered 3rd party library functions in to git repos. There is also a hard coded mapping in `jar-mappings.json` for any popular 3rd party libraries that the tool's heuristics are unable to resolve.
jake-kramer
requested review from
a team,
bryanhuhta and
marcsanmi
as code owners
| "strings" | ||
| ) | ||
|
|
||
| type CommandRunner interface { |
There was a problem hiding this comment.
what is the purpose of this interface?
| "time" | ||
| ) | ||
|
|
||
| type HTTPClient interface { |
There was a problem hiding this comment.
what is the purpose of this interface? Can't we use http.Client?
| } | ||
|
|
||
| // MavenService handles downloading JAR files from Maven Central. | ||
| type MavenService struct { |
There was a problem hiding this comment.
MavenService is not used?
|
|
||
| // extractJDKVersionFromJAR extracts the JDK version from a JAR file by analyzing | ||
| // the class file major version numbers. Returns the major version (e.g., "8", "11", "17"). | ||
| func extractJDKVersionFromJAR(jarPath string) (string, error) { |
There was a problem hiding this comment.
The class version in the class file header is not the version of the JDK used to run the program. I am not 100% sure but it's likely the javac -target <TARGET> used at compile time. Furthermore libraries are often compiled with low target to allow running on many JDKs, a lot of them target 8 or 11 JDKs. Running this logic against different libraries would produce different results. It should only run against non libraries classes, but even then it's not reliable as app devs can still compile to a different target (they have less reasons than the lib devs, but still)
| @@ -0,0 +1,124 @@ | |||
| { | |||
There was a problem hiding this comment.
why is the main config yaml, and this config is json?
| { | ||
| "mappings": [ | ||
| { | ||
| "jar": "tomcat-embed-core", |
There was a problem hiding this comment.
If this field is compared against artifact id, then maybe rename the field to artifact_id
| "path": "spring-boot-project/spring-boot-autoconfigure/src/main/java" | ||
| }, | ||
| { | ||
| "jar": "agent", |
There was a problem hiding this comment.
does this mean any artifact with the name agent will resolve to pyroscope-java ? this does not seem right
|
|
||
| func main() { | ||
| var ( | ||
| jarPath = flag.String("jar", "", "Path to the Java JAR file to analyze") |
There was a problem hiding this comment.
Am I expected to call this tool on every dependency manually? This is not very convenient. We should at least allow passing multiple jars or a directory(ies?) of jars.
| } | ||
|
|
||
| // Check for Bazel runfiles directory (e.g., ProjectRunner.runfiles for ProjectRunner.jar) | ||
| bazelJARs := e.findBazelRunfileJARs(jarPath) |
There was a problem hiding this comment.
does the customer we build this for have these files and does it work for them?
2 participants
This tool is used to modify a
.pyroscope.yamlfile with source code mappings for 3rd party libraries from a given jar.It uses heuristics and 3rd party APIs to try to resolve discovered 3rd party library functions in to git repos.
There is also a hard coded mapping in
jar-mappings.jsonfor any popular 3rd party libraries that the tool's heuristics are unable to resolve.