Re: String null comparison failure
"Konstantin L. Metlov" <[email protected]> Thu, 06 Jan 2022 23:08:49 +0300
| Newsgroups | gmane.comp.java.jel.general |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]>:
> 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 <[email protected]>:
>>
>> > 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
>> > [email protected] http://www.star.bristol.ac.uk/~mbt/
>>
>>
>>
>>
>
> --
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> [email protected] http://www.star.bristol.ac.uk/~mbt/