help-jel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: String null comparison failure


From: Konstantin L. Metlov
Subject: Re: String null comparison failure
Date: Thu, 06 Jan 2022 23:08:49 +0300
User-agent: Horde Application Framework 5

Great that the fix works !

Eventually (after more changes are accumulated) yes, there will be a next release.

The downside is that JDK is a moving target. A compatible version today can become incompatible after the next JDK release and "the earliest compatible" is most endangered in this respect.

It should not be difficult to rebuild JEL with ant. Just go to the "./source" directory of the distribution and run "ant dist-test". This will build everything with your default java, run all the tests and assemble the distribution under "./source/build/dist" putting the .jar files in "./source/build/dist/lib". On my machine the build time is 15 seconds.

With the best regards,
                          Konstantin.

Quoting Mark Taylor <m.b.taylor@bristol.ac.uk>:

Konstantin,

fantastic, many thanks as ever for the fast response.
I confirm that this jel-2_1_3-pre1.zip fixes the issue for me.
Do you plan to make a numbered 2.1.3 release in the near future?

One very minor point about the distribution: the pre-compiled jel.jar
and jel_g.jar files use the Java 14 classfile format, so I have to
recompile them for my Java 8 target platform.  This is no problem
to do, but since the code is compatible with earlier classfile
versions, it would make it slightly easier to use if jel.jar and
jel_g.jar were cross-compiled for whatever is the earliest
compatible Java version.  I'm not aware of any disadvantages to
doing that, though perhaps there's some reason I haven't thought of.

Best wishes,

Mark


On Tue, 4 Jan 2022, Konstantin L. Metlov wrote:

Happy New Year, Mark !

Thank you for the bug report !

Indeed, JEL used to strictly follow JLS for string comparison, but then for
JEL 0.9.8 someone requested a full string comparison support (complete with
collation rules). It was indeed a very good idea, but since that version the
strings started to be treated differently from other objects. Their comparison
was delegated to java.text.Collator, which by default throws an exception on
null arguments. It was possible to override this behaviour in collator without
modifying JEL, but I agree that not following the JLS for string comparisons
by default is a bug.

I've made a pre-release version of JEL 2.1.3, fixing this bug (and adding a
few more tests for string comparison) and also committed this fix on Savannah.
You can download the pre-release from:

http://www.donfti.ru/~metlov/jel-2_1_3-pre1.zip

The sha256sum is:
db720fdc4dc5679aa43232baea31f47a9fa6b784f30d2cadaac0541af38df9a7
jel-2_1_3-pre1.zip

With the best regards,
                          Konstantin.


Quoting Mark Taylor <m.b.taylor@bristol.ac.uk>:

> Dear Konstantin,
>
> happy new year!  And a JEL question.
>
> If I evaluate a string equality test in which one of the operands is null,
> a NullPointerException results, e.g.:
>
>   x=="abc"
>
> provokes a NullPointerException if x has the value null.
> Since the equivalent test in Java simply returns false, that's not
> what I was expecting.  Is this intended behaviour?
>
> The following program illustrates this:
>
>    import gnu.jel.CompiledExpression;
>    import gnu.jel.Evaluator;
>    import gnu.jel.Library;
>
>    public class Cmp {
>        public static void main(String[] args) throws Throwable {
>            Library lib = new Library(new Class[] {Cmp.ALib.class}, null,
> null, null, null);
>            compare("textValue", lib);
>            compare("nullValue", lib);
>        }
>        private static void compare(String func, Library lib) throws
> Throwable {
>            String txtExpr = func;
>            String cmpExpr = func + "==\"abc\"";
>
>            CompiledExpression txtCompex = Evaluator.compile(txtExpr, lib);
>            CompiledExpression cmpCompex = Evaluator.compile(cmpExpr, lib);
>
>            System.out.println();
>            report(txtExpr, txtCompex);
>            report(cmpExpr, cmpCompex);
>        }
>        private static void report(String expr, CompiledExpression compex)
> throws Throwable {
>            System.out.println(expr);
>            Object result = compex.evaluate(null);
>            System.out.println("    -> " + represent(result));
>        }
>        private static String represent(Object obj) {
>            if (obj == null) {
>                return "null";
>            }
>            else if (obj instanceof String) {
>                return "\"" + obj + "\"";
>            }
>            else {
>                return obj.toString();
>            }
>        }
>        public static class ALib {
>            public static String textValue() {
>                return "text";
>            }
>            public static String nullValue() {
>                return null;
>            }
>        }
>    }
>
> which produces the output (JEL 2.1.2):
>
>    textValue
>        -> "text"
>    textValue=="abc"
>        -> false
>
>    nullValue
>        -> null
>    nullValue=="abc"
>    Exception in thread "main" java.lang.NullPointerException
>            at
> java.text.RuleBasedCollator.compare(RuleBasedCollator.java:357)
>            at
> gnu.jel.CompiledExpression.compare(CompiledExpression.java:352)
>            at dump.evaluate_boolean(Unknown Source)
>            at
> gnu.jel.CompiledExpression.evaluate(CompiledExpression.java:157)
>            at Cmp.report(Cmp.java:25)
>            at Cmp.compare(Cmp.java:21)
>            at Cmp.main(Cmp.java:10)
>
> Thanks!
>
> Mark
>
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor@bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/





--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor@bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/






reply via email to

[Prev in Thread] Current Thread [Next in Thread]