Re: CompiledExpression.evaluate implementation

[Konstantin L. Metlov]

Dear Mark,

I've made a JEL 2.1.2 release today (available at the usual
https://www.gnu.org/software/jel/ ). It is identical to the last
pre-release code I've sent you.

With the best regards,
                             Konstantin.

> Konstantin,
>
> On Tue, 17 Nov 2020, Konstantin L. Metlov wrote:
>
>> Dear Mark,
>>
>> thank you for your suggestion ! I've done just that and also cleaned up
>> all the other JDK14 compiler warnings.
>>
>> The valueOf may be slower to create an object in some cases, but note
>> that
>> it also eliminates the need to free these objects. So, additionally to
>> using "valueOf" in the compiler itself, I've switched JEL code generator
>> to use it for creation of wrapper objects in the compiled expressions as
>> well.
>>
>> I've made another pre-release version today with these changes available
>> at
>>
>> http://www.donfti.ru/~metlov/jel-2_1_2-pre2.zip
>>
>> $ md5sum jel-2_1_2-pre2.zip
>> 995daac05794b29109267815df76284e  jel-2_1_2-pre2.zip
>> $ sha256sum jel-2_1_2-pre2.zip
>> f15e6e25b2d39f28c8a503cfd382c0361734a85c50d8e7e61195a2818d97ca43
>> jel-2_1_2-pre2.zip
>>
>> Could you please download it and see if it does not break anything for
>> you
>> ? You can conveniently browse the source changes on Savannah:
>
> Great, that works fine for me.  I have a reasonable amount of test
> code that uses JEL and nothing I can see breaks or changes with the
> new version.
>
>> http://svn.savannah.gnu.org/viewvc/jel/trunk/
>>
>> Still, the best performance with JEL can be achieved by eliminating the
>> object usage altogether and using only the primitive types. This can be
>> done by fixing the result type in the Evaluator.compile call to one of
>> the
>> Boolean.TYPE, Integer.TYPE, ... fields (note that these are not the
>> Boolean.class, Integer.class, etc) and then calling the corresponding
>> evaluate_boolean, evaluate_int, etc method of the CompiledExpression
>> directly. Setting the result type this way makes
>> CompiledExpression.getType() to always return the same value. The type
>> compatibility check (with widening conversion, if necessary) is then
>> going
>> to be done by JEL at compile time.
>
> Yes, I do this in a few circumstances, but in most cases because of
> the way the rest of the code is arranged I end up boxing the results
> in any case.  Rewriting everything to avoid wrapper classes is
> somewhere on my to-do list, but it would make the code quite a bit
> messier.
> Wouldn't it be nice to have first-class primitive types in java.
>
> Do you plan to release a 2.1.2 following these chanages or not?
> I don't really mind, but if there's about to be a numbered release
> I'll wait for that before I commit the JEL updates to my application.
>
> Thanks again for your efforts.
>
> Mark
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor@bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>