subject:"Re\: JDK 8 syntax"

Re: JDK 8 syntax

2018-08-28 Thread Vova Vysotskyi

Sure, I'll prepare the fix, just wanted to share good news :)

Kind regards,
Volodymyr Vysotskyi


On Tue, Aug 28, 2018 at 8:41 PM Julian Hyde  wrote:

> Excellent. Can you commit the fix please, Vova?
>
> > On Aug 28, 2018, at 10:34 AM, Vova Vysotskyi  wrote:
> >
> > Hi all,
> >
> > Janino issue  with
> > this "strange" default method was fixed, so now we can revert the
> temporary
> > fix made in CALCITE-2261
> >  and update Janino
> > version to 3.0.9.
> >
> > Kind regards,
> > Volodymyr Vysotskyi
> >
> >
> > On Sat, Apr 21, 2018 at 11:27 AM Enrico Olivelli 
> > wrote:
> >
> >> Patch merged!
> >>
> >> Welcome to java 8 !
> >>
> >> Enrico
> >>
> >> Il mar 17 apr 2018, 17:09 Enrico Olivelli  ha
> >> scritto:
> >>
> >>> Issue
> >>> https://issues.apache.org/jira/browse/CALCITE-2261
> >>>
> >>> Patch
> >>> https://github.com/apache/calcite/pull/667
> >>>
> >>> Cheers
> >>> Enrico
> >>>
> >>>
> >>> 2018-04-17 16:51 GMT+02:00 Enrico Olivelli :
> >>>
>  Vova,
>  I tried to add some "default" methods and all tests are passing (maybe
>  you already saw this).
>  Thank you !
> 
>  I will be happy to contribute my patch as it is really simple and I
> have
>  it on my laptop
> 
>  Enrico
> 
> 
>  2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :
> 
> > Taking a step to the side of a workaround, the current version of
> >> Janino
> > prefers default methods instead of "abstract", so we may declare
> > *SchemaPlus.getSubSchema()* method as default and it will help to
> >> choose
> > this method instead of the method from the parent interface :)
> >
> > Kind regards,
> > Volodymyr Vysotskyi
> >
> > 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
> >
> >> I have tried to add an 'unwrap' method to Schema but then Janino
> >> keeps
> >> breaking for other similar reasons about method overriding with
> > narrower
> >> return types.
> >>
> >> I guess it will be an hard task to adapt Calcite code.
> >> The approach of working on Janino is better.
> >>
> >> Enrico
> >>
> >> Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
> >> scritto:
> >>
> >>>
> >>>
> >>> Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
> > scritto:
> >>>
>  I have reproduced it in Janino only and created the issue:
>  https://github.com/janino-compiler/janino/issues/47
> >>>
> >>>
> >>> Great work Vova,
> >>> Thank you
> >>>
> >>> Enrico
> >>>
> >>>
> >>>
> 
> 
> 
>  Kind regards,
>  Volodymyr Vysotskyi
> 
>  2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
> 
> > Ok, I will try to prepare a test case and will log a bug on
> >> Janino
> >> soon.
> >
> > Kind regards,
> > Volodymyr Vysotskyi
> >
> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> >
> >> Vova,
> >>
> >> Thanks for doing the research. Your explanation sounds very
> > plausible
> >> (I suspected default methods, too). Can you please log a bug on
> >> JANINO? https://github.com/janino-compiler/janino/issues Arno,
> > the
> >> project maintainer, has been very good to us over the years.
> >>
> >> Julian
> >>
> >>
> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
> >> eolive...@gmail.com>
> >> wrote:
> >>> Il sab 14 apr 2018, 18:20 Enrico Olivelli <
> >> eolive...@gmail.com>
> > ha
> >> scritto:
> >>>
> 
> 
>  Il sab 14 apr 2018, 17:39 Vova Vysotskyi 
> > ha
> >> scritto:
> 
> > Hi all,
> >
> > I think the reason for this issue is that at the compile
> > stage
> >> was
> >> assumed
> > that *getSubSchema()* method returns *Schema *inheritor,
> >> but
> > not
> > *SchemaPlus*.
> > But the interesting thing is that with Java 8, methods list
> > of
> > *SchemaPlus *interface
> > contains default *getSubSchema()* method.
> > It may be observed by executing this code:
> > *Method[] declaredMethods =
> >
> >
> >> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
> >> laredMethods();*
> > *for (Method m : declaredMethods) {*
> > *  if (m.getName().equals("getSubSchema")) {*
> > *System.out.println(m);*
> > *  }*
> > *}*
> >
> > Its output:
> >
> > *public default org.apache.calcite.schema.Schema
> >
> 
> >>

Re: JDK 8 syntax

2018-08-28 Thread Julian Hyde

Excellent. Can you commit the fix please, Vova?

> On Aug 28, 2018, at 10:34 AM, Vova Vysotskyi  wrote:
> 
> Hi all,
> 
> Janino issue  with
> this "strange" default method was fixed, so now we can revert the temporary
> fix made in CALCITE-2261
>  and update Janino
> version to 3.0.9.
> 
> Kind regards,
> Volodymyr Vysotskyi
> 
> 
> On Sat, Apr 21, 2018 at 11:27 AM Enrico Olivelli 
> wrote:
> 
>> Patch merged!
>> 
>> Welcome to java 8 !
>> 
>> Enrico
>> 
>> Il mar 17 apr 2018, 17:09 Enrico Olivelli  ha
>> scritto:
>> 
>>> Issue
>>> https://issues.apache.org/jira/browse/CALCITE-2261
>>> 
>>> Patch
>>> https://github.com/apache/calcite/pull/667
>>> 
>>> Cheers
>>> Enrico
>>> 
>>> 
>>> 2018-04-17 16:51 GMT+02:00 Enrico Olivelli :
>>> 
 Vova,
 I tried to add some "default" methods and all tests are passing (maybe
 you already saw this).
 Thank you !
 
 I will be happy to contribute my patch as it is really simple and I have
 it on my laptop
 
 Enrico
 
 
 2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :
 
> Taking a step to the side of a workaround, the current version of
>> Janino
> prefers default methods instead of "abstract", so we may declare
> *SchemaPlus.getSubSchema()* method as default and it will help to
>> choose
> this method instead of the method from the parent interface :)
> 
> Kind regards,
> Volodymyr Vysotskyi
> 
> 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
> 
>> I have tried to add an 'unwrap' method to Schema but then Janino
>> keeps
>> breaking for other similar reasons about method overriding with
> narrower
>> return types.
>> 
>> I guess it will be an hard task to adapt Calcite code.
>> The approach of working on Janino is better.
>> 
>> Enrico
>> 
>> Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
>> scritto:
>> 
>>> 
>>> 
>>> Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
> scritto:
>>> 
 I have reproduced it in Janino only and created the issue:
 https://github.com/janino-compiler/janino/issues/47
>>> 
>>> 
>>> Great work Vova,
>>> Thank you
>>> 
>>> Enrico
>>> 
>>> 
>>> 
 
 
 
 Kind regards,
 Volodymyr Vysotskyi
 
 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
 
> Ok, I will try to prepare a test case and will log a bug on
>> Janino
>> soon.
> 
> Kind regards,
> Volodymyr Vysotskyi
> 
> 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> 
>> Vova,
>> 
>> Thanks for doing the research. Your explanation sounds very
> plausible
>> (I suspected default methods, too). Can you please log a bug on
>> JANINO? https://github.com/janino-compiler/janino/issues Arno,
> the
>> project maintainer, has been very good to us over the years.
>> 
>> Julian
>> 
>> 
>> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
>> eolive...@gmail.com>
>> wrote:
>>> Il sab 14 apr 2018, 18:20 Enrico Olivelli <
>> eolive...@gmail.com>
> ha
>> scritto:
>>> 
 
 
 Il sab 14 apr 2018, 17:39 Vova Vysotskyi 
> ha
>> scritto:
 
> Hi all,
> 
> I think the reason for this issue is that at the compile
> stage
>> was
>> assumed
> that *getSubSchema()* method returns *Schema *inheritor,
>> but
> not
> *SchemaPlus*.
> But the interesting thing is that with Java 8, methods list
> of
> *SchemaPlus *interface
> contains default *getSubSchema()* method.
> It may be observed by executing this code:
> *Method[] declaredMethods =
> 
> 
>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
>> laredMethods();*
> *for (Method m : declaredMethods) {*
> *  if (m.getName().equals("getSubSchema")) {*
> *System.out.println(m);*
> *  }*
> *}*
> 
> Its output:
> 
> *public default org.apache.calcite.schema.Schema
> 
 
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> *public abstract org.apache.calcite.schema.SchemaPlus
> 
 
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> 
> The output of the same code for Java 7:
> 
> *public abstract org.apache.calcite.schema.SchemaPlus
> 
 
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*

Re: JDK 8 syntax

2018-08-28 Thread Vova Vysotskyi

Hi all,

Janino issue  with
this "strange" default method was fixed, so now we can revert the temporary
fix made in CALCITE-2261
 and update Janino
version to 3.0.9.

Kind regards,
Volodymyr Vysotskyi


On Sat, Apr 21, 2018 at 11:27 AM Enrico Olivelli 
wrote:

> Patch merged!
>
> Welcome to java 8 !
>
> Enrico
>
> Il mar 17 apr 2018, 17:09 Enrico Olivelli  ha
> scritto:
>
> > Issue
> > https://issues.apache.org/jira/browse/CALCITE-2261
> >
> > Patch
> > https://github.com/apache/calcite/pull/667
> >
> > Cheers
> > Enrico
> >
> >
> > 2018-04-17 16:51 GMT+02:00 Enrico Olivelli :
> >
> >> Vova,
> >> I tried to add some "default" methods and all tests are passing (maybe
> >> you already saw this).
> >> Thank you !
> >>
> >> I will be happy to contribute my patch as it is really simple and I have
> >> it on my laptop
> >>
> >> Enrico
> >>
> >>
> >> 2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :
> >>
> >>> Taking a step to the side of a workaround, the current version of
> Janino
> >>> prefers default methods instead of "abstract", so we may declare
> >>> *SchemaPlus.getSubSchema()* method as default and it will help to
> choose
> >>> this method instead of the method from the parent interface :)
> >>>
> >>> Kind regards,
> >>> Volodymyr Vysotskyi
> >>>
> >>> 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
> >>>
> >>> > I have tried to add an 'unwrap' method to Schema but then Janino
> keeps
> >>> > breaking for other similar reasons about method overriding with
> >>> narrower
> >>> > return types.
> >>> >
> >>> > I guess it will be an hard task to adapt Calcite code.
> >>> > The approach of working on Janino is better.
> >>> >
> >>> > Enrico
> >>> >
> >>> > Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
> >>> > scritto:
> >>> >
> >>> > >
> >>> > >
> >>> > > Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
> >>> scritto:
> >>> > >
> >>> > >> I have reproduced it in Janino only and created the issue:
> >>> > >> https://github.com/janino-compiler/janino/issues/47
> >>> > >
> >>> > >
> >>> > > Great work Vova,
> >>> > > Thank you
> >>> > >
> >>> > > Enrico
> >>> > >
> >>> > >
> >>> > >
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >> Kind regards,
> >>> > >> Volodymyr Vysotskyi
> >>> > >>
> >>> > >> 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
> >>> > >>
> >>> > >> > Ok, I will try to prepare a test case and will log a bug on
> Janino
> >>> > soon.
> >>> > >> >
> >>> > >> > Kind regards,
> >>> > >> > Volodymyr Vysotskyi
> >>> > >> >
> >>> > >> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> >>> > >> >
> >>> > >> >> Vova,
> >>> > >> >>
> >>> > >> >> Thanks for doing the research. Your explanation sounds very
> >>> plausible
> >>> > >> >> (I suspected default methods, too). Can you please log a bug on
> >>> > >> >> JANINO? https://github.com/janino-compiler/janino/issues Arno,
> >>> the
> >>> > >> >> project maintainer, has been very good to us over the years.
> >>> > >> >>
> >>> > >> >> Julian
> >>> > >> >>
> >>> > >> >>
> >>> > >> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
> >>> > eolive...@gmail.com>
> >>> > >> >> wrote:
> >>> > >> >> > Il sab 14 apr 2018, 18:20 Enrico Olivelli <
> eolive...@gmail.com>
> >>> ha
> >>> > >> >> scritto:
> >>> > >> >> >
> >>> > >> >> >>
> >>> > >> >> >>
> >>> > >> >> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi 
> >>> ha
> >>> > >> >> scritto:
> >>> > >> >> >>
> >>> > >> >> >>> Hi all,
> >>> > >> >> >>>
> >>> > >> >> >>> I think the reason for this issue is that at the compile
> >>> stage
> >>> > was
> >>> > >> >> assumed
> >>> > >> >> >>> that *getSubSchema()* method returns *Schema *inheritor,
> but
> >>> not
> >>> > >> >> >>> *SchemaPlus*.
> >>> > >> >> >>> But the interesting thing is that with Java 8, methods list
> >>> of
> >>> > >> >> >>> *SchemaPlus *interface
> >>> > >> >> >>> contains default *getSubSchema()* method.
> >>> > >> >> >>> It may be observed by executing this code:
> >>> > >> >> >>> *Method[] declaredMethods =
> >>> > >> >> >>>
> >>> > >> >> >>>
> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
> >>> > >> >> laredMethods();*
> >>> > >> >> >>> *for (Method m : declaredMethods) {*
> >>> > >> >> >>> *  if (m.getName().equals("getSubSchema")) {*
> >>> > >> >> >>> *System.out.println(m);*
> >>> > >> >> >>> *  }*
> >>> > >> >> >>> *}*
> >>> > >> >> >>>
> >>> > >> >> >>> Its output:
> >>> > >> >> >>>
> >>> > >> >> >>> *public default org.apache.calcite.schema.Schema
> >>> > >> >> >>>
> >>> > >>
> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >>> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >>> > >> >> >>>
> >>> > >>
> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >>> > >> >> >>>
> >>> > >> >> >>> The output of the same code for Java 7:
> >>> > >> >> >>>
> >>> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >>> > >> >> >>>
> >>> > >>
>

