Thanks for all of the work on this, Ekaterina! I would add a third point:
- If newer JVMs offer a standard way to access things that no longer
requires unsafe or native access, we can move to that standard approach
once all supported JVMs are in scope
The case I was thinking about specifically
Hi everyone,
To close this thread, I see lazy consensus around JDK internals accesses as
follows:
- we keep the current accesses to JDK internals in the Cassandra codebase,
they were carefully considered during former reviews already. If there is
breakage from changes in JDK internals (which are
Thanks Benjamin, please, find below my comments.
"It is not necessarily a problem as long as we do get an issue with the
Modules boundaries and their access. For me it needs to be looked at on a
case by case basis."
We can still use the --add-opens/add-exports with Java 17(I mentioned I
added
Hey Ekaterina,
Thanks for the update and all the work.
> -- we also use setAccessible at numerous places.
It is not necessarily a problem as long as we do get an issue with the
Modules boundaries and their access. For me it needs to be looked at on a
case by case basis.
- thoughts around the
Hi everyone,
Some updates and questions around JDK 17 below.
First of all, I wanted to let people know that currently Cassandra trunk
can be already compiled and run with J8 + J11 + J17. This is the product of
the realization that the feature branch makes it harder for working on
JDK17 related
