Re: CompiledExpression.evaluate implementation

[Mark Taylor]

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/