Re: JDK 8 syntax

2018-04-21 Thread Enrico Olivelli

Patch merged!

Welcome to java 8 !

Enrico

Il mar 17 apr 2018, 17:09 Enrico Olivelli  ha scritto:

> Issue
> https://issues.apache.org/jira/browse/CALCITE-2261
>
> Patch
> https://github.com/apache/calcite/pull/667
>
> Cheers
> Enrico
>
>
> 2018-04-17 16:51 GMT+02:00 Enrico Olivelli :
>
>> Vova,
>> I tried to add some "default" methods and all tests are passing (maybe
>> you already saw this).
>> Thank you !
>>
>> I will be happy to contribute my patch as it is really simple and I have
>> it on my laptop
>>
>> Enrico
>>
>>
>> 2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :
>>
>>> Taking a step to the side of a workaround, the current version of Janino
>>> prefers default methods instead of "abstract", so we may declare
>>> *SchemaPlus.getSubSchema()* method as default and it will help to choose
>>> this method instead of the method from the parent interface :)
>>>
>>> Kind regards,
>>> Volodymyr Vysotskyi
>>>
>>> 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
>>>
>>> > I have tried to add an 'unwrap' method to Schema but then Janino keeps
>>> > breaking for other similar reasons about method overriding with
>>> narrower
>>> > return types.
>>> >
>>> > I guess it will be an hard task to adapt Calcite code.
>>> > The approach of working on Janino is better.
>>> >
>>> > Enrico
>>> >
>>> > Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
>>> > scritto:
>>> >
>>> > >
>>> > >
>>> > > Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
>>> scritto:
>>> > >
>>> > >> I have reproduced it in Janino only and created the issue:
>>> > >> https://github.com/janino-compiler/janino/issues/47
>>> > >
>>> > >
>>> > > Great work Vova,
>>> > > Thank you
>>> > >
>>> > > Enrico
>>> > >
>>> > >
>>> > >
>>> > >>
>>> > >>
>>> > >>
>>> > >> Kind regards,
>>> > >> Volodymyr Vysotskyi
>>> > >>
>>> > >> 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
>>> > >>
>>> > >> > Ok, I will try to prepare a test case and will log a bug on Janino
>>> > soon.
>>> > >> >
>>> > >> > Kind regards,
>>> > >> > Volodymyr Vysotskyi
>>> > >> >
>>> > >> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
>>> > >> >
>>> > >> >> Vova,
>>> > >> >>
>>> > >> >> Thanks for doing the research. Your explanation sounds very
>>> plausible
>>> > >> >> (I suspected default methods, too). Can you please log a bug on
>>> > >> >> JANINO? https://github.com/janino-compiler/janino/issues Arno,
>>> the
>>> > >> >> project maintainer, has been very good to us over the years.
>>> > >> >>
>>> > >> >> Julian
>>> > >> >>
>>> > >> >>
>>> > >> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
>>> > eolive...@gmail.com>
>>> > >> >> wrote:
>>> > >> >> > Il sab 14 apr 2018, 18:20 Enrico Olivelli 
>>> ha
>>> > >> >> scritto:
>>> > >> >> >
>>> > >> >> >>
>>> > >> >> >>
>>> > >> >> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi 
>>> ha
>>> > >> >> scritto:
>>> > >> >> >>
>>> > >> >> >>> Hi all,
>>> > >> >> >>>
>>> > >> >> >>> I think the reason for this issue is that at the compile
>>> stage
>>> > was
>>> > >> >> assumed
>>> > >> >> >>> that *getSubSchema()* method returns *Schema *inheritor, but
>>> not
>>> > >> >> >>> *SchemaPlus*.
>>> > >> >> >>> But the interesting thing is that with Java 8, methods list
>>> of
>>> > >> >> >>> *SchemaPlus *interface
>>> > >> >> >>> contains default *getSubSchema()* method.
>>> > >> >> >>> It may be observed by executing this code:
>>> > >> >> >>> *Method[] declaredMethods =
>>> > >> >> >>>
>>> > >> >> >>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
>>> > >> >> laredMethods();*
>>> > >> >> >>> *for (Method m : declaredMethods) {*
>>> > >> >> >>> *  if (m.getName().equals("getSubSchema")) {*
>>> > >> >> >>> *System.out.println(m);*
>>> > >> >> >>> *  }*
>>> > >> >> >>> *}*
>>> > >> >> >>>
>>> > >> >> >>> Its output:
>>> > >> >> >>>
>>> > >> >> >>> *public default org.apache.calcite.schema.Schema
>>> > >> >> >>>
>>> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>>> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
>>> > >> >> >>>
>>> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>>> > >> >> >>>
>>> > >> >> >>> The output of the same code for Java 7:
>>> > >> >> >>>
>>> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
>>> > >> >> >>>
>>> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>>> > >> >> >>>
>>> > >> >> >>> Kind regards,
>>> > >> >> >>> Volodymyr Vysotskyi
>>> > >> >> >>>
>>> > >> >> >>
>>> > >> >> >> Good catch!
>>> > >> >> >> It would be useful to look into that 'default' method by
>>> > >> disassembling
>>> > >> >> >> .class file.
>>> > >> >> >> Enrico
>>> > >> >> >>
>>> > >> >> >
>>> > >> >> > Anyway a fix would be to add an unwrap method to Schema
>>> > >> >> > Cheers
>>> > >> >> > Enrico
>>> > >> >> >
>>> > >> >> >

Re: JDK 8 syntax

2018-04-17 Thread Enrico Olivelli

Issue
https://issues.apache.org/jira/browse/CALCITE-2261

Patch
https://github.com/apache/calcite/pull/667

Cheers
Enrico


2018-04-17 16:51 GMT+02:00 Enrico Olivelli :

> Vova,
> I tried to add some "default" methods and all tests are passing (maybe you
> already saw this).
> Thank you !
>
> I will be happy to contribute my patch as it is really simple and I have
> it on my laptop
>
> Enrico
>
>
> 2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :
>
>> Taking a step to the side of a workaround, the current version of Janino
>> prefers default methods instead of "abstract", so we may declare
>> *SchemaPlus.getSubSchema()* method as default and it will help to choose
>> this method instead of the method from the parent interface :)
>>
>> Kind regards,
>> Volodymyr Vysotskyi
>>
>> 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
>>
>> > I have tried to add an 'unwrap' method to Schema but then Janino keeps
>> > breaking for other similar reasons about method overriding with narrower
>> > return types.
>> >
>> > I guess it will be an hard task to adapt Calcite code.
>> > The approach of working on Janino is better.
>> >
>> > Enrico
>> >
>> > Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
>> > scritto:
>> >
>> > >
>> > >
>> > > Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
>> scritto:
>> > >
>> > >> I have reproduced it in Janino only and created the issue:
>> > >> https://github.com/janino-compiler/janino/issues/47
>> > >
>> > >
>> > > Great work Vova,
>> > > Thank you
>> > >
>> > > Enrico
>> > >
>> > >
>> > >
>> > >>
>> > >>
>> > >>
>> > >> Kind regards,
>> > >> Volodymyr Vysotskyi
>> > >>
>> > >> 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
>> > >>
>> > >> > Ok, I will try to prepare a test case and will log a bug on Janino
>> > soon.
>> > >> >
>> > >> > Kind regards,
>> > >> > Volodymyr Vysotskyi
>> > >> >
>> > >> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
>> > >> >
>> > >> >> Vova,
>> > >> >>
>> > >> >> Thanks for doing the research. Your explanation sounds very
>> plausible
>> > >> >> (I suspected default methods, too). Can you please log a bug on
>> > >> >> JANINO? https://github.com/janino-compiler/janino/issues Arno,
>> the
>> > >> >> project maintainer, has been very good to us over the years.
>> > >> >>
>> > >> >> Julian
>> > >> >>
>> > >> >>
>> > >> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
>> > eolive...@gmail.com>
>> > >> >> wrote:
>> > >> >> > Il sab 14 apr 2018, 18:20 Enrico Olivelli 
>> ha
>> > >> >> scritto:
>> > >> >> >
>> > >> >> >>
>> > >> >> >>
>> > >> >> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha
>> > >> >> scritto:
>> > >> >> >>
>> > >> >> >>> Hi all,
>> > >> >> >>>
>> > >> >> >>> I think the reason for this issue is that at the compile stage
>> > was
>> > >> >> assumed
>> > >> >> >>> that *getSubSchema()* method returns *Schema *inheritor, but
>> not
>> > >> >> >>> *SchemaPlus*.
>> > >> >> >>> But the interesting thing is that with Java 8, methods list of
>> > >> >> >>> *SchemaPlus *interface
>> > >> >> >>> contains default *getSubSchema()* method.
>> > >> >> >>> It may be observed by executing this code:
>> > >> >> >>> *Method[] declaredMethods =
>> > >> >> >>>
>> > >> >> >>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
>> > >> >> laredMethods();*
>> > >> >> >>> *for (Method m : declaredMethods) {*
>> > >> >> >>> *  if (m.getName().equals("getSubSchema")) {*
>> > >> >> >>> *System.out.println(m);*
>> > >> >> >>> *  }*
>> > >> >> >>> *}*
>> > >> >> >>>
>> > >> >> >>> Its output:
>> > >> >> >>>
>> > >> >> >>> *public default org.apache.calcite.schema.Schema
>> > >> >> >>>
>> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
>> > >> >> >>>
>> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> > >> >> >>>
>> > >> >> >>> The output of the same code for Java 7:
>> > >> >> >>>
>> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
>> > >> >> >>>
>> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> > >> >> >>>
>> > >> >> >>> Kind regards,
>> > >> >> >>> Volodymyr Vysotskyi
>> > >> >> >>>
>> > >> >> >>
>> > >> >> >> Good catch!
>> > >> >> >> It would be useful to look into that 'default' method by
>> > >> disassembling
>> > >> >> >> .class file.
>> > >> >> >> Enrico
>> > >> >> >>
>> > >> >> >
>> > >> >> > Anyway a fix would be to add an unwrap method to Schema
>> > >> >> > Cheers
>> > >> >> > Enrico
>> > >> >> >
>> > >> >> >
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>> 2018-04-10 18:43 GMT+03:00 Julian Hyde <
>> jhyde.apa...@gmail.com>:
>> > >> >> >>>
>> > >> >> >>> > I’d really appreciate that.
>> > >> >> >>> >
>> > >> >> >>> > Can you please log a JIRA case, and record your
>> > >> >> observations/progress
>> > >> >>

Re: JDK 8 syntax

2018-04-17 Thread Enrico Olivelli

Vova,
I tried to add some "default" methods and all tests are passing (maybe you
already saw this).
Thank you !

