Now that both DS-Memory 6.0.0 and DS-Java 8.0.0 are released on 21 I am
thinking about a strategy to move them beyond 21.

The next Java LTS release will be Java 25 this coming September and I have
already checked out the early-access release of 25 and, so far, there are
no changes in 22 through 25 that would require any API changes in our Java
21 releases.  This is good news.

However, as the first goal, I would like to move the Java code out from
underneath the problems associated with having the FFM code in "preview"
mode.  It is unfortunate that FFM did not graduate from preview in 21, but
it did finally in 22 where it was promoted to being part of the Java
Language.

The other goal is to move away from the dependency on DS-Memory entirely
and have DS-Java code directly to FFM as required.  Once we move to 22+
this can be accomplished in stages, initially having the DS-Memory API and
FFM API in parallel for a while and eventually removing the DS-Memory
dependency entirely.

I can see at least two paths forward:

1. Create DS-Memory / DS-Java releases on Java 22.

   - This would make the code compilable and runnable with Java 23, 24, and
   25.
   - This only requires changes to the POM file with one tiny exception in
   DS-Memory where it checks for the minimum java version.
   - Nonetheless, no public API changes.
   - Users who are on 23 or 24 and can't use 21 will be able to use the
   library without waiting for 25.
   - I don't think moving to 22 would require a major version change.
   DS-Memory could become version 6.1.0 and DS-Java 8.1.0.
   - If I start adding direct FFM capabilities, those would be additional
   API methods and not removing any API, so those releases could be 6.2.0 and
   8.2.0 respectively, and so on.  It is when we decide to remove the
   dependency on DS-Memory that would require a major version change, which
   could be much later.

2. Start working on deprecation of DS-Memory and adding direct FFM calls in
DS-Java and prepare for a Java 25 compatible release after the September
Oracle release of Java 25.

   - This is quite a bit of work, but it needs to be done eventually.
   Nonetheless, it means skipping over 22, 23, and 24.
   - I'm sure there is other clean-up work that could be done that would
   justify a major version release at that point.

Thoughts?

Reply via email to