JDO queries not working with Turkish locale

#1
    static void main() {
        Locale.setDefault(Locale.of("tr", "TR"));
        
        PersistenceManager persistenceManager = Utilities.getPersistenceManager("objectdb.mem");
        Query<Test> query = persistenceManager.newQuery(Test.class);
        query.setOrdering("this.x descending");
        query.execute();
    }
    
    @Entity
    static class Test {
        int x = 0;
    }

Running main crashes with:

Exception in thread "main" [ObjectDB 2.9.5_05] this.x  ==> descending <== 
javax.jdo.JDOUserException
Unexpected query token 'descending' (error 752)
 (position 7)    at com.objectdb.jdo.JdoQuery.execute0(JdoQuery.java:872)
    at com.objectdb.jdo.JdoQuery.execute(JdoQuery.java:747)

This is only happening in Turkish locale. I suspect that ObjectDB is converting strings to uppercase/lowercase with default locale instead of Locale.ROOT, so any word that contains "i" will get converted according to Turkish capitalization rules (i -> İ, I -> ı) and break parsing.

This is breaking every query that contains ordering, and possibly a lot more. I ran the query with breakpoints in java.lang.ConditionalSpecialCasing which handles Turkish and a few other locales, and there are a huge number of strings in ObjectDB classes that are being converted with Turkish locale.

#2

Good catch. Please try build 2.9.6_01, which switched to Locale.ROOT.

ObjectDB Support
#3

Queries appear to work, I'm still seeing breakpoint hits in ConditionalSpecialCasing from JDO classes which are bundled in the objectdb jar, for example:

at java.lang.ConditionalSpecialCasing.lookUpTable(ConditionalSpecialCasing.java:150)
at java.lang.ConditionalSpecialCasing.toLowerCaseEx(ConditionalSpecialCasing.java:107)
at java.lang.StringLatin1.toLowerCaseEx(StringLatin1.java:456)
at java.lang.StringLatin1.toLowerCase(StringLatin1.java:432)
at java.lang.String.toLowerCase(String.java:3704)
at java.lang.String.toLowerCase(String.java:3728)
at javax.jdo.spi.JDOImplHelper.<clinit>(JDOImplHelper.java:173)
at javax.jdo.JDOHelper$1.run(JDOHelper.java:181)
at javax.jdo.JDOHelper$1.run(JDOHelper.java:179)
at javax.jdo.LegacyJava.doPrivileged(LegacyJava.java:163)
at java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(DirectMethodHandle$Holder:-1)
at java.lang.invoke.LambdaForm$MH/0x00001fc001eec400.invoke(LambdaForm$MH:-1)
at java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder:-1)
at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:155)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.lang.reflect.Method.invoke(Method.java:565)
at javax.jdo.JDOHelper.doPrivileged(JDOHelper.java:2063)
at javax.jdo.JDOHelper.<clinit>(JDOHelper.java:178)

or

at java.lang.ConditionalSpecialCasing.lookUpTable(ConditionalSpecialCasing.java:150)
at java.lang.ConditionalSpecialCasing.toLowerCaseEx(ConditionalSpecialCasing.java:107)
at java.lang.StringLatin1.toLowerCaseEx(StringLatin1.java:456)
at java.lang.StringLatin1.toLowerCase(StringLatin1.java:432)
at java.lang.String.toLowerCase(String.java:3704)
at java.lang.String.toLowerCase(String.java:3728)
at javax.jdo.spi.JDOImplHelper.assertOnlyKnownStandardProperties(JDOImplHelper.java:1181)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:804)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:720)

I don't know whether it's in scope for objectdb to fix these cases, since these are from javax.jdo packages, but at minimum whoever is in charge of javax.jdo should know about this issue.

#4

Yes, ObjectDB switched to using Locale.ROOT in build 2.9.6_01, but the embedded JDO library remains unchanged and still calls toLowerCase() internally (for property validation, error handling, etc.).

Please note that JDO support in ObjectDB is nearing end-of-life, and we strongly recommend migrating to Jakarta Persistence (JPA).

If you disable this diagnostic breakpoint, are you experiencing any actual functional failures or crashes in your application?

ObjectDB Support
#5

I haven't observed any other issues so far, but I haven't done a lot of testing. If anything comes up, I will open a new issue. Do you have an estimate for when JDO support will be removed?

#6

JDO will remain in ObjectDB 2.x, but will be dropped in ObjectDB 3.x (release date yet to be determined).

Although we prefer not to modify bundled JDO classes, we are open to patching them if this case-conversion behavior causes actual failures in your environment.

We will close this ticket for now, but please let us know or reopen it if necessary.

 

ObjectDB Support

Reply