I will be happy to contribute my patch as it is really simple and I have it
on my laptop

Enrico


2018-04-17 15:49 GMT+02:00 Vova Vysotskyi :

> Taking a step to the side of a workaround, the current version of Janino
> prefers default methods instead of "abstract", so we may declare
> *SchemaPlus.getSubSchema()* method as default and it will help to choose
> this method instead of the method from the parent interface :)
>
> Kind regards,
> Volodymyr Vysotskyi
>
> 2018-04-17 15:10 GMT+03:00 Enrico Olivelli :
>
> > I have tried to add an 'unwrap' method to Schema but then Janino keeps
> > breaking for other similar reasons about method overriding with narrower
> > return types.
> >
> > I guess it will be an hard task to adapt Calcite code.
> > The approach of working on Janino is better.
> >
> > Enrico
> >
> > Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
> > scritto:
> >
> > >
> > >
> > > Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha
> scritto:
> > >
> > >> I have reproduced it in Janino only and created the issue:
> > >> https://github.com/janino-compiler/janino/issues/47
> > >
> > >
> > > Great work Vova,
> > > Thank you
> > >
> > > Enrico
> > >
> > >
> > >
> > >>
> > >>
> > >>
> > >> Kind regards,
> > >> Volodymyr Vysotskyi
> > >>
> > >> 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
> > >>
> > >> > Ok, I will try to prepare a test case and will log a bug on Janino
> > soon.
> > >> >
> > >> > Kind regards,
> > >> > Volodymyr Vysotskyi
> > >> >
> > >> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> > >> >
> > >> >> Vova,
> > >> >>
> > >> >> Thanks for doing the research. Your explanation sounds very
> plausible
> > >> >> (I suspected default methods, too). Can you please log a bug on
> > >> >> JANINO? https://github.com/janino-compiler/janino/issues Arno, the
> > >> >> project maintainer, has been very good to us over the years.
> > >> >>
> > >> >> Julian
> > >> >>
> > >> >>
> > >> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
> > eolive...@gmail.com>
> > >> >> wrote:
> > >> >> > Il sab 14 apr 2018, 18:20 Enrico Olivelli 
> ha
> > >> >> scritto:
> > >> >> >
> > >> >> >>
> > >> >> >>
> > >> >> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha
> > >> >> scritto:
> > >> >> >>
> > >> >> >>> Hi all,
> > >> >> >>>
> > >> >> >>> I think the reason for this issue is that at the compile stage
> > was
> > >> >> assumed
> > >> >> >>> that *getSubSchema()* method returns *Schema *inheritor, but
> not
> > >> >> >>> *SchemaPlus*.
> > >> >> >>> But the interesting thing is that with Java 8, methods list of
> > >> >> >>> *SchemaPlus *interface
> > >> >> >>> contains default *getSubSchema()* method.
> > >> >> >>> It may be observed by executing this code:
> > >> >> >>> *Method[] declaredMethods =
> > >> >> >>>
> > >> >> >>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
> > >> >> laredMethods();*
> > >> >> >>> *for (Method m : declaredMethods) {*
> > >> >> >>> *  if (m.getName().equals("getSubSchema")) {*
> > >> >> >>> *System.out.println(m);*
> > >> >> >>> *  }*
> > >> >> >>> *}*
> > >> >> >>>
> > >> >> >>> Its output:
> > >> >> >>>
> > >> >> >>> *public default org.apache.calcite.schema.Schema
> > >> >> >>>
> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> > >> >> >>>
> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> > >> >> >>>
> > >> >> >>> The output of the same code for Java 7:
> > >> >> >>>
> > >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> > >> >> >>>
> > >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> > >> >> >>>
> > >> >> >>> Kind regards,
> > >> >> >>> Volodymyr Vysotskyi
> > >> >> >>>
> > >> >> >>
> > >> >> >> Good catch!
> > >> >> >> It would be useful to look into that 'default' method by
> > >> disassembling
> > >> >> >> .class file.
> > >> >> >> Enrico
> > >> >> >>
> > >> >> >
> > >> >> > Anyway a fix would be to add an unwrap method to Schema
> > >> >> > Cheers
> > >> >> > Enrico
> > >> >> >
> > >> >> >
> > >> >> >>
> > >> >> >>
> > >> >> >>> 2018-04-10 18:43 GMT+03:00 Julian Hyde  >:
> > >> >> >>>
> > >> >> >>> > I’d really appreciate that.
> > >> >> >>> >
> > >> >> >>> > Can you please log a JIRA case, and record your
> > >> >> observations/progress
> > >> >> >>> > there.
> > >> >> >>> >
> > >> >> >>> > There’s no particular hurry on this one.
> > >> >> >>> >
> > >> >> >>> > Julian
> > >> >> >>> >
> > >> >> >>> > > On Apr 10, 2018, at 06:32, Enrico Olivelli <
> > >> eolive...@gmail.com>
> > >> >> >>> wrote:
> > >> >> >>> > >
> > >> >> >>> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde <
> > jhyde.apa...@gmail.com

Re: JDK 8 syntax

2018-04-17 Thread Vova Vysotskyi

Taking a step to the side of a workaround, the current version of Janino
prefers default methods instead of "abstract", so we may declare
*SchemaPlus.getSubSchema()* method as default and it will help to choose
this method instead of the method from the parent interface :)

Kind regards,
Volodymyr Vysotskyi

2018-04-17 15:10 GMT+03:00 Enrico Olivelli :

> I have tried to add an 'unwrap' method to Schema but then Janino keeps
> breaking for other similar reasons about method overriding with narrower
> return types.
>
> I guess it will be an hard task to adapt Calcite code.
> The approach of working on Janino is better.
>
> Enrico
>
> Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha
> scritto:
>
> >
> >
> > Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha scritto:
> >
> >> I have reproduced it in Janino only and created the issue:
> >> https://github.com/janino-compiler/janino/issues/47
> >
> >
> > Great work Vova,
> > Thank you
> >
> > Enrico
> >
> >
> >
> >>
> >>
> >>
> >> Kind regards,
> >> Volodymyr Vysotskyi
> >>
> >> 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
> >>
> >> > Ok, I will try to prepare a test case and will log a bug on Janino
> soon.
> >> >
> >> > Kind regards,
> >> > Volodymyr Vysotskyi
> >> >
> >> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> >> >
> >> >> Vova,
> >> >>
> >> >> Thanks for doing the research. Your explanation sounds very plausible
> >> >> (I suspected default methods, too). Can you please log a bug on
> >> >> JANINO? https://github.com/janino-compiler/janino/issues Arno, the
> >> >> project maintainer, has been very good to us over the years.
> >> >>
> >> >> Julian
> >> >>
> >> >>
> >> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli <
> eolive...@gmail.com>
> >> >> wrote:
> >> >> > Il sab 14 apr 2018, 18:20 Enrico Olivelli  ha
> >> >> scritto:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha
> >> >> scritto:
> >> >> >>
> >> >> >>> Hi all,
> >> >> >>>
> >> >> >>> I think the reason for this issue is that at the compile stage
> was
> >> >> assumed
> >> >> >>> that *getSubSchema()* method returns *Schema *inheritor, but not
> >> >> >>> *SchemaPlus*.
> >> >> >>> But the interesting thing is that with Java 8, methods list of
> >> >> >>> *SchemaPlus *interface
> >> >> >>> contains default *getSubSchema()* method.
> >> >> >>> It may be observed by executing this code:
> >> >> >>> *Method[] declaredMethods =
> >> >> >>>
> >> >> >>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
> >> >> laredMethods();*
> >> >> >>> *for (Method m : declaredMethods) {*
> >> >> >>> *  if (m.getName().equals("getSubSchema")) {*
> >> >> >>> *System.out.println(m);*
> >> >> >>> *  }*
> >> >> >>> *}*
> >> >> >>>
> >> >> >>> Its output:
> >> >> >>>
> >> >> >>> *public default org.apache.calcite.schema.Schema
> >> >> >>>
> >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >> >> >>>
> >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >> >> >>>
> >> >> >>> The output of the same code for Java 7:
> >> >> >>>
> >> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >> >> >>>
> >> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >> >> >>>
> >> >> >>> Kind regards,
> >> >> >>> Volodymyr Vysotskyi
> >> >> >>>
> >> >> >>
> >> >> >> Good catch!
> >> >> >> It would be useful to look into that 'default' method by
> >> disassembling
> >> >> >> .class file.
> >> >> >> Enrico
> >> >> >>
> >> >> >
> >> >> > Anyway a fix would be to add an unwrap method to Schema
> >> >> > Cheers
> >> >> > Enrico
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>> 2018-04-10 18:43 GMT+03:00 Julian Hyde :
> >> >> >>>
> >> >> >>> > I’d really appreciate that.
> >> >> >>> >
> >> >> >>> > Can you please log a JIRA case, and record your
> >> >> observations/progress
> >> >> >>> > there.
> >> >> >>> >
> >> >> >>> > There’s no particular hurry on this one.
> >> >> >>> >
> >> >> >>> > Julian
> >> >> >>> >
> >> >> >>> > > On Apr 10, 2018, at 06:32, Enrico Olivelli <
> >> eolive...@gmail.com>
> >> >> >>> wrote:
> >> >> >>> > >
> >> >> >>> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde <
> jhyde.apa...@gmail.com
> >> >:
> >> >> >>> > >
> >> >> >>> > >> Yes, that’s it.
> >> >> >>> > >>
> >> >> >>> > >> Next step would be to check whether the generated code is
> the
> >> >> same as
> >> >> >>> > >> previously, and if so, it is a Janino bug. Then try to
> create
> >> a
> >> >> >>> minimal
> >> >> >>> > >> test case for Janino. Maybe we can work around by adding an
> >> >> explicit
> >> >> >>> > cast
> >> >> >>> > >> somewhere.
> >> >> >>> > >>
> >> >> >>> > >> Thanks for reproducing this, and trying the Janino upgrade.
> >> >> >>> > >>
> >> >> >>> > >
> >> >> >>> > >
> >> >> >>>

Re: JDK 8 syntax

2018-04-17 Thread Enrico Olivelli

I have tried to add an 'unwrap' method to Schema but then Janino keeps
breaking for other similar reasons about method overriding with narrower
return types.

I guess it will be an hard task to adapt Calcite code.
The approach of working on Janino is better.

Enrico

Il dom 15 apr 2018, 14:43 Enrico Olivelli  ha scritto:

