-
Notifications
You must be signed in to change notification settings - Fork 937
Change jfrconv binary generation from cpp to shell. #1366
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
Conversation
The commit fixes async-profiler#1344 and includes the following changes: * Rewrite jfrconv launcher script in shell from cpp. * Changes to Makefile to accomodate the shift to shell script.
src/launcher/launcher.sh
Outdated
|
|
||
| set -euo pipefail | ||
|
|
||
| VERSION_STRING="JFR converter PROFILER_VERSION built on $(date '+%b %d %Y')" |
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.
It is today's date, not the build date, right?
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.
Yes replaced at build time like a macro. Will reflect in next commit
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.
Addressed in commit 444fb5d
src/launcher/launcher.sh
Outdated
| if [[ "$OSTYPE" == "darwin"* ]]; then | ||
| SCRIPT_PATH="$(cd "$(dirname "$0")" && pwd)/$(basename "$0")" | ||
| else | ||
| SCRIPT_PATH="$(readlink -f "$0")" | ||
| fi |
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.
Is canonicalization necessary? java -jar accepts relative paths too.
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.
this is such a great suggestion. Thanks can be simplified so much
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.
Addressed in commit 444fb5d
src/launcher/launcher.sh
Outdated
| SCRIPT_PATH="$(readlink -f "$0")" | ||
| fi | ||
|
|
||
| JAVA_CMD=("java" "-Xss2M" "-Dsun.misc.URLClassPath.disableJarChecking") |
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.
Why put java in the beginning, if it's always cut later?
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.
yes changed here and other affected places
src/launcher/launcher.sh
Outdated
| # Copyright The async-profiler authors | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| #!/bin/bash |
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.
bash is not available on all systems. Script must use POSIX compatible /bin/sh.
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.
Addressed in commit 444fb5d
src/launcher/launcher.sh
Outdated
| run_java() { | ||
| # 1. Try JAVA_HOME | ||
| if [[ -n "$JAVA_HOME" ]] && find_java "$JAVA_HOME/bin/java"; then | ||
| exec "$JAVA_HOME/bin/java" "${JAVA_CMD[@]:1}" |
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.
Script should continue trying next options if one of exec calls fails.
This is how the original C++ launcher worked.
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.
Addressed in commit 444fb5d
src/launcher/launcher.sh
Outdated
| exit 1 | ||
| } | ||
|
|
||
| run_java No newline at end of file |
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.
Newline here is required not only because of the coding style, but also because it won't work otherwise after concatenation with .jar.
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.
Addressed in commit 444fb5d
src/launcher/launcher.sh
Outdated
|
|
||
| JAVA_CMD+=("-jar" "$SCRIPT_PATH" "$@") | ||
|
|
||
| find_java() { |
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.
Not very meaningful function - there is just one short expression that can be as well inlined.
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.
Addressed in commit 444fb5d
Makefile
Outdated
|
|
||
| clean: | ||
| $(RM) -r build | ||
| $(RM) -r build |
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.
You have styling issue here & in other files
The file should always end with a single empty new line
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.
Addressed in latest commit
src/launcher/launcher.sh
Outdated
|
|
||
| #!/bin/bash | ||
|
|
||
| set -euo pipefail |
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.
Do we need this on user script?
This might end up causing weird failures on user side if we're not careful
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.
Isn't this better than silent failures?
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.
Some failures that happen due to set -euo pipefail are due to reasons that would work fine without the flags
Such as unbound variables
I'm fine with keeping this but we should test all possible branches of the script
If all possible branches were not tested then this isn't really safe
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.
Which ones do you suggest removing?
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.
All of them raise some level of risk
The question shouldn't be "which to remove"
The proper question should be were all possible cases tested with these flags?
If we have enough testing then keeping this should be fine
For example the script should continue even if a previous exec fails right?
However if an exec fails wouldn't it cause an exit code of 1?
Wouldn't this break the script?
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.
Let's not delve into philosophy. A simple answer is - leave options that are necessary and delete those that aren't.
To me, -e does not seem useful here: there are basically no commands that can fail except for exec, but I explicitly noted that the script should proceed if exec fails.
The same for pipefail: I don't see why it is here, given there are no pipes in the script.
While -u is generally useful, again, it has no behavior impact in this particular script.
Please correct me if I'm wrong, otherwise just remove the entire line. The less code, the better.
src/launcher/launcher.sh
Outdated
| fi | ||
|
|
||
| if [[ "$OSTYPE" == "darwin"* ]]; then | ||
| SCRIPT_PATH="$(cd "$(dirname "$0")" && pwd)/$(basename "$0")" |
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.
pwd)?
wouldn't realpath $0 solve for both?
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.
this is removed after Andrei's suggestion
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.
Addressed in commit 444fb5d
src/launcher/launcher.sh
Outdated
| fi | ||
|
|
||
| # 2. Try PATH | ||
| if command -v java >/dev/null 2>&1; then |
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.
Do we really need all this logic for finding java
can't we use PATH always?
if missing we can print a message telling the user to add it?
If the problem is with our jar being compatible with a specific minimum Java version, we can add a check for that as well
This logic might be hiding bugs as if the user has 10 JDKs it could be failing for the first 9 while passing for the last one
@apangin what do you think?
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 the script is doing what it's intended to do - find any working Java Runtime, even if java is not on the PATH.
src/launcher/launcher.sh
Outdated
| exit 0 | ||
| fi | ||
|
|
||
| if [[ "$OSTYPE" == "darwin"* ]]; then |
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.
why not use uname -s as we do in Makefile?
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.
We have an env variable ready to use. Why go through uname -s?
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.
For consistency
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 don't get how are we deviating from consistency by using a ready to use variable?
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.
Different approach than what we have in the Makefile
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.
Addressed in aeb211f to maintain uniformity and posix compliance
src/launcher/launcher.sh
Outdated
| run_java() { | ||
| # 1. Try JAVA_HOME | ||
| if [[ -n "$JAVA_HOME" ]] && [[ -x "$JAVA_HOME/bin/java" ]]; then | ||
| "$JAVA_HOME/bin/java" "${JAVA_CMD[@]}" && exit 0 |
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.
Why not exec?
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.
For fallback as per Andrei's comment on the previous commit. With prev commit when exec command itself failed it would proceed to try the next for example if java is not present in the path corresponding to the exec command. But now if the exec succeeds but then encounters an error, it won't try the subsequent alternatives. @apangin is this the change you wanted or the previous impl using exec suffices your expectation?
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.
@apangin I checked again and in the previous launcher cpp, there was no fallback if exec succeeds but then error encountered. So the previous impl in shell script sufficed the need as per the existing one. Should I revert again or do you want the changes now for a better fallback?
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.
Script should proceed with the next attempt if exec itself fails, not the target command. There should be no fallback when java process is launched but fails for whatever reason. Basically, the script should retain the same behavior as in the original launcher.
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.
Ok I will change it accordingly. The previous one however wouldn't have proceeded due to set -e. There is a comment from @Baraa-Hasheesh regarding the set -euo pipefail. @apangin if you can share your thoughts so that I can make this change accordingly
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.
Addressed in 385001b
| # Copyright The async-profiler authors | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| #!/bin/sh |
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.
Shebang must stay on the first line. License header shall come after.
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.
Addressed in 385001b
src/launcher/launcher.sh
Outdated
|
|
||
| #!/bin/bash | ||
|
|
||
| set -euo pipefail |
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.
Let's not delve into philosophy. A simple answer is - leave options that are necessary and delete those that aren't.
To me, -e does not seem useful here: there are basically no commands that can fail except for exec, but I explicitly noted that the script should proceed if exec fails.
The same for pipefail: I don't see why it is here, given there are no pipes in the script.
While -u is generally useful, again, it has no behavior impact in this particular script.
Please correct me if I'm wrong, otherwise just remove the entire line. The less code, the better.
src/launcher/launcher.sh
Outdated
|
|
||
| set -euo pipefail | ||
|
|
||
| VERSION_STRING="JFR converter PROFILER_VERSION built on BUILD_DATE" |
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.
There is no much value in introducing variables that are used only once in a local context.
Just inline the string where needed.
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.
Addressed in 385001b
src/launcher/launcher.sh
Outdated
| exit 0 | ||
| fi | ||
|
|
||
| SCRIPT_PATH="$0" |
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.
Same as above.
Good code is like a poem: every word counts.
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.
Addressed in 385001b
src/launcher/launcher.sh
Outdated
|
|
||
| JAVA_CMD+=("-jar" "$SCRIPT_PATH" "$@") | ||
|
|
||
| run_java() { |
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.
Is there a reason to put it in a function, if the following code is executed as is anyway?
E.g., the above argument parsing logic is not in a function, and that's fine.
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.
Since this is not a big script it can be removed
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.
Addressed in 385001b
test.html
Outdated
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.
Added by mistake
src/launcher/launcher.sh
Outdated
| JAVA_CMD+=("-jar" "$0" "$@") | ||
|
|
||
| # 1. Try JAVA_HOME | ||
| if [[ -n "$JAVA_HOME" ]] && [[ -x "$JAVA_HOME/bin/java" ]]; then |
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.
AFAIK, [[ is also a bash extension. Strictly POSIX-compliant shell only supports [.
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.
Had to make other changes as well for full compliance. Addressed in 52af9cc
src/launcher/launcher.sh
Outdated
| fi | ||
| ;; | ||
| -agent*) | ||
| if [ "$(echo "$1" | cut -c1-6)" = "-agent" ]; then |
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.
What does this expression verify? Don't we get in this case only if the argument starts with -agent?
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.
Yes this is redundant. Removed in 6f07677
Signed-off-by: Andrei Pangin <1749416+apangin@users.noreply.github.com>
|
Merged, thanks! |
Description
The commit fixes #1344 and includes the following changes:
Related issues
#1344
Motivation and context
How has this been tested?
jfrconv has been tested to show no Move to trash popup by using the binaries from the notarized zip.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.