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

[inferred spans] Java 8 vs. agrona #1435

Open
breedx-splk opened this issue Aug 26, 2024 · 3 comments
Open

[inferred spans] Java 8 vs. agrona #1435

breedx-splk opened this issue Aug 26, 2024 · 3 comments

Comments

@breedx-splk
Copy link
Contributor

Component(s)

No response

Is your feature request related to a problem? Please describe.

This PR tries to update agorna to the latest version: #1433

It currently breaks the build, because agorna has chosen to require java 17:
https://github.com/real-logic/agrona/releases/tag/1.23.0-v2

So now the inferred-spans module cannot update agorna. We should figure out if we want to continue using it and/or require java 17 as well, or something else.

Describe the solution you'd like

Creating this issue mostly for the component owners to figure this out.

Describe alternatives you've considered

No response

Additional context

No response

@breedx-splk
Copy link
Contributor Author

@jackshirazi @SylvainJuge @JonasKunz what do you think?

@SylvainJuge
Copy link
Contributor

The usage in inferred spans is mostly for a few collection implementations, so we definitely not require the latest features. Doing an upgrade here means dropping support from Java 8 to 16 which is definitely a big change. We need to discuss this on our side but my gut feeling is that we will probably only keep the 1.22.0 version for now.

@JonasKunz
Copy link
Contributor

Yeah let's just stick with 1.22.0.
In the elastic-apm-agent we still support Java 7. For that reason agrona wasn't used as a dependency, but the source code of the used collections was copied directly to the repo.

We only use agrona for some primitive-optimized collections (maps and lists). Those don't use any "nasty" features but just plain Java without any java-api calls and therefore are very very very unlikely pose a security risk. I also don't expect that we lose out on significant performance gains as the fundamental algorithms are decades old.

If we ever get a report of a security vulnerability we can move to copying / reimplementing the used primitive collections, but I highly doubt that we'll receive such a vulnerability report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants
@SylvainJuge @JonasKunz @breedx-splk and others