>
>
> Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha scritto:
>
>> I have reproduced it in Janino only and created the issue:
>> https://github.com/janino-compiler/janino/issues/47
>
>
> Great work Vova,
> Thank you
>
> Enrico
>
>
>
>>
>>
>>
>> Kind regards,
>> Volodymyr Vysotskyi
>>
>> 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
>>
>> > Ok, I will try to prepare a test case and will log a bug on Janino soon.
>> >
>> > Kind regards,
>> > Volodymyr Vysotskyi
>> >
>> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
>> >
>> >> Vova,
>> >>
>> >> Thanks for doing the research. Your explanation sounds very plausible
>> >> (I suspected default methods, too). Can you please log a bug on
>> >> JANINO? https://github.com/janino-compiler/janino/issues Arno, the
>> >> project maintainer, has been very good to us over the years.
>> >>
>> >> Julian
>> >>
>> >>
>> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli 
>> >> wrote:
>> >> > Il sab 14 apr 2018, 18:20 Enrico Olivelli  ha
>> >> scritto:
>> >> >
>> >> >>
>> >> >>
>> >> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha
>> >> scritto:
>> >> >>
>> >> >>> Hi all,
>> >> >>>
>> >> >>> I think the reason for this issue is that at the compile stage was
>> >> assumed
>> >> >>> that *getSubSchema()* method returns *Schema *inheritor, but not
>> >> >>> *SchemaPlus*.
>> >> >>> But the interesting thing is that with Java 8, methods list of
>> >> >>> *SchemaPlus *interface
>> >> >>> contains default *getSubSchema()* method.
>> >> >>> It may be observed by executing this code:
>> >> >>> *Method[] declaredMethods =
>> >> >>>
>> >> >>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
>> >> laredMethods();*
>> >> >>> *for (Method m : declaredMethods) {*
>> >> >>> *  if (m.getName().equals("getSubSchema")) {*
>> >> >>> *System.out.println(m);*
>> >> >>> *  }*
>> >> >>> *}*
>> >> >>>
>> >> >>> Its output:
>> >> >>>
>> >> >>> *public default org.apache.calcite.schema.Schema
>> >> >>>
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
>> >> >>>
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> >> >>>
>> >> >>> The output of the same code for Java 7:
>> >> >>>
>> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
>> >> >>>
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> >> >>>
>> >> >>> Kind regards,
>> >> >>> Volodymyr Vysotskyi
>> >> >>>
>> >> >>
>> >> >> Good catch!
>> >> >> It would be useful to look into that 'default' method by
>> disassembling
>> >> >> .class file.
>> >> >> Enrico
>> >> >>
>> >> >
>> >> > Anyway a fix would be to add an unwrap method to Schema
>> >> > Cheers
>> >> > Enrico
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >>> 2018-04-10 18:43 GMT+03:00 Julian Hyde :
>> >> >>>
>> >> >>> > I’d really appreciate that.
>> >> >>> >
>> >> >>> > Can you please log a JIRA case, and record your
>> >> observations/progress
>> >> >>> > there.
>> >> >>> >
>> >> >>> > There’s no particular hurry on this one.
>> >> >>> >
>> >> >>> > Julian
>> >> >>> >
>> >> >>> > > On Apr 10, 2018, at 06:32, Enrico Olivelli <
>> eolive...@gmail.com>
>> >> >>> wrote:
>> >> >>> > >
>> >> >>> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde > >:
>> >> >>> > >
>> >> >>> > >> Yes, that’s it.
>> >> >>> > >>
>> >> >>> > >> Next step would be to check whether the generated code is the
>> >> same as
>> >> >>> > >> previously, and if so, it is a Janino bug. Then try to create
>> a
>> >> >>> minimal
>> >> >>> > >> test case for Janino. Maybe we can work around by adding an
>> >> explicit
>> >> >>> > cast
>> >> >>> > >> somewhere.
>> >> >>> > >>
>> >> >>> > >> Thanks for reproducing this, and trying the Janino upgrade.
>> >> >>> > >>
>> >> >>> > >
>> >> >>> > >
>> >> >>> > > Julian,
>> >> >>> > > If you have no hurry for this I will be happy to spend some
>> time
>> >> in
>> >> >>> order
>> >> >>> > > to figure out the root cause.
>> >> >>> > >
>> >> >>> > > I will follow the discussion and jump in when I have some idea.
>> >> >>> > >
>> >> >>> > > It will be great to have Calcite really built on jdk8 and
>> leverage
>> >> >>> > lambdas
>> >> >>> > >
>> >> >>> > >
>> >> >>> > > Cheers
>> >> >>> > > Enrico
>> >> >>> > >
>> >> >>> > >
>> >> >>> > >
>> >> >>> > >>
>> >> >>> > >> Julian
>> >> >>> > >>
>> >> >>> > >>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli <
>> >> eolive...@gmail.com>
>> >> >>> > >> wrote:
>> >> >>> > >>>
>> >> >>> > >>> This is

Re: JDK 8 syntax

2018-04-15 Thread Enrico Olivelli

Il dom 15 apr 2018, 14:22 Vova Vysotskyi  ha scritto:

> I have reproduced it in Janino only and created the issue:
> https://github.com/janino-compiler/janino/issues/47


Great work Vova,
Thank you

Enrico



>
>
>
> Kind regards,
> Volodymyr Vysotskyi
>
> 2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :
>
> > Ok, I will try to prepare a test case and will log a bug on Janino soon.
> >
> > Kind regards,
> > Volodymyr Vysotskyi
> >
> > 2018-04-14 20:02 GMT+03:00 Julian Hyde :
> >
> >> Vova,
> >>
> >> Thanks for doing the research. Your explanation sounds very plausible
> >> (I suspected default methods, too). Can you please log a bug on
> >> JANINO? https://github.com/janino-compiler/janino/issues Arno, the
> >> project maintainer, has been very good to us over the years.
> >>
> >> Julian
> >>
> >>
> >> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli 
> >> wrote:
> >> > Il sab 14 apr 2018, 18:20 Enrico Olivelli  ha
> >> scritto:
> >> >
> >> >>
> >> >>
> >> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha
> >> scritto:
> >> >>
> >> >>> Hi all,
> >> >>>
> >> >>> I think the reason for this issue is that at the compile stage was
> >> assumed
> >> >>> that *getSubSchema()* method returns *Schema *inheritor, but not
> >> >>> *SchemaPlus*.
> >> >>> But the interesting thing is that with Java 8, methods list of
> >> >>> *SchemaPlus *interface
> >> >>> contains default *getSubSchema()* method.
> >> >>> It may be observed by executing this code:
> >> >>> *Method[] declaredMethods =
> >> >>>
> >> >>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
> >> laredMethods();*
> >> >>> *for (Method m : declaredMethods) {*
> >> >>> *  if (m.getName().equals("getSubSchema")) {*
> >> >>> *System.out.println(m);*
> >> >>> *  }*
> >> >>> *}*
> >> >>>
> >> >>> Its output:
> >> >>>
> >> >>> *public default org.apache.calcite.schema.Schema
> >> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >> >>>
> >> >>> The output of the same code for Java 7:
> >> >>>
> >> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >> >>>
> >> >>> Kind regards,
> >> >>> Volodymyr Vysotskyi
> >> >>>
> >> >>
> >> >> Good catch!
> >> >> It would be useful to look into that 'default' method by
> disassembling
> >> >> .class file.
> >> >> Enrico
> >> >>
> >> >
> >> > Anyway a fix would be to add an unwrap method to Schema
> >> > Cheers
> >> > Enrico
> >> >
> >> >
> >> >>
> >> >>
> >> >>> 2018-04-10 18:43 GMT+03:00 Julian Hyde :
> >> >>>
> >> >>> > I’d really appreciate that.
> >> >>> >
> >> >>> > Can you please log a JIRA case, and record your
> >> observations/progress
> >> >>> > there.
> >> >>> >
> >> >>> > There’s no particular hurry on this one.
> >> >>> >
> >> >>> > Julian
> >> >>> >
> >> >>> > > On Apr 10, 2018, at 06:32, Enrico Olivelli  >
> >> >>> wrote:
> >> >>> > >
> >> >>> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde  >:
> >> >>> > >
> >> >>> > >> Yes, that’s it.
> >> >>> > >>
> >> >>> > >> Next step would be to check whether the generated code is the
> >> same as
> >> >>> > >> previously, and if so, it is a Janino bug. Then try to create a
> >> >>> minimal
> >> >>> > >> test case for Janino. Maybe we can work around by adding an
> >> explicit
> >> >>> > cast
> >> >>> > >> somewhere.
> >> >>> > >>
> >> >>> > >> Thanks for reproducing this, and trying the Janino upgrade.
> >> >>> > >>
> >> >>> > >
> >> >>> > >
> >> >>> > > Julian,
> >> >>> > > If you have no hurry for this I will be happy to spend some time
> >> in
> >> >>> order
> >> >>> > > to figure out the root cause.
> >> >>> > >
> >> >>> > > I will follow the discussion and jump in when I have some idea.
> >> >>> > >
> >> >>> > > It will be great to have Calcite really built on jdk8 and
> leverage
> >> >>> > lambdas
> >> >>> > >
> >> >>> > >
> >> >>> > > Cheers
> >> >>> > > Enrico
> >> >>> > >
> >> >>> > >
> >> >>> > >
> >> >>> > >>
> >> >>> > >> Julian
> >> >>> > >>
> >> >>> > >>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli <
> >> eolive...@gmail.com>
> >> >>> > >> wrote:
> >> >>> > >>>
> >> >>> > >>> This is "the" error (see below). Unfortunately just be
> upgrading
> >> >>> Janino
> >> >>> > >> to
> >> >>> > >>> 3.0.8 the problem still is present.
> >> >>> > >>>
> >> >>> > >>> the only 'unwrap'  word in the generated code is here
> >> >>> > >>> ...
> >> >>> > >>> public org.apache.calcite.linq4j.Enumerable bind(final
> >> >>> > >>> org.apache.calcite.DataContext root0) {
> >> >>> > >>> root = root0;
> >> >>> > >>> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> >> >>> > >>>

Re: JDK 8 syntax

2018-04-15 Thread Vova Vysotskyi

I have reproduced it in Janino only and created the issue:
https://github.com/janino-compiler/janino/issues/47

Kind regards,
Volodymyr Vysotskyi

2018-04-14 20:15 GMT+03:00 Vova Vysotskyi :

> Ok, I will try to prepare a test case and will log a bug on Janino soon.
>
> Kind regards,
> Volodymyr Vysotskyi
>
> 2018-04-14 20:02 GMT+03:00 Julian Hyde :
>
>> Vova,
>>
>> Thanks for doing the research. Your explanation sounds very plausible
>> (I suspected default methods, too). Can you please log a bug on
>> JANINO? https://github.com/janino-compiler/janino/issues Arno, the
>> project maintainer, has been very good to us over the years.
>>
>> Julian
>>
>>
>> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli 
>> wrote:
>> > Il sab 14 apr 2018, 18:20 Enrico Olivelli  ha
>> scritto:
>> >
>> >>
>> >>
>> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha
>> scritto:
>> >>
>> >>> Hi all,
>> >>>
>> >>> I think the reason for this issue is that at the compile stage was
>> assumed
>> >>> that *getSubSchema()* method returns *Schema *inheritor, but not
>> >>> *SchemaPlus*.
>> >>> But the interesting thing is that with Java 8, methods list of
>> >>> *SchemaPlus *interface
>> >>> contains default *getSubSchema()* method.
>> >>> It may be observed by executing this code:
>> >>> *Method[] declaredMethods =
>> >>>
>> >>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDec
>> laredMethods();*
>> >>> *for (Method m : declaredMethods) {*
>> >>> *  if (m.getName().equals("getSubSchema")) {*
>> >>> *System.out.println(m);*
>> >>> *  }*
>> >>> *}*
>> >>>
>> >>> Its output:
>> >>>
>> >>> *public default org.apache.calcite.schema.Schema
>> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> >>> *public abstract org.apache.calcite.schema.SchemaPlus
>> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> >>>
>> >>> The output of the same code for Java 7:
>> >>>
>> >>> *public abstract org.apache.calcite.schema.SchemaPlus
>> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> >>>
>> >>> Kind regards,
>> >>> Volodymyr Vysotskyi
>> >>>
>> >>
>> >> Good catch!
>> >> It would be useful to look into that 'default' method by disassembling
>> >> .class file.
>> >> Enrico
>> >>
>> >
>> > Anyway a fix would be to add an unwrap method to Schema
>> > Cheers
>> > Enrico
>> >
>> >
>> >>
>> >>
>> >>> 2018-04-10 18:43 GMT+03:00 Julian Hyde :
>> >>>
>> >>> > I’d really appreciate that.
>> >>> >
>> >>> > Can you please log a JIRA case, and record your
>> observations/progress
>> >>> > there.
>> >>> >
>> >>> > There’s no particular hurry on this one.
>> >>> >
>> >>> > Julian
>> >>> >
>> >>> > > On Apr 10, 2018, at 06:32, Enrico Olivelli 
>> >>> wrote:
>> >>> > >
>> >>> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde :
>> >>> > >
>> >>> > >> Yes, that’s it.
>> >>> > >>
>> >>> > >> Next step would be to check whether the generated code is the
>> same as
>> >>> > >> previously, and if so, it is a Janino bug. Then try to create a
>> >>> minimal
>> >>> > >> test case for Janino. Maybe we can work around by adding an
>> explicit
>> >>> > cast
>> >>> > >> somewhere.
>> >>> > >>
>> >>> > >> Thanks for reproducing this, and trying the Janino upgrade.
>> >>> > >>
>> >>> > >
>> >>> > >
>> >>> > > Julian,
>> >>> > > If you have no hurry for this I will be happy to spend some time
>> in
>> >>> order
>> >>> > > to figure out the root cause.
>> >>> > >
>> >>> > > I will follow the discussion and jump in when I have some idea.
>> >>> > >
>> >>> > > It will be great to have Calcite really built on jdk8 and leverage
>> >>> > lambdas
>> >>> > >
>> >>> > >
>> >>> > > Cheers
>> >>> > > Enrico
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > >>
>> >>> > >> Julian
>> >>> > >>
>> >>> > >>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli <
>> eolive...@gmail.com>
>> >>> > >> wrote:
>> >>> > >>>
>> >>> > >>> This is "the" error (see below). Unfortunately just be upgrading
>> >>> Janino
>> >>> > >> to
>> >>> > >>> 3.0.8 the problem still is present.
>> >>> > >>>
>> >>> > >>> the only 'unwrap'  word in the generated code is here
>> >>> > >>> ...
>> >>> > >>> public org.apache.calcite.linq4j.Enumerable bind(final
>> >>> > >>> org.apache.calcite.DataContext root0) {
>> >>> > >>> root = root0;
>> >>> > >>> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
>> >>> > >>> org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.
>> >>> > apache.calcite.test.
>> >>> > >> ReflectiveSchemaTest.CatchallSchema)
>> >>> > >>> ((org.apache.calcite.adapter.java.ReflectiveSchema)
>> >>> > >>> root.getRootSchema().getSubSchema("s").unwrap(org.
>> >>> > >> apache.calcite.adapter.java.ReflectiveSchema.class)).
>> >>> > >> getTarget()).nullables);
>> >>> > >>> 
>> >>> > >>>
>> >>> > >>> Does any ring bell ?
>> >>> > >>>
>> >>> > >>> Enrico

