[ 
https://issues.apache.org/jira/browse/CALCITE-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109803#comment-18109803
 ] 

Vladimir Sitnikov commented on CALCITE-4831:
--------------------------------------------

The blocker is a javac bug rather than an Immutables one. javac did not surface 
{{TYPE_USE}} annotations through the annotation-processing API when it read the 
declaring interface from a class file rather than from source. Immutables 
therefore saw no {{@Nullable}} on {{description()}} in any module other than 
{{:core}}, treated the attribute as mandatory, and refused to generate the rule 
configs. The jsr305 annotation is a declaration annotation, so it survived the 
round trip and kept the attribute optional.

The upstream issue is immutables#1262, still open. The comment in {{RelRule}} 
points at #1261, which is an unrelated Guava deserialization issue; worth 
correcting whenever this line is touched.

Measured on the CALCITE-7736 branch by deleting {{@javax.annotation.Nullable}} 
and running {{compileJava}}:

|| compiler || result ||
| javac 21.0.9 | fails in {{:arrow}}, {{:cassandra}}, {{:file}}, {{:geode}}, 
{{:piglet}}, {{:innodb}} and {{:example:csv}} with {{Attribute 'description' is 
mandatory}} |
| javac 21.0.9 with {{-XDaddTypeAnnotationsToSymbol=true}} | passes |
| javac 25.0.1 | passes; the generated cross-module code carries 
{{java.lang.@Nullable String description}} |
| javac 17.0.10 with the same flag | fails |

Per cpovirk on immutables#1262 (2026-02-25), the javac fix is backported to JDK 
21 but off by default, the JDK 17 backport ships in the April release, and JDK 
22 and later need no flag. So this issue closes as soon as the compile JDK is 
22 or later, which is what the {{--release 8}} proposal on dev@ would give us.

Upgrading Immutables does not help on its own: 2.12.2 fails the same way.

The Autostyle exclusion goes at the same time. {{build.gradle.kts}} excludes 
{{**/RelRule.java}} because the {{jsr305 nullable -> jspecify}} rule rewrites 
{{javax.annotation.Nullable}} and destroys the workaround. With the annotation 
gone I removed the exclusion and {{:core:autostyleJavaCheck}} passes; the only 
change Autostyle wants is the import order, which it applies itself.

One thing that does not change: {{:core}} keeps its {{compileOnly}} dependency 
on jsr305, because Immutables-generated code still imports 
{{javax.annotation.CheckReturnValue}}, 
{{javax.annotation.ParametersAreNonnullByDefault}} and 
{{javax.annotation.concurrent.Immutable}}.

> Cleanup Nullable rule annotations post fix for Immutables checker conflict bug
> ------------------------------------------------------------------------------
>
>                 Key: CALCITE-4831
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4831
>             Project: Calcite
>          Issue Type: Task
>            Reporter: Jacques Nadeau
>            Assignee: Jacques Nadeau
>            Priority: Major
>
> Immutables has a small incompatibility issue when compiling cross-module 
> using the checker nullable annotations (works fine with 
> javax.annotation.Nullable). They are looking to fix it shortly. In the 
> meantime, we need to double-annotation the description field of 
> RelRule.Config to allow separate module Immutables to be correctly generated 
> with description as a nullable field. This requires a second annotation and 
> whitelisting RelRule in the autostyle application.
> Pending on this ticket:
> https://github.com/immutables/immutables/issues/1262 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to