DEFAULT_CALL could also be converted to a method. There’s no harm if such SqlCall objects are created each time we need them.
> On Nov 6, 2020, at 11:05 AM, Vladimir Sitnikov <[email protected]> > wrote: > > Just in case, I've added a GitHub job that runs Calcite tests with OpenJ9 > JVM 1.8 in > https://github.com/apache/calcite/commit/d226a9456a8cfdb108a50744d702e915b46c7ffa > > Julian>The problem occurs at InferTypes line 41, which is a lambda > > I believe lambda/reference is irrelevant since SqlOperandTypeInference (the > type of the field) is interface with a method that receives SqlCallBinding. > So the implementation does not matter, and JVM would have to load and link > SqlCallBinding. > > --- > > Technically speaking, circular dependencies between classes/packages are > sad, so it might be nice to heal that anyway. > I believe we could easily fix SqlCallBinding. > > The current code is as follows, and we do not really need DEFAUL_CALL to be > present on SqlCallBinding > > public class SqlCallBinding extends SqlOperatorBinding { > private static final SqlCall DEFAULT_CALL = > SqlStdOperatorTable.DEFAULT.createCall(SqlParserPos.ZERO); > > *Ruben*, could you please try wrap that with a holder class as follows? > It would break the circular dependency. > > public class SqlCallBinding extends SqlOperatorBinding { > private static class DefaultCallHolder { > private static final SqlCall DEFAULT_CALL = > SqlStdOperatorTable.DEFAULT.createCall(SqlParserPos.ZERO); > } > > --- > > RexToLixTranslator, JAVA_TO_SQL_METHOD_MAP is public field. I wonder if we > can make it private and move to a holder class as well. > > Vladimir