Re: JDK 8 syntax

2018-04-14 Thread Vova Vysotskyi

Ok, I will try to prepare a test case and will log a bug on Janino soon.

Kind regards,
Volodymyr Vysotskyi

2018-04-14 20:02 GMT+03:00 Julian Hyde :

> Vova,
>
> Thanks for doing the research. Your explanation sounds very plausible
> (I suspected default methods, too). Can you please log a bug on
> JANINO? https://github.com/janino-compiler/janino/issues Arno, the
> project maintainer, has been very good to us over the years.
>
> Julian
>
>
> On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli 
> wrote:
> > Il sab 14 apr 2018, 18:20 Enrico Olivelli  ha
> scritto:
> >
> >>
> >>
> >> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha scritto:
> >>
> >>> Hi all,
> >>>
> >>> I think the reason for this issue is that at the compile stage was
> assumed
> >>> that *getSubSchema()* method returns *Schema *inheritor, but not
> >>> *SchemaPlus*.
> >>> But the interesting thing is that with Java 8, methods list of
> >>> *SchemaPlus *interface
> >>> contains default *getSubSchema()* method.
> >>> It may be observed by executing this code:
> >>> *Method[] declaredMethods =
> >>>
> >>> Class.forName("org.apache.calcite.schema.SchemaPlus").
> getDeclaredMethods();*
> >>> *for (Method m : declaredMethods) {*
> >>> *  if (m.getName().equals("getSubSchema")) {*
> >>> *System.out.println(m);*
> >>> *  }*
> >>> *}*
> >>>
> >>> Its output:
> >>>
> >>> *public default org.apache.calcite.schema.Schema
> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >>>
> >>> The output of the same code for Java 7:
> >>>
> >>> *public abstract org.apache.calcite.schema.SchemaPlus
> >>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> >>>
> >>> Kind regards,
> >>> Volodymyr Vysotskyi
> >>>
> >>
> >> Good catch!
> >> It would be useful to look into that 'default' method by disassembling
> >> .class file.
> >> Enrico
> >>
> >
> > Anyway a fix would be to add an unwrap method to Schema
> > Cheers
> > Enrico
> >
> >
> >>
> >>
> >>> 2018-04-10 18:43 GMT+03:00 Julian Hyde :
> >>>
> >>> > I’d really appreciate that.
> >>> >
> >>> > Can you please log a JIRA case, and record your observations/progress
> >>> > there.
> >>> >
> >>> > There’s no particular hurry on this one.
> >>> >
> >>> > Julian
> >>> >
> >>> > > On Apr 10, 2018, at 06:32, Enrico Olivelli 
> >>> wrote:
> >>> > >
> >>> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde :
> >>> > >
> >>> > >> Yes, that’s it.
> >>> > >>
> >>> > >> Next step would be to check whether the generated code is the
> same as
> >>> > >> previously, and if so, it is a Janino bug. Then try to create a
> >>> minimal
> >>> > >> test case for Janino. Maybe we can work around by adding an
> explicit
> >>> > cast
> >>> > >> somewhere.
> >>> > >>
> >>> > >> Thanks for reproducing this, and trying the Janino upgrade.
> >>> > >>
> >>> > >
> >>> > >
> >>> > > Julian,
> >>> > > If you have no hurry for this I will be happy to spend some time in
> >>> order
> >>> > > to figure out the root cause.
> >>> > >
> >>> > > I will follow the discussion and jump in when I have some idea.
> >>> > >
> >>> > > It will be great to have Calcite really built on jdk8 and leverage
> >>> > lambdas
> >>> > >
> >>> > >
> >>> > > Cheers
> >>> > > Enrico
> >>> > >
> >>> > >
> >>> > >
> >>> > >>
> >>> > >> Julian
> >>> > >>
> >>> > >>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli <
> eolive...@gmail.com>
> >>> > >> wrote:
> >>> > >>>
> >>> > >>> This is "the" error (see below). Unfortunately just be upgrading
> >>> Janino
> >>> > >> to
> >>> > >>> 3.0.8 the problem still is present.
> >>> > >>>
> >>> > >>> the only 'unwrap'  word in the generated code is here
> >>> > >>> ...
> >>> > >>> public org.apache.calcite.linq4j.Enumerable bind(final
> >>> > >>> org.apache.calcite.DataContext root0) {
> >>> > >>> root = root0;
> >>> > >>> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> >>> > >>> org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.
> >>> > apache.calcite.test.
> >>> > >> ReflectiveSchemaTest.CatchallSchema)
> >>> > >>> ((org.apache.calcite.adapter.java.ReflectiveSchema)
> >>> > >>> root.getRootSchema().getSubSchema("s").unwrap(org.
> >>> > >> apache.calcite.adapter.java.ReflectiveSchema.class)).
> >>> > >> getTarget()).nullables);
> >>> > >>> 
> >>> > >>>
> >>> > >>> Does any ring bell ?
> >>> > >>>
> >>> > >>> Enrico
> >>> > >>>
> >>> > >>>
> >>> > >>> Caused by: org.codehaus.commons.compiler.CompileException: Line
> 5,
> >>> > >> Column
> >>> > >>> 272: A method named "unwrap" is not declared in any enclosing
> class
> >>> nor
> >>> > >> any
> >>> > >>> supertype, nor through a static import
> >>> >    at
> >>> > >>>
> >>>

Re: JDK 8 syntax

2018-04-14 Thread Julian Hyde

Vova,

Thanks for doing the research. Your explanation sounds very plausible
(I suspected default methods, too). Can you please log a bug on
JANINO? https://github.com/janino-compiler/janino/issues Arno, the
project maintainer, has been very good to us over the years.

Julian


On Sat, Apr 14, 2018 at 9:28 AM, Enrico Olivelli  wrote:
> Il sab 14 apr 2018, 18:20 Enrico Olivelli  ha scritto:
>
>>
>>
>> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha scritto:
>>
>>> Hi all,
>>>
>>> I think the reason for this issue is that at the compile stage was assumed
>>> that *getSubSchema()* method returns *Schema *inheritor, but not
>>> *SchemaPlus*.
>>> But the interesting thing is that with Java 8, methods list of
>>> *SchemaPlus *interface
>>> contains default *getSubSchema()* method.
>>> It may be observed by executing this code:
>>> *Method[] declaredMethods =
>>>
>>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDeclaredMethods();*
>>> *for (Method m : declaredMethods) {*
>>> *  if (m.getName().equals("getSubSchema")) {*
>>> *System.out.println(m);*
>>> *  }*
>>> *}*
>>>
>>> Its output:
>>>
>>> *public default org.apache.calcite.schema.Schema
>>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>>> *public abstract org.apache.calcite.schema.SchemaPlus
>>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>>>
>>> The output of the same code for Java 7:
>>>
>>> *public abstract org.apache.calcite.schema.SchemaPlus
>>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>>>
>>> Kind regards,
>>> Volodymyr Vysotskyi
>>>
>>
>> Good catch!
>> It would be useful to look into that 'default' method by disassembling
>> .class file.
>> Enrico
>>
>
> Anyway a fix would be to add an unwrap method to Schema
> Cheers
> Enrico
>
>
>>
>>
>>> 2018-04-10 18:43 GMT+03:00 Julian Hyde :
>>>
>>> > I’d really appreciate that.
>>> >
>>> > Can you please log a JIRA case, and record your observations/progress
>>> > there.
>>> >
>>> > There’s no particular hurry on this one.
>>> >
>>> > Julian
>>> >
>>> > > On Apr 10, 2018, at 06:32, Enrico Olivelli 
>>> wrote:
>>> > >
>>> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde :
>>> > >
>>> > >> Yes, that’s it.
>>> > >>
>>> > >> Next step would be to check whether the generated code is the same as
>>> > >> previously, and if so, it is a Janino bug. Then try to create a
>>> minimal
>>> > >> test case for Janino. Maybe we can work around by adding an explicit
>>> > cast
>>> > >> somewhere.
>>> > >>
>>> > >> Thanks for reproducing this, and trying the Janino upgrade.
>>> > >>
>>> > >
>>> > >
>>> > > Julian,
>>> > > If you have no hurry for this I will be happy to spend some time in
>>> order
>>> > > to figure out the root cause.
>>> > >
>>> > > I will follow the discussion and jump in when I have some idea.
>>> > >
>>> > > It will be great to have Calcite really built on jdk8 and leverage
>>> > lambdas
>>> > >
>>> > >
>>> > > Cheers
>>> > > Enrico
>>> > >
>>> > >
>>> > >
>>> > >>
>>> > >> Julian
>>> > >>
>>> > >>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli 
>>> > >> wrote:
>>> > >>>
>>> > >>> This is "the" error (see below). Unfortunately just be upgrading
>>> Janino
>>> > >> to
>>> > >>> 3.0.8 the problem still is present.
>>> > >>>
>>> > >>> the only 'unwrap'  word in the generated code is here
>>> > >>> ...
>>> > >>> public org.apache.calcite.linq4j.Enumerable bind(final
>>> > >>> org.apache.calcite.DataContext root0) {
>>> > >>> root = root0;
>>> > >>> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
>>> > >>> org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.
>>> > apache.calcite.test.
>>> > >> ReflectiveSchemaTest.CatchallSchema)
>>> > >>> ((org.apache.calcite.adapter.java.ReflectiveSchema)
>>> > >>> root.getRootSchema().getSubSchema("s").unwrap(org.
>>> > >> apache.calcite.adapter.java.ReflectiveSchema.class)).
>>> > >> getTarget()).nullables);
>>> > >>> 
>>> > >>>
>>> > >>> Does any ring bell ?
>>> > >>>
>>> > >>> Enrico
>>> > >>>
>>> > >>>
>>> > >>> Caused by: org.codehaus.commons.compiler.CompileException: Line 5,
>>> > >> Column
>>> > >>> 272: A method named "unwrap" is not declared in any enclosing class
>>> nor
>>> > >> any
>>> > >>> supertype, nor through a static import
>>> >    at
>>> > >>>
>>> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11821)
>>> >    at
>>> > >>> org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8731)
>>> >    at
>>> > >>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4737)
>>> >    at org.codehaus.janino.UnitCompiler.access$8300(
>>> > >> UnitCompiler.java:212)
>>> >    at
>>> > >>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
>>> > >> UnitCompiler.java:4097)
>>> >    at
>>> > >>>

Re: JDK 8 syntax

2018-04-14 Thread Enrico Olivelli

Il sab 14 apr 2018, 18:20 Enrico Olivelli  ha scritto:

>
>
> Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha scritto:
>
>> Hi all,
>>
>> I think the reason for this issue is that at the compile stage was assumed
>> that *getSubSchema()* method returns *Schema *inheritor, but not
>> *SchemaPlus*.
>> But the interesting thing is that with Java 8, methods list of
>> *SchemaPlus *interface
>> contains default *getSubSchema()* method.
>> It may be observed by executing this code:
>> *Method[] declaredMethods =
>>
>> Class.forName("org.apache.calcite.schema.SchemaPlus").getDeclaredMethods();*
>> *for (Method m : declaredMethods) {*
>> *  if (m.getName().equals("getSubSchema")) {*
>> *System.out.println(m);*
>> *  }*
>> *}*
>>
>> Its output:
>>
>> *public default org.apache.calcite.schema.Schema
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>> *public abstract org.apache.calcite.schema.SchemaPlus
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>>
>> The output of the same code for Java 7:
>>
>> *public abstract org.apache.calcite.schema.SchemaPlus
>> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>>
>> Kind regards,
>> Volodymyr Vysotskyi
>>
>
> Good catch!
> It would be useful to look into that 'default' method by disassembling
> .class file.
> Enrico
>

