Warnings about terminally deprecated `Unsafe` usage

[fmeum]

What version of protobuf and what language are you using? Version: 30.1 Language: C++/Java/Python/C#/Ruby/PHP/Objective-C/Javascript

What operating system (Linux, Windows, ...) and version? Any

What runtime / compiler are you using (e.g., python version or gcc version) JDK 24

What did you do? Use Protobuf generated messages.

What did you expect to see No warnings

What did you see instead?

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::arrayBaseOffset has been called by com.google.protobuf.UnsafeUtil$MemoryAccessor (file:/redacted/some.jar)
WARNING: Please consider reporting this to the maintainers of class com.google.protobuf.UnsafeUtil$MemoryAccessor
WARNING: sun.misc.Unsafe::arrayBaseOffset will be removed in a future release

Anything else we should know about your project / environment

[cushon]

(This is also tracked by internal bug b/382713504)

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.

[fmeum]

Still relevant (13 upvotes)

[danishnawab]

@cushon can you share an update on the internal issue. Currently, it's only a warning but might become a runtime failure in JDK 26.

[esrauchg]

Sorry about failing to update the public issue here!

We're aware of this issue and are just resolving on which of a few possible paths to resolve it. We intend to resolve this before it should become a serious issue for any users, even early adopters of new JDKs.

Just to clarify the state a bit, JavaProto uses sun.misc.Unsafe as a performance optimization and supports environments where it is unavailable (checks existence via reflection and falls back to another), on that runtime it is only a performance slowdown in those environments.

It is not possible that JDK 26 will strictly remove it: the next step in the process is that 26 may change the behavior to throw by default instead of logging by default with a flag to opt back to logging. We understand that is currently more likely to happen in 27 or 28 however, but it has not been decided yet. In the worst case we could quickly do a patch release that tests if it throws and runs our fallback path with a printed notice that you may be slower unless you reenable it, but we also expect to have other temporary solutions that we could move fast on if it is announced that 26 is moving forward on this compared to 27 or 28 (compared to larger efforts that would also solve the problem a different way which we are still evaluating)

The next LTS will be 29 which we understand is almost certainly going to have the throw-by-default-but-flag-to-opt out behavior, and the actual removal of the API with no flag to opt back in will happen at some point after that LTS. We are obviously committed to fully resolving the topic well before that is a possibility.

Note that we also still officially support Java 8 until at least end of 2026, where Java 8 does not support any of the suggested replacement APIs for sun.misc.Unsafe. We are also correspondingly committed to still supporting Java 8 users.

Thanks!

[bmarwell]

As a workaround (only to silence the warnings), you can add --sun-misc-unsafe-memory-access=allow for now.

[bmarwell]

@jguamie what is the performance impact when unsafe is not available? Also, the message is a warning. Given that it works "just fine", this seems too high? I guess every user would see it on each application start by default...

[leonardehrenfried]

I believe that the warning is emitted by the JVM itself and not this library. I think it's supposed to scare people into finding an alternative to sun.misc.Unsafe.

[bmarwell]

I meant the logging statement which was added by them

[esrauchg]

Just to give an update regarding that last PR (of 'log-warning concern') which has gone in:

The JDK removal track of the method proceeds as:

1. The methods just are there and work
2. The methods log warnings by default (latest JDK is here)
3. The methods throw by default (sometime JDK 26 or later)
4. The methods are genuinely removed (TBD)

Most of our users are still on step 1 today with some on step 2.

Per last reply, both before and after that PR, if the JDK jumped straight to step 4, Protobuf would already silently continue without Unsafe with a performance hit.

After the PR, Protobuf behave more robustly under state 3. But we still plan to update Protobuf to not use sun.misc.Unsafe (and not print any warning when it is unavailable) well before any nontrivial percentage of users are in state 3, meaning that looking forward to 2027, 2028, etc, we don't expect users who use 'latest' Protobuf and 'latest' JDK with no flags to ever see that warning. The defensive check and warning will primarily help help people who (for example) are living in the year 2028 and are still on some from-that-vantage-point-'old' Protobuf release (from e.g. 2026-Q1) with a 'new' JDK (from e.g. 2028).

Java logger does have the capability to set logger levels of specific loggers, so under a weird case that someone is intentionally living on a throw-on-use JDK and a Protobuf version that hasn't been updated, and they find it annoying a warning is printed, it is always possible for the application to add one weird line to suppress the warnings from being printed.

what is the performance impact when unsafe is not available? [...] Given that it works "just fine", this seems too high?

This is a somewhat of nuanced topic; one of the main reasons people use Protobuf instead of e.g. simple raw JSON is for the performance characteristics, so even somewhat small performance regressions happening silently to users will be a very big deal to some customers. For many of our largest customers a 5% performance regression would be a more serious of a concern than some of our published CVEs, while a 5% performance regression on Protobuf encode time wouldn't be a meaningful topic for many other customers.