Query Parser fails on feature-type clause (Android only)

[sh3llc0d3r]

Tried many different scenarios but no luck so far. Works fine with the tool.

FeatureLibrary library = new FeatureLibrary("/storage/emulated/0/Download/bremen.gol"); //this is okay

Features<?> movieTheaters = library.select("na[amenity=cinema]"); //throws an error

- com.geodesk.feature.match.QueryException: [1:4]: Unknown feature type '[', should be 'n','w','a', or 'r'

Any ideas would be helpful.

[clarisma]

Thanks for opening this issue. Unfortunately, I haven't been able to reproduce it so far.
Generally, any bug in the query parser would also manifest in the GOL tool, as it uses the same library.

Here's a possible explanation for this odd behavior: The parser consumes the feature-type clause (The na part of your query) as an identifier, using this regex pattern: [a-zA-Z_]\w*. This pattern should stop at the [. However, \w is locale-sensitive and although I'm unaware of any locale that treats [ as a word character, this could be an obscure regex bug. Just to rule out this possibility, could you tell me the locale on which you are running the code snippet? You can use the following (which also re-creates the regex match):

import java.util.Locale;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class Issue91
{
    public static void main(String[] args)
    {
        Locale jvmLocale = Locale.getDefault();
        System.out.println("Default JVM Locale:");
        System.out.println("Language: " + jvmLocale.getLanguage());
        System.out.println("Country: " + jvmLocale.getCountry());
        System.out.println("Display Name: " + jvmLocale.getDisplayName());

        String input = "na[xxx";
        Pattern pattern = Pattern.compile("[a-zA-Z_]\\w*");
        Matcher matcher = pattern.matcher(input);

        if(matcher.lookingAt())
        {
	    System.out.println("Matched: " + input.substring(0, matcher.end()));
        }
    }
}

Also, can you tell me the JVM version and OS? (Path name suggests Android)
Thanks!

[sh3llc0d3r]

Thank you for the quick reply!

2023-07-04 20:09:01.916 25683-25683 System.out Default JVM Locale:
2023-07-04 20:09:01.916 25683-25683 System.out Language: en
2023-07-04 20:09:01.916 25683-25683 System.out Country: US
2023-07-04 20:09:01.935 25683-25683 System.out Display Name: English (United States)
2023-07-04 20:09:01.935 25683-25683 System.out Matched: na

Dependencies is implemented through jitpack.io

OS is Android 13 in an emulator build with JDK 17. But I think it might be the Problem that Android 13 supports only Java code up to 11.

[clarisma]

We haven't tested the GeoDesk library on Android, but it doesn't look like it will run on any version of Android without modifications. As you've mentioned, even the latest version of Android only supports JDK 11. GeoDesk requires at least JDK 13 (for absolute bulk operations on ByteBuffer). However, the bigger issue is runtime bytecode generation (used by the Query Engine to support high-performance queries). Android does not build on the JVM, but instead contains its own virtual machine called Dalvik, which uses a different type of bytecode.

I created a separate issue to enhance GeoDesk with Android support. In the meantime, I'll have a look at the bug you've discovered. It's a "This can't possibly happen" kind of bug, so it should be interesting.

[sh3llc0d3r]

Android support would be great. Geodesk what just was I was looking for in terms of query speed.

Not to waste your time because I'm not sure it was clear: The parser "bug" was an error thrown on Android. Gradle build was fine but there are probably way more issues in the compiled .dex file that may lead to this bug eventually.

Keep up the good work.