Anyway a fix would be to add an unwrap method to Schema
Cheers
Enrico


>
>
>> 2018-04-10 18:43 GMT+03:00 Julian Hyde :
>>
>> > I’d really appreciate that.
>> >
>> > Can you please log a JIRA case, and record your observations/progress
>> > there.
>> >
>> > There’s no particular hurry on this one.
>> >
>> > Julian
>> >
>> > > On Apr 10, 2018, at 06:32, Enrico Olivelli 
>> wrote:
>> > >
>> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde :
>> > >
>> > >> Yes, that’s it.
>> > >>
>> > >> Next step would be to check whether the generated code is the same as
>> > >> previously, and if so, it is a Janino bug. Then try to create a
>> minimal
>> > >> test case for Janino. Maybe we can work around by adding an explicit
>> > cast
>> > >> somewhere.
>> > >>
>> > >> Thanks for reproducing this, and trying the Janino upgrade.
>> > >>
>> > >
>> > >
>> > > Julian,
>> > > If you have no hurry for this I will be happy to spend some time in
>> order
>> > > to figure out the root cause.
>> > >
>> > > I will follow the discussion and jump in when I have some idea.
>> > >
>> > > It will be great to have Calcite really built on jdk8 and leverage
>> > lambdas
>> > >
>> > >
>> > > Cheers
>> > > Enrico
>> > >
>> > >
>> > >
>> > >>
>> > >> Julian
>> > >>
>> > >>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli 
>> > >> wrote:
>> > >>>
>> > >>> This is "the" error (see below). Unfortunately just be upgrading
>> Janino
>> > >> to
>> > >>> 3.0.8 the problem still is present.
>> > >>>
>> > >>> the only 'unwrap'  word in the generated code is here
>> > >>> ...
>> > >>> public org.apache.calcite.linq4j.Enumerable bind(final
>> > >>> org.apache.calcite.DataContext root0) {
>> > >>> root = root0;
>> > >>> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
>> > >>> org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.
>> > apache.calcite.test.
>> > >> ReflectiveSchemaTest.CatchallSchema)
>> > >>> ((org.apache.calcite.adapter.java.ReflectiveSchema)
>> > >>> root.getRootSchema().getSubSchema("s").unwrap(org.
>> > >> apache.calcite.adapter.java.ReflectiveSchema.class)).
>> > >> getTarget()).nullables);
>> > >>> 
>> > >>>
>> > >>> Does any ring bell ?
>> > >>>
>> > >>> Enrico
>> > >>>
>> > >>>
>> > >>> Caused by: org.codehaus.commons.compiler.CompileException: Line 5,
>> > >> Column
>> > >>> 272: A method named "unwrap" is not declared in any enclosing class
>> nor
>> > >> any
>> > >>> supertype, nor through a static import
>> >    at
>> > >>>
>> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11821)
>> >    at
>> > >>> org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8731)
>> >    at
>> > >>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4737)
>> >    at org.codehaus.janino.UnitCompiler.access$8300(
>> > >> UnitCompiler.java:212)
>> >    at
>> > >>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
>> > >> UnitCompiler.java:4097)
>> >    at
>> > >>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
>> > >> UnitCompiler.java:4070)
>> >    at
>> org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
>> >    at org.codehaus.janino.UnitCompiler.compileGet(
>> > >> UnitCompiler.java:4070)
>> >    at
>> > >>> org.codehaus.janino.UnitCompiler.compileGetValue(
>> > UnitCompiler.java:5253)
>> >    at
>> > >>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
>> >    at org.codehaus.janino.UnitCompiler.access$7800(
>> > >> UnitCompiler.java:212)

Re: JDK 8 syntax

2018-04-14 Thread Enrico Olivelli

Il sab 14 apr 2018, 17:39 Vova Vysotskyi  ha scritto:

> Hi all,
>
> I think the reason for this issue is that at the compile stage was assumed
> that *getSubSchema()* method returns *Schema *inheritor, but not
> *SchemaPlus*.
> But the interesting thing is that with Java 8, methods list of
> *SchemaPlus *interface
> contains default *getSubSchema()* method.
> It may be observed by executing this code:
> *Method[] declaredMethods =
>
> Class.forName("org.apache.calcite.schema.SchemaPlus").getDeclaredMethods();*
> *for (Method m : declaredMethods) {*
> *  if (m.getName().equals("getSubSchema")) {*
> *System.out.println(m);*
> *  }*
> *}*
>
> Its output:
>
> *public default org.apache.calcite.schema.Schema
> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
> *public abstract org.apache.calcite.schema.SchemaPlus
> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>
> The output of the same code for Java 7:
>
> *public abstract org.apache.calcite.schema.SchemaPlus
> org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
>
> Kind regards,
> Volodymyr Vysotskyi
>

Good catch!
It would be useful to look into that 'default' method by disassembling
.class file.
Enrico



> 2018-04-10 18:43 GMT+03:00 Julian Hyde :
>
> > I’d really appreciate that.
> >
> > Can you please log a JIRA case, and record your observations/progress
> > there.
> >
> > There’s no particular hurry on this one.
> >
> > Julian
> >
> > > On Apr 10, 2018, at 06:32, Enrico Olivelli 
> wrote:
> > >
> > > 2018-04-10 13:48 GMT+02:00 Julian Hyde :
> > >
> > >> Yes, that’s it.
> > >>
> > >> Next step would be to check whether the generated code is the same as
> > >> previously, and if so, it is a Janino bug. Then try to create a
> minimal
> > >> test case for Janino. Maybe we can work around by adding an explicit
> > cast
> > >> somewhere.
> > >>
> > >> Thanks for reproducing this, and trying the Janino upgrade.
> > >>
> > >
> > >
> > > Julian,
> > > If you have no hurry for this I will be happy to spend some time in
> order
> > > to figure out the root cause.
> > >
> > > I will follow the discussion and jump in when I have some idea.
> > >
> > > It will be great to have Calcite really built on jdk8 and leverage
> > lambdas
> > >
> > >
> > > Cheers
> > > Enrico
> > >
> > >
> > >
> > >>
> > >> Julian
> > >>
> > >>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli 
> > >> wrote:
> > >>>
> > >>> This is "the" error (see below). Unfortunately just be upgrading
> Janino
> > >> to
> > >>> 3.0.8 the problem still is present.
> > >>>
> > >>> the only 'unwrap'  word in the generated code is here
> > >>> ...
> > >>> public org.apache.calcite.linq4j.Enumerable bind(final
> > >>> org.apache.calcite.DataContext root0) {
> > >>> root = root0;
> > >>> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> > >>> org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.
> > apache.calcite.test.
> > >> ReflectiveSchemaTest.CatchallSchema)
> > >>> ((org.apache.calcite.adapter.java.ReflectiveSchema)
> > >>> root.getRootSchema().getSubSchema("s").unwrap(org.
> > >> apache.calcite.adapter.java.ReflectiveSchema.class)).
> > >> getTarget()).nullables);
> > >>> 
> > >>>
> > >>> Does any ring bell ?
> > >>>
> > >>> Enrico
> > >>>
> > >>>
> > >>> Caused by: org.codehaus.commons.compiler.CompileException: Line 5,
> > >> Column
> > >>> 272: A method named "unwrap" is not declared in any enclosing class
> nor
> > >> any
> > >>> supertype, nor through a static import
> >    at
> > >>>
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11821)
> >    at
> > >>> org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8731)
> >    at
> > >>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4737)
> >    at org.codehaus.janino.UnitCompiler.access$8300(
> > >> UnitCompiler.java:212)
> >    at
> > >>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
> > >> UnitCompiler.java:4097)
> >    at
> > >>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
> > >> UnitCompiler.java:4070)
> >    at
> org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
> >    at org.codehaus.janino.UnitCompiler.compileGet(
> > >> UnitCompiler.java:4070)
> >    at
> > >>> org.codehaus.janino.UnitCompiler.compileGetValue(
> > UnitCompiler.java:5253)
> >    at
> > >>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
> >    at org.codehaus.janino.UnitCompiler.access$7800(
> > >> UnitCompiler.java:212)
> >    at
> > >>> org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4092)
> >    at
> > >>> org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4070)
> >    at org.codehaus.janino.Java$Cast.accept(Java.java:4727)
> >    at org.codehaus.janino.UnitCompiler.compileGet(

Re: JDK 8 syntax

2018-04-14 Thread Vova Vysotskyi

Hi all,

I think the reason for this issue is that at the compile stage was assumed
that *getSubSchema()* method returns *Schema *inheritor, but not
*SchemaPlus*.
But the interesting thing is that with Java 8, methods list of
*SchemaPlus *interface
contains default *getSubSchema()* method.
It may be observed by executing this code:
*Method[] declaredMethods =
Class.forName("org.apache.calcite.schema.SchemaPlus").getDeclaredMethods();*
*for (Method m : declaredMethods) {*
*  if (m.getName().equals("getSubSchema")) {*
*System.out.println(m);*
*  }*
*}*

Its output:

*public default org.apache.calcite.schema.Schema
org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*
*public abstract org.apache.calcite.schema.SchemaPlus
org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*

The output of the same code for Java 7:

*public abstract org.apache.calcite.schema.SchemaPlus
org.apache.calcite.schema.SchemaPlus.getSubSchema(java.lang.String)*

Kind regards,
Volodymyr Vysotskyi

2018-04-10 18:43 GMT+03:00 Julian Hyde :

> I’d really appreciate that.
>
> Can you please log a JIRA case, and record your observations/progress
> there.
>
> There’s no particular hurry on this one.
>
> Julian
>
> > On Apr 10, 2018, at 06:32, Enrico Olivelli  wrote:
> >
> > 2018-04-10 13:48 GMT+02:00 Julian Hyde :
> >
> >> Yes, that’s it.
> >>
> >> Next step would be to check whether the generated code is the same as
> >> previously, and if so, it is a Janino bug. Then try to create a minimal
> >> test case for Janino. Maybe we can work around by adding an explicit
> cast
> >> somewhere.
> >>
> >> Thanks for reproducing this, and trying the Janino upgrade.
> >>
> >
> >
> > Julian,
> > If you have no hurry for this I will be happy to spend some time in order
> > to figure out the root cause.
> >
> > I will follow the discussion and jump in when I have some idea.
> >
> > It will be great to have Calcite really built on jdk8 and leverage
> lambdas
> >
> >
> > Cheers
> > Enrico
> >
> >
> >
> >>
> >> Julian
> >>
> >>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli 
> >> wrote:
> >>>
> >>> This is "the" error (see below). Unfortunately just be upgrading Janino
> >> to
> >>> 3.0.8 the problem still is present.
> >>>
> >>> the only 'unwrap'  word in the generated code is here
> >>> ...
> >>> public org.apache.calcite.linq4j.Enumerable bind(final
> >>> org.apache.calcite.DataContext root0) {
> >>> root = root0;
> >>> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> >>> org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.
> apache.calcite.test.
> >> ReflectiveSchemaTest.CatchallSchema)
> >>> ((org.apache.calcite.adapter.java.ReflectiveSchema)
> >>> root.getRootSchema().getSubSchema("s").unwrap(org.
> >> apache.calcite.adapter.java.ReflectiveSchema.class)).
> >> getTarget()).nullables);
> >>> 
> >>>
> >>> Does any ring bell ?
> >>>
> >>> Enrico
> >>>
> >>>
> >>> Caused by: org.codehaus.commons.compiler.CompileException: Line 5,
> >> Column
> >>> 272: A method named "unwrap" is not declared in any enclosing class nor
> >> any
> >>> supertype, nor through a static import
>    at
> >>> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11821)
>    at
> >>> org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8731)
>    at
> >>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4737)
>    at org.codehaus.janino.UnitCompiler.access$8300(
> >> UnitCompiler.java:212)
>    at
> >>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
> >> UnitCompiler.java:4097)
>    at
> >>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
> >> UnitCompiler.java:4070)
>    at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
>    at org.codehaus.janino.UnitCompiler.compileGet(
> >> UnitCompiler.java:4070)
>    at
> >>> org.codehaus.janino.UnitCompiler.compileGetValue(
> UnitCompiler.java:5253)
>    at
> >>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
>    at org.codehaus.janino.UnitCompiler.access$7800(
> >> UnitCompiler.java:212)
>    at
> >>> org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4092)
>    at
> >>> org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4070)
>    at org.codehaus.janino.Java$Cast.accept(Java.java:4727)
>    at org.codehaus.janino.UnitCompiler.compileGet(
> >> UnitCompiler.java:4070)
>    at
> >>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4732)
>    at org.codehaus.janino.UnitCompiler.access$7300(
> >> UnitCompiler.java:212)
>    at
> >>> org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(
> >> UnitCompiler.java:4083)
>    at
> >>> org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(
> >> UnitCompiler.java:4074)
>    at
> >>>

