Vladimir Sitnikov created CALCITE-4459: ------------------------------------------
Summary: Type annotations defeat org.jboss:jandex bytecode parser sometimes Key: CALCITE-4459 URL: https://issues.apache.org/jira/browse/CALCITE-4459 Project: Calcite Issue Type: Improvement Components: core, linq4j Reporter: Vladimir Sitnikov Assignee: Vladimir Sitnikov For instance, the following code in {{org.apache.calcite.linq4j.EnumerableDefaults.WrapMap}} {code:java} @Override public Set<Entry<@KeyFor("this") K, V>> entrySet() { return new AbstractSet<Entry<@KeyFor("this") K, V>>() { {code} produces the following exception with {{org.jboss:jandex:2.0.3.Final}} {noformat} Caused by: java.lang.IllegalStateException: Class extends type annotation appeared on a non class target at org.jboss.jandex.Indexer.processTypeAnnotation(Indexer.java:403) at org.jboss.jandex.Indexer.processTypeAnnotations(Indexer.java:380) at org.jboss.jandex.Indexer.processAttributes(Indexer.java:314) at org.jboss.jandex.Indexer.processMethodInfo(Indexer.java:271) at org.jboss.jandex.Indexer.index(Indexer.java:1454) {noformat} Note: Calcite bytecode is perfectly valid (provided a recent javac is used), however, jandex is used by Hibernate, Quarkus (and other projects), so it might result in non-tirival exceptions like {{IllegalStateException: Class extends type annotation appeared on a non class target}} while users would have absolutely no clue which class causes failure and why. Sample jandex issues: https://github.com/wildfly/jandex/issues/98, https://github.com/wildfly/jandex/issues/88, https://github.com/wildfly/jandex/issues/80, and others. I suggest we parse Calcite-produced classes with Jandex, so we know when incompatibility happens. Here's the same case for pgjdbc/pgjdbc: https://github.com/pgjdbc/pgjdbc/pull/2010 -- This message was sent by Atlassian Jira (v8.3.4#803005)