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)