Re: JDK 8 syntax

2018-04-10 Thread Julian Hyde

I’d really appreciate that.

Can you please log a JIRA case, and record your observations/progress there.

There’s no particular hurry on this one. 

Julian

> On Apr 10, 2018, at 06:32, Enrico Olivelli  wrote:
> 
> 2018-04-10 13:48 GMT+02:00 Julian Hyde :
> 
>> Yes, that’s it.
>> 
>> Next step would be to check whether the generated code is the same as
>> previously, and if so, it is a Janino bug. Then try to create a minimal
>> test case for Janino. Maybe we can work around by adding an explicit cast
>> somewhere.
>> 
>> Thanks for reproducing this, and trying the Janino upgrade.
>> 
> 
> 
> Julian,
> If you have no hurry for this I will be happy to spend some time in order
> to figure out the root cause.
> 
> I will follow the discussion and jump in when I have some idea.
> 
> It will be great to have Calcite really built on jdk8 and leverage lambdas
> 
> 
> Cheers
> Enrico
> 
> 
> 
>> 
>> Julian
>> 
>>> On Apr 10, 2018, at 3:37 AM, Enrico Olivelli 
>> wrote:
>>> 
>>> This is "the" error (see below). Unfortunately just be upgrading Janino
>> to
>>> 3.0.8 the problem still is present.
>>> 
>>> the only 'unwrap'  word in the generated code is here
>>> ...
>>> public org.apache.calcite.linq4j.Enumerable bind(final
>>> org.apache.calcite.DataContext root0) {
>>> root = root0;
>>> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
>>> org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.apache.calcite.test.
>> ReflectiveSchemaTest.CatchallSchema)
>>> ((org.apache.calcite.adapter.java.ReflectiveSchema)
>>> root.getRootSchema().getSubSchema("s").unwrap(org.
>> apache.calcite.adapter.java.ReflectiveSchema.class)).
>> getTarget()).nullables);
>>> 
>>> 
>>> Does any ring bell ?
>>> 
>>> Enrico
>>> 
>>> 
>>> Caused by: org.codehaus.commons.compiler.CompileException: Line 5,
>> Column
>>> 272: A method named "unwrap" is not declared in any enclosing class nor
>> any
>>> supertype, nor through a static import
   at
>>> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11821)
   at
>>> org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8731)
   at
>>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4737)
   at org.codehaus.janino.UnitCompiler.access$8300(
>> UnitCompiler.java:212)
   at
>>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
>> UnitCompiler.java:4097)
   at
>>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
>> UnitCompiler.java:4070)
   at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
   at org.codehaus.janino.UnitCompiler.compileGet(
>> UnitCompiler.java:4070)
   at
>>> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
   at
>>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
   at org.codehaus.janino.UnitCompiler.access$7800(
>> UnitCompiler.java:212)
   at
>>> org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4092)
   at
>>> org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4070)
   at org.codehaus.janino.Java$Cast.accept(Java.java:4727)
   at org.codehaus.janino.UnitCompiler.compileGet(
>> UnitCompiler.java:4070)
   at
>>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4732)
   at org.codehaus.janino.UnitCompiler.access$7300(
>> UnitCompiler.java:212)
   at
>>> org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(
>> UnitCompiler.java:4083)
   at
>>> org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(
>> UnitCompiler.java:4074)
   at
>>> org.codehaus.janino.Java$ParenthesizedExpression.accept(Java.java:4753)
   at
>>> org.codehaus.janino.UnitCompiler$12.visitLvalue(UnitCompiler.java:4074)
   at
>>> org.codehaus.janino.UnitCompiler$12.visitLvalue(UnitCompiler.java:4070)
   at org.codehaus.janino.Java$Lvalue.accept(Java.java:3977)
   at org.codehaus.janino.UnitCompiler.compileGet(
>> UnitCompiler.java:4070)
   at
>>> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
   at
>>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4792)
   at org.codehaus.janino.UnitCompiler.access$8300(
>> UnitCompiler.java:212)
   at
>>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
>> UnitCompiler.java:4097)
   at
>>> org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
>> UnitCompiler.java:4070)
   at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
   at org.codehaus.janino.UnitCompiler.compileGet(
>> UnitCompiler.java:4070)
   at
>>> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
   at
>>> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
   at org.codehaus.janino.UnitCompiler.access$7800(
>> UnitCompiler.java:212)
   at
>>>

Re: JDK 8 syntax

2018-04-10 Thread Enrico Olivelli

2018-04-10 13:48 GMT+02:00 Julian Hyde :

> Yes, that’s it.
>
> Next step would be to check whether the generated code is the same as
> previously, and if so, it is a Janino bug. Then try to create a minimal
> test case for Janino. Maybe we can work around by adding an explicit cast
> somewhere.
>
> Thanks for reproducing this, and trying the Janino upgrade.
>


Julian,
If you have no hurry for this I will be happy to spend some time in order
to figure out the root cause.

I will follow the discussion and jump in when I have some idea.

It will be great to have Calcite really built on jdk8 and leverage lambdas


Cheers
Enrico



>
> Julian
>
> > On Apr 10, 2018, at 3:37 AM, Enrico Olivelli 
> wrote:
> >
> > This is "the" error (see below). Unfortunately just be upgrading Janino
> to
> > 3.0.8 the problem still is present.
> >
> > the only 'unwrap'  word in the generated code is here
> > ...
> > public org.apache.calcite.linq4j.Enumerable bind(final
> > org.apache.calcite.DataContext root0) {
> >  root = root0;
> >  final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> > org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.apache.calcite.test.
> ReflectiveSchemaTest.CatchallSchema)
> > ((org.apache.calcite.adapter.java.ReflectiveSchema)
> > root.getRootSchema().getSubSchema("s").unwrap(org.
> apache.calcite.adapter.java.ReflectiveSchema.class)).
> getTarget()).nullables);
> > 
> >
> > Does any ring bell ?
> >
> > Enrico
> >
> >
> > Caused by: org.codehaus.commons.compiler.CompileException: Line 5,
> Column
> > 272: A method named "unwrap" is not declared in any enclosing class nor
> any
> > supertype, nor through a static import
> >>at
> > org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11821)
> >>at
> > org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8731)
> >>at
> > org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4737)
> >>at org.codehaus.janino.UnitCompiler.access$8300(
> UnitCompiler.java:212)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
> UnitCompiler.java:4097)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
> UnitCompiler.java:4070)
> >>at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
> >>at org.codehaus.janino.UnitCompiler.compileGet(
> UnitCompiler.java:4070)
> >>at
> > org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
> >>at
> > org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
> >>at org.codehaus.janino.UnitCompiler.access$7800(
> UnitCompiler.java:212)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4092)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4070)
> >>at org.codehaus.janino.Java$Cast.accept(Java.java:4727)
> >>at org.codehaus.janino.UnitCompiler.compileGet(
> UnitCompiler.java:4070)
> >>at
> > org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4732)
> >>at org.codehaus.janino.UnitCompiler.access$7300(
> UnitCompiler.java:212)
> >>at
> > org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(
> UnitCompiler.java:4083)
> >>at
> > org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(
> UnitCompiler.java:4074)
> >>at
> > org.codehaus.janino.Java$ParenthesizedExpression.accept(Java.java:4753)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitLvalue(UnitCompiler.java:4074)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitLvalue(UnitCompiler.java:4070)
> >>at org.codehaus.janino.Java$Lvalue.accept(Java.java:3977)
> >>at org.codehaus.janino.UnitCompiler.compileGet(
> UnitCompiler.java:4070)
> >>at
> > org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
> >>at
> > org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4792)
> >>at org.codehaus.janino.UnitCompiler.access$8300(
> UnitCompiler.java:212)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
> UnitCompiler.java:4097)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(
> UnitCompiler.java:4070)
> >>at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
> >>at org.codehaus.janino.UnitCompiler.compileGet(
> UnitCompiler.java:4070)
> >>at
> > org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
> >>at
> > org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
> >>at org.codehaus.janino.UnitCompiler.access$7800(
> UnitCompiler.java:212)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4092)
> >>at
> > org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4070)
> >>at org.codehaus.janino.Java$Cast.accept(Java.java:4727)
> >>at org.codehaus.janino.UnitCompiler.compileGet(
> UnitCompiler.java:4070)
> >>at
> >

Re: JDK 8 syntax

2018-04-10 Thread Enrico Olivelli

This is "the" error (see below). Unfortunately just be upgrading Janino to
3.0.8 the problem still is present.

the only 'unwrap'  word in the generated code is here
...
public org.apache.calcite.linq4j.Enumerable bind(final
org.apache.calcite.DataContext root0) {
  root = root0;
  final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.apache.calcite.test.ReflectiveSchemaTest.CatchallSchema)
((org.apache.calcite.adapter.java.ReflectiveSchema)
root.getRootSchema().getSubSchema("s").unwrap(org.apache.calcite.adapter.java.ReflectiveSchema.class)).getTarget()).nullables);


Does any ring bell ?

Enrico


Caused by: org.codehaus.commons.compiler.CompileException: Line 5, Column
272: A method named "unwrap" is not declared in any enclosing class nor any
supertype, nor through a static import
> at
org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11821)
> at
org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8731)
> at
org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4737)
> at org.codehaus.janino.UnitCompiler.access$8300(UnitCompiler.java:212)
> at
org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(UnitCompiler.java:4097)
> at
org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(UnitCompiler.java:4070)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4070)
> at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
> at
org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
> at org.codehaus.janino.UnitCompiler.access$7800(UnitCompiler.java:212)
> at
org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4092)
> at
org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4070)
> at org.codehaus.janino.Java$Cast.accept(Java.java:4727)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4070)
> at
org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4732)
> at org.codehaus.janino.UnitCompiler.access$7300(UnitCompiler.java:212)
> at
org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(UnitCompiler.java:4083)
> at
org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(UnitCompiler.java:4074)
> at
org.codehaus.janino.Java$ParenthesizedExpression.accept(Java.java:4753)
> at
org.codehaus.janino.UnitCompiler$12.visitLvalue(UnitCompiler.java:4074)
> at
org.codehaus.janino.UnitCompiler$12.visitLvalue(UnitCompiler.java:4070)
> at org.codehaus.janino.Java$Lvalue.accept(Java.java:3977)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4070)
> at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
> at
org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4792)
> at org.codehaus.janino.UnitCompiler.access$8300(UnitCompiler.java:212)
> at
org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(UnitCompiler.java:4097)
> at
org.codehaus.janino.UnitCompiler$12.visitMethodInvocation(UnitCompiler.java:4070)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:4902)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4070)
> at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
> at
org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4696)
> at org.codehaus.janino.UnitCompiler.access$7800(UnitCompiler.java:212)
> at
org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4092)
> at
org.codehaus.janino.UnitCompiler$12.visitCast(UnitCompiler.java:4070)
> at org.codehaus.janino.Java$Cast.accept(Java.java:4727)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4070)
> at
org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4732)
> at org.codehaus.janino.UnitCompiler.access$7300(UnitCompiler.java:212)
> at
org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(UnitCompiler.java:4083)
> at
org.codehaus.janino.UnitCompiler$12$1.visitParenthesizedExpression(UnitCompiler.java:4074)
> at
org.codehaus.janino.Java$ParenthesizedExpression.accept(Java.java:4753)
> at
org.codehaus.janino.UnitCompiler$12.visitLvalue(UnitCompiler.java:4074)
> at
org.codehaus.janino.UnitCompiler$12.visitLvalue(UnitCompiler.java:4070)
> at org.codehaus.janino.Java$Lvalue.accept(Java.java:3977)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4070)
> at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5253)
> at
org.codehaus.janino.UnitCompiler.compileContext2(UnitCompiler.java:4010)
> at org.codehaus.janino.UnitCompiler.access$6100(UnitCompiler.java:212)
> at
org.codehaus.janino.UnitCompiler$11$1.visitFieldAccess(UnitCompiler.java:3947)
> at

