Skip to content
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

Set 22.0.1-tem as SDKMAN env Java #110

Closed
wants to merge 3 commits into from
Closed

Conversation

MattAlp
Copy link
Contributor

@MattAlp MattAlp commented Jun 25, 2024

What does this PR do?:
This configures sdkman to use Temurin 22 as the Java version when working in this repo.

Motivation:
We need the correct JDK registered for using JVMTI symbols when building, and dd-trace-java requires JAVA_HOME to point to a JDK 8 build. This is a convenient way of mitigating forgetting to run sdk use or some other env var switching prior to building.

Additional Notes:
I'm considering adding a shell hook here and in dd-trace-java + relevant private repos that will automatically set the appropriate environment variables for these multi-JDK-dep projects. I've used https://github.com/Shopify/shadowenv in the past and like it quite a bit, any of https://direnv.net/#related-projects would work though.

How to test the change?:

For Datadog employees:

  • If this PR touches code that signs or publishes builds or packages, or handles
    credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
  • This PR doesn't touch any of that.

Unsure? Have a question? Request a review!

Copy link

github-actions bot commented Jun 25, 2024

🔧 Report generated by pr-comment-cppcheck

CppCheck Report

Warnings (6)

Style Violations (176)

Copy link

github-actions bot commented Jun 25, 2024

🔧 Report generated by pr-comment-scanbuild

Scan-Build Report

User:runner@fv-az654-570
Working Directory:/home/runner/work/java-profiler/java-profiler/ddprof-lib/src/test/make
Command Line:make -j4 clean all
Clang Version:Ubuntu clang version 14.0.0-1ubuntu1.1
Date:Fri Dec 13 20:54:20 2024

Bug Summary

Bug TypeQuantityDisplay?
All Bugs6
Logic error
Assigned value is garbage or undefined1
Dereference of null pointer3
Result of operation is garbage or undefined1
Unused code
Dead nested assignment1

Reports

Bug Group Bug Type ▾ File Function/Method Line Path Length
Logic errorAssigned value is garbage or undefineddwarf.cppparseInstructions24420
Unused codeDead nested assignmentvmStructs.cppcheckNativeBinding9451
Logic errorDereference of null pointersafeAccess.hload3318
Logic errorDereference of null pointersymbols_linux.hElfParser12932
Logic errorDereference of null pointerflightRecorder.cppflush15048
Logic errorResult of operation is garbage or undefinedvmStructs.cppfind84016

@@ -0,0 +1,3 @@
# Enable auto-env through the sdkman_auto_env config
# Add key=value pairs of SDKs to use below
java=22.0.1-tem
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we have a matching README requirement section if we use sdkman ?

Copy link
Contributor Author

@MattAlp MattAlp Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would you put in it? Prompt the user to install sdkman?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are currently pre-requisites to building the project.
Using sdkman simplifies this. We can mention it as an alternative or we can just put this as the standard path to building the project.
This is not a blocking comment to merge.

@jbachorik
Copy link
Collaborator

Nice, using the rc file :)

I wonder if we need JDK 22 for anything - we still need to keep the bytecode of the Java part compatible with Java 8.
What symbols we need from JDK 22?

@MattAlp
Copy link
Contributor Author

MattAlp commented Jun 25, 2024

@jbachorik some symbols and jvmtiCapabilities are not present. Do you build successfully when using a JDK such as 8.0.412-zulu? However, this does bring up a good point and the larger task at hand; some of our tooling runs on newer JDKs (i.e. Gradle), some of the build processes requires a newer JDK for the correct headers, and some things require Java 8 compatibility. Many of these expect to use an overloaded environment variable such as JAVA_HOME (and its derivatives) AFAICT. There is an opportunity to make the dev workflow more coherent.

@jbachorik
Copy link
Collaborator

@MattAlp Yes, the baseline is JDK 11 for us - because of the JVMTI sampler.

We can be progressive and use the tip (JDK 22) - we are setting the compatibility in ddprof-lib to Java 8 so we are fine at least for JDK 22

@jbachorik
Copy link
Collaborator

Is this still relevant? If not, please close it - it's been dangling for long enough time.

@MattAlp
Copy link
Contributor Author

MattAlp commented Jan 6, 2025

It doesn't appear that we really needed this and it was suggested to check off our onboarding get-a-commit-in tradition. If we run into something that requires Java x and would benefit from the directory-aware switch, I'll re-open.

@MattAlp MattAlp closed this Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants