[mathias]

OK. Sounds super alien to me, never heard of or seen before.

If i may, can i ask why you do all this reflection stuff? Why not just cast it to a LocalDate and make the method calls directly?

[Isomorphic]

Try googling “spring classloader problem” to see several hundred problems - a tiny subset of the bizarre problems that can come from classloader issues, which are especially rife with Spring.

We are forced to use Reflection because if you reference a class in your code in Java, the class must be present and loaded, even if never actually used at runtime. Therefore any class that might not be present has to be used via CRAPI (Java Core Reflection API - yea CRAPI is the real acronym).

Without using reflection for LocalDate, we could not continue to support old Java where such classes aren’t present.

We need to do the same thing for any optional libraries that we want to support: Hibernate.

Every framework has to go through acrobatics like this due to Java language limitations - just be glad you as an app developer don’t have to deal with it!

[mathias]

Thanks for the heads up. Guess i've never thought of it since i've never ran into it. Also, i don't really get it, the class has surely been loaded into the JVM long before this. Oh well.

Haha yeah thanks, you just made my day a bit better for not having to deal with backwards compatibility stuff on the server. It's enough with all the shenanigans on IOS and Android...

[Isomorphic]

It’s possible that would work. It’s also possible that relative placement of jars (eg system vs entire app server vs app-specific) could make a difference.

You may also be able to “prime” the system by eg, asking JSTranslater to translate some dummy data at server startup.

And of course you’ve already discovered the order-of-operations / concurrency nature of the problem, so that implies a number of app-level workarounds with reordering operations.

Unfortunately, getting to the root cause is a daunting task of basically running the JVM under a debugger.

[Isomorphic]

Just to follow up here - we’ve revisited the Reflection methods involved, and there is no plausible scenario that we can see where concurrent threads could cause an issue. Plus we have the previously mentioned concurrency test cases that exercise these APIs..

We could be wrong of course, so if you can find a way that we can reproduce the problem, we can of course look again.

[mathias]

Hey thanks for looking into this more. If I can, will let you know.