Re: JDK 8 syntax

2018-04-09 Thread Cade Markegard

Awesome!

On Mon, Apr 9, 2018 at 1:29 PM Enrico Olivelli  wrote:

> Il lun 9 apr 2018, 22:20 Cade Markegard  ha
> scritto:
>
> > Not sure if this is related, but it seems like Janino doesn't support
> Java8
> > lambdas under "Limitations" in http://janino-compiler.github.io/janino/
>
>
>
> This should not be a problem, we are not generating java sources with
> lambdas (maybe in future?).
> I will be happy to do some trials with new Janino, but I guess that would
> be the only way (or to drop Janino, but I think it will be harder). I have
> not much time these days.
>
> Anyhow I am testing my apps on jdk10 and Calcite is working like a charm !
>
> Enrico
>
> >
> >
> > On Mon, Apr 9, 2018 at 12:54 PM Julian Hyde  wrote:
> >
> > > I didn’t try. We’re on janino 2.7.6. The 2.x line only goes up to
> 2.7.8.
> > > I’m not eager to try upgrading to 3.x (latest release is 3.0.8)
> > especially
> > > as they don’t explicitly mention fixing a JDK 8 issue.
> > >
> > > http://janino-compiler.github.io/janino/changelog.html <
> > > http://janino-compiler.github.io/janino/changelog.html>
> > >
> > >
> > > > On Apr 9, 2018, at 12:42 PM, Enrico Olivelli 
> > > wrote:
> > > >
> > > > Il lun 9 apr 2018, 21:37 Julian Hyde  > jh...@apache.org>> ha scritto:
> > > >
> > > >> Don’t have the error stack, but janino could not compile generated
> > code
> > > >> because it said an “unwrap” method did not exist.
> > > >>
> > > >> There were no lambdas. I think perhaps that version of janino could
> > not
> > > >> fully understand the Calcite class files.
> > > >>
> > > >> To reproduce, change 2 lines in core/pom.xml and run “mvn test”.
> > > >>
> > > >
> > > > Did you try to update to latest Janino?
> > > > It seems to that we have an old version (2.7.6)
> > > >
> > > > Enrico
> > > >
> > > >>
> > > >> Julian
> > > >>
> > > >>
> > > >>> On Apr 9, 2018, at 12:15 PM, Enrico Olivelli 
> > > >> wrote:
> > > >>>
> > > >>> Il lun 9 apr 2018, 19:05 Julian Hyde  ha
> scritto:
> > > >>>
> > >  Has anyone had any luck using JDK 8 syntax (e.g. “->” for lambdas)
> > in
> > >  Calcite?
> > > 
> > >  In core/pom.xml I changed source=1.7 target=1.7 to source=8
> target=8
> > > and
> > >  it allowed the syntax but it seemed to break any tests that relied
> > on
> > >  janino.
> > > 
> > > >>>
> > > >>> Julian,
> > > >>> Could you please share a stacktrace of your error?
> > > >>> As far as I know using lambdas is not only a matter of syntactic
> > sugar
> > > >> but
> > > >>> they are more efficient than simple anonymous classes.
> > > >>>
> > > >>> Cheers
> > > >>> Enrico
> > > >>>
> > > >>>
> > >  Related: https://issues.apache.org/jira/browse/CALCITE-2027 <
> > >  https://issues.apache.org/jira/browse/CALCITE-2027>
> > > 
> > >  Julian
> > > 
> > >  --
> > > >>>
> > > >>>
> > > >>> -- Enrico Olivelli
> > > >>
> > > >> --
> > > >
> > > >
> > > > -- Enrico Olivelli
> > >
> > >
> >
> --
>
>
> -- Enrico Olivelli
>

Re: JDK 8 syntax

2018-04-09 Thread Cade Markegard

Not sure if this is related, but it seems like Janino doesn't support Java8
lambdas under "Limitations" in http://janino-compiler.github.io/janino/

On Mon, Apr 9, 2018 at 12:54 PM Julian Hyde  wrote:

> I didn’t try. We’re on janino 2.7.6. The 2.x line only goes up to 2.7.8.
> I’m not eager to try upgrading to 3.x (latest release is 3.0.8) especially
> as they don’t explicitly mention fixing a JDK 8 issue.
>
> http://janino-compiler.github.io/janino/changelog.html <
> http://janino-compiler.github.io/janino/changelog.html>
>
>
> > On Apr 9, 2018, at 12:42 PM, Enrico Olivelli 
> wrote:
> >
> > Il lun 9 apr 2018, 21:37 Julian Hyde > ha scritto:
> >
> >> Don’t have the error stack, but janino could not compile generated code
> >> because it said an “unwrap” method did not exist.
> >>
> >> There were no lambdas. I think perhaps that version of janino could not
> >> fully understand the Calcite class files.
> >>
> >> To reproduce, change 2 lines in core/pom.xml and run “mvn test”.
> >>
> >
> > Did you try to update to latest Janino?
> > It seems to that we have an old version (2.7.6)
> >
> > Enrico
> >
> >>
> >> Julian
> >>
> >>
> >>> On Apr 9, 2018, at 12:15 PM, Enrico Olivelli 
> >> wrote:
> >>>
> >>> Il lun 9 apr 2018, 19:05 Julian Hyde  ha scritto:
> >>>
>  Has anyone had any luck using JDK 8 syntax (e.g. “->” for lambdas) in
>  Calcite?
> 
>  In core/pom.xml I changed source=1.7 target=1.7 to source=8 target=8
> and
>  it allowed the syntax but it seemed to break any tests that relied on
>  janino.
> 
> >>>
> >>> Julian,
> >>> Could you please share a stacktrace of your error?
> >>> As far as I know using lambdas is not only a matter of syntactic sugar
> >> but
> >>> they are more efficient than simple anonymous classes.
> >>>
> >>> Cheers
> >>> Enrico
> >>>
> >>>
>  Related: https://issues.apache.org/jira/browse/CALCITE-2027 <
>  https://issues.apache.org/jira/browse/CALCITE-2027>
> 
>  Julian
> 
>  --
> >>>
> >>>
> >>> -- Enrico Olivelli
> >>
> >> --
> >
> >
> > -- Enrico Olivelli
>
>

Re: JDK 8 syntax

2018-04-09 Thread Julian Hyde

I didn’t try. We’re on janino 2.7.6. The 2.x line only goes up to 2.7.8. I’m 
not eager to try upgrading to 3.x (latest release is 3.0.8) especially as they 
don’t explicitly mention fixing a JDK 8 issue.

http://janino-compiler.github.io/janino/changelog.html 



> On Apr 9, 2018, at 12:42 PM, Enrico Olivelli  wrote:
> 
> Il lun 9 apr 2018, 21:37 Julian Hyde  > ha scritto:
> 
>> Don’t have the error stack, but janino could not compile generated code
>> because it said an “unwrap” method did not exist.
>> 
>> There were no lambdas. I think perhaps that version of janino could not
>> fully understand the Calcite class files.
>> 
>> To reproduce, change 2 lines in core/pom.xml and run “mvn test”.
>> 
> 
> Did you try to update to latest Janino?
> It seems to that we have an old version (2.7.6)
> 
> Enrico
> 
>> 
>> Julian
>> 
>> 
>>> On Apr 9, 2018, at 12:15 PM, Enrico Olivelli 
>> wrote:
>>> 
>>> Il lun 9 apr 2018, 19:05 Julian Hyde  ha scritto:
>>> 
 Has anyone had any luck using JDK 8 syntax (e.g. “->” for lambdas) in
 Calcite?
 
 In core/pom.xml I changed source=1.7 target=1.7 to source=8 target=8 and
 it allowed the syntax but it seemed to break any tests that relied on
 janino.
 
>>> 
>>> Julian,
>>> Could you please share a stacktrace of your error?
>>> As far as I know using lambdas is not only a matter of syntactic sugar
>> but
>>> they are more efficient than simple anonymous classes.
>>> 
>>> Cheers
>>> Enrico
>>> 
>>> 
 Related: https://issues.apache.org/jira/browse/CALCITE-2027 <
 https://issues.apache.org/jira/browse/CALCITE-2027>
 
 Julian
 
 --
>>> 
>>> 
>>> -- Enrico Olivelli
>> 
>> --
> 
> 
> -- Enrico Olivelli

Re: JDK 8 syntax

2018-04-09 Thread Enrico Olivelli

Il lun 9 apr 2018, 21:37 Julian Hyde  ha scritto:

> Don’t have the error stack, but janino could not compile generated code
> because it said an “unwrap” method did not exist.
>
> There were no lambdas. I think perhaps that version of janino could not
> fully understand the Calcite class files.
>
> To reproduce, change 2 lines in core/pom.xml and run “mvn test”.
>

Did you try to update to latest Janino?
It seems to that we have an old version (2.7.6)

Enrico

>
> Julian
>
>
> > On Apr 9, 2018, at 12:15 PM, Enrico Olivelli 
> wrote:
> >
> > Il lun 9 apr 2018, 19:05 Julian Hyde  ha scritto:
> >
> >> Has anyone had any luck using JDK 8 syntax (e.g. “->” for lambdas) in
> >> Calcite?
> >>
> >> In core/pom.xml I changed source=1.7 target=1.7 to source=8 target=8 and
> >> it allowed the syntax but it seemed to break any tests that relied on
> >> janino.
> >>
> >
> > Julian,
> > Could you please share a stacktrace of your error?
> > As far as I know using lambdas is not only a matter of syntactic sugar
> but
> > they are more efficient than simple anonymous classes.
> >
> > Cheers
> > Enrico
> >
> >
> >> Related: https://issues.apache.org/jira/browse/CALCITE-2027 <
> >> https://issues.apache.org/jira/browse/CALCITE-2027>
> >>
> >> Julian
> >>
> >> --
> >
> >
> > -- Enrico Olivelli
>
> --


-- Enrico Olivelli

Re: JDK 8 syntax

2018-04-09 Thread Julian Hyde

Don’t have the error stack, but janino could not compile generated code because 
it said an “unwrap” method did not exist.

There were no lambdas. I think perhaps that version of janino could not fully 
understand the Calcite class files.

To reproduce, change 2 lines in core/pom.xml and run “mvn test”.

Julian


> On Apr 9, 2018, at 12:15 PM, Enrico Olivelli  wrote:
> 
> Il lun 9 apr 2018, 19:05 Julian Hyde  ha scritto:
> 
>> Has anyone had any luck using JDK 8 syntax (e.g. “->” for lambdas) in
>> Calcite?
>> 
>> In core/pom.xml I changed source=1.7 target=1.7 to source=8 target=8 and
>> it allowed the syntax but it seemed to break any tests that relied on
>> janino.
>> 
> 
> Julian,
> Could you please share a stacktrace of your error?
> As far as I know using lambdas is not only a matter of syntactic sugar but
> they are more efficient than simple anonymous classes.
> 
> Cheers
> Enrico
> 
> 
>> Related: https://issues.apache.org/jira/browse/CALCITE-2027 <
>> https://issues.apache.org/jira/browse/CALCITE-2027>
>> 
>> Julian
>> 
>> --
> 
> 
> -- Enrico Olivelli

Re: JDK 8 syntax

2018-04-09 Thread Enrico Olivelli

Il lun 9 apr 2018, 19:05 Julian Hyde  ha scritto:

> Has anyone had any luck using JDK 8 syntax (e.g. “->” for lambdas) in
> Calcite?
>
> In core/pom.xml I changed source=1.7 target=1.7 to source=8 target=8 and
> it allowed the syntax but it seemed to break any tests that relied on
> janino.
>

Julian,
Could you please share a stacktrace of your error?
As far as I know using lambdas is not only a matter of syntactic sugar but
they are more efficient than simple anonymous classes.

Cheers
Enrico


> Related: https://issues.apache.org/jira/browse/CALCITE-2027 <
> https://issues.apache.org/jira/browse/CALCITE-2027>
>
> Julian
>
> --


-- Enrico Olivelli

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

Re: JDK 8 syntax

24 matches

Site Navigation

Mail list logo

Footer information