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 usage/future of Unsafe? History around the choice of
> using it in C* and future plans I might not know of?
>

It was used mainly to get around the fact that Java did not offer other
means to do certain things.
Outside of trying to anticipate some of the restrictions of that API and
make sure that the JDK offers a suitable replacement for us. I am not sure
that there is much that we can do. But I might misunderstand your question.

Le mer. 1 mars 2023 à 21:16, Ekaterina Dimitrova <e.dimitr...@gmail.com> a
écrit :

> 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 tickets due to the involvement of too many moving parts.
> Agreement reached in [1] that new JDK introduction can be done
> incrementally. Scripted UDFs removed, hooks to be added in a follow up
> ticket.
> What does this mean?
> - Currently you can compile and run Cassandra trunk  with JDK 17(further
> to 8+11). You can run unit and java distributed tests already with JDK17
> - CASSANDRA-18106 in progress,  enabling CCM to handle JDK8, 11 and 17
> with trunk and when that is ready we will be able to run also Python tests;
> After that one lands it comes CASSANDRA-18247 ; its goal is to add CircleCI
> config (separate of the one we have for 8+11) for 11+17 which can be used
> from people who work on JDK17 related issues. Patch proposal already in the
> ticket. Final version we will have when we do the switch 8+11 to 11+17,
> things will go through evolution.
>
> What does this mean? Anyone who is interested to test or to help with
> JDK17 effort can easily do it directly from trunk. Jenkins and CircleCI are
> not switched from 8+11 to 11+17 until we are ready. Only test experimental
> additional CircleCI config will be added, temporary to make it easier for
> testing
>
> To remind you - the umbrella ticket for the JDK17 builds is
> CASSANDRA-16895.
> Good outstanding candidate still not assigned - CASSANDRA-18180, if anyone
> has cycles, please, take a look at it. CASSANDRA-18263 might be also of
> interest to someone.
>
> In other news, I added already to the JDK17 jvm options certain
> imports/exports which are needed at this point but as we agreed in the past
> - it will be good to try to eliminate as many of them as we can. Consider
> those experimental in my opinion.
> Some of them though are related to:
> -- some were added already from 11; thoughts?
> *-- *some will be eliminated with some maintenance in progress
> *-- *some are related to
> https://chronicle.software/chronicle-support-java-17. I guess we are
> cornered with those until Chronicle eliminates the need for those.
> (CASSANDRA-18049)
> -- Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd
> without opening internals (CASSANDRA-17850)
> -- we also use setAccessible at numerous places.
> And I am sure our CI will tell me I am missing something, especially when
> trunk is alive...
>
> A few other questions:
> - thoughts around the usage/future of Unsafe? History around the choice of
> using it in C* and future plans I might not know of?
> - ECJ - It seems the compiler artifacts are moved from here
> <https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj> to
> here <https://mvnrepository.com/artifact/org.eclipse.jdt/ecj> and there
> is change of license from EPL1.0 to EPL2.0 too. But if I read correctly
> here <https://www.apache.org/legal/resolved.html#weak-copyleft-licenses> that
> should not affect us. I am dealing with this in CASSANDRA-18190. Please let
> me know if you see any problem with this that I might be missing.
> - Looking at the history of tickets around JMXServerUtils class I guess it
> was accepted that we might have breakages (and we already had
> CASSANDRA-14173) - JmxRegistry extends sun.rmi.registry.RegistryImpl?
>
> Best regards,
> Ekaterina
>
> [1] https://lists.apache.org/thread/c39yrbdszgz9s34vr17wpjdhv6h2oo61
>
>
>

Reply via email to