New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use runtime java home for third party audit task #91412
Use runtime java home for third party audit task #91412
Conversation
We actually do indeed need to use the runtime Java for this task because depending on the target version, we may be loading classes for a later Java version. For example, if we use dependencies that are MR jars, then we in fact do load different classes depending on the runtime Java version. To test this properly then we need to use the target Java version to actually execute the task so it can both load the newer classes, and any classes from any newer APIs present in the later Java version.
Pinging @elastic/es-delivery (Team:Delivery) |
👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its cleaner to use an if / else block here instead of potentially configure javahome twice
We're not configuring it twice, we simply on set it if runtime java is different than the compiler java. So otherwise it'll just use the default, which is the build java home. |
💚 Backport successful
|
We actually do indeed need to use the runtime Java for this task because depending on the target version, we may be loading classes for a later Java version. For example, if we use dependencies that are MR jars, then we in fact do load different classes depending on the runtime Java version. To test this properly then we need to use the target Java version to actually execute the task so it can both load the newer classes, and any classes from any newer APIs present in the later Java version.
We actually do indeed need to use the runtime Java for this task because depending on the target version, we may be loading classes for a later Java version. For example, if we use dependencies that are MR jars, then we in fact do load different classes depending on the runtime Java version. To test this properly then we need to use the target Java version to actually execute the task so it can both load the newer classes, and any classes from any newer APIs present in the later Java version.
We actually do indeed need to use the runtime Java for this task because depending on the target version, we may be loading classes for a later Java version. For example, if we use dependencies that are MR jars, then we in fact do load different classes depending on the runtime Java version. To test this properly then we need to use the target Java version to actually execute the task so it can both load the newer classes, and any classes from any newer APIs present in the later Java version.
Closes #91264