Hi Vladimir, first of all, I am very glad to have you back, and thanks for your effort on building consensus on many topics lately!
I am not an expert either in this area, and for a mix of reasons my bandwidth is very limited at the moment, so I wouldn't have the time to ramp up on all details, before being able to review or provide feedback on the change. This said, I hear the pros and I agree on all points, I doubt there could be objections there. I haven't seen (apologies if I missed them!) a list of potential risks, which is the only possible blocking point. An incomplete list of questions: - are we at risk of having the new bytecode misbehaving where the current setup works correctly, especially on older JVM versions? - is there any foreseeable friction for current contributors due to the switch (problems compiling, running tests, CI, etc.)? - is there a risk of having problems running our release process or upgrades downstream? If there are no risks, or if they can be verified or mitigated with reasonable effort, possibly with the use of new AI technologies, I don't see why we should pass on modernizing our stack and get the project to a better place. Stamatis raised one concern, and it was addressed, I wonder if you could foresee others, and if you could list them. The community trusts you on these matters, you have a great record track on improving CI/build/error checking etc, if you could summarize the risks for us to discuss, we can probably gloss over the implementation details, unless someone has the skill and time to look into them. What do you guys think? Best regards, Alessandro On Thu, 24 Sept 2026 at 23:39, Vladimir Sitnikov < [email protected]> wrote: > > I don't understand exactly what the benefit of these changes is for > Calcite developers or users. > > Sorry this is lots of text. I do not know how to make it smaller. > Sorry if this brings bad memories. > > Mihai, Julian, Calcite currently relies on Java 8, and its publicly > available builds receive no bug fixes for a long time already. > > There are lots of bugs in javac (e.g. I filed one a couple of weeks > ago: https://bugs.openjdk.org/browse/JDK-8391567), > and we can't live with outdated/unsupported java compilers. > > The very first mail in the thread gives an exact issue Calcite faces > should someone add/remove annotations: > Invalid bytecode file: .../elasticsearch/.../ElasticsearchJson.class > > The solution is to use javac from Java 25. It has all the bug fixes, > and it can produce Java 8 compatible code. > Then we no longer rely on outdated compilers, and users get better > Calcite (fewer bugs in the bytecode). > > ----- > > Part of the puzzle is as follows: > > * "faster calcite builds" require "replace Checkerframework with > NullAway checker" because NullAway is way faster > * "nullaway" requires "going for jspecify annotations". It is a nice > thing anyway because it is a de-facto standard. > * "jspecify and nullaway" requires "upgrading javac" because java 8 > often produces invalid bytecode > * "newer nullaway and error-prone" requires "java 17 or even 21 for > launching the build system" > * "running build system with Java 21 and running tests with Java > 8..25" requires "teaching build system to use different JVM for tests" > ... > > Now's the tough part. > Five years ago I quit the project as I realized my behavior was not > acceptable: > https://lists.apache.org/thread/j4nbh4st0nqbwl69b1mzrsd8p758mf28 > Now I think I got better at listening. > > I can easily understand if someone says "this all worked previously, > don't fix something that is not broken", so I would like to gauge > first. > > I see many of the changes I contributed still hold: Gradle is still > there, `@Nullable` are still there. > So I wonder if I could ask for a bit of trust in that area. > No strings attached. Like if it misbehaves, I could help rolling it back. > > Vladimir >
