querydsl-sql : Joda time should be optional

[amanteaux]

I am using Java 8 so I don't want Joda time in my classpath.
Indeed it messes with the imports: if I want to use a java.time.LocalDate, I have to be careful not to import org.joda.time.LocalDate.

Currently if I try to exclude Joda time from my classpath, I cannot initialize Querydsl because in JavaTypeMapping, the CalendarType is registered and it depends on Joda time.
Moreover:

• still in JavaTypeMapping, Joda time types are registered,
• the Configuration class is final and reference JavaTypeMapping, so there is no way around.

In a first step, the modifications that needs to be done are:

• Refactor AbstractDateTimeType to remove the Joda time dependency,
• In JavaTypeMapping, do the joda time initialization the same way java 8 types are registered,
• Mark joda time as optional in the pom.xml :)

If that is ok, I can do the change.
However, it is a breaking change: libraries and projects depending on querydsl-sql and using joda time will have to explicitly add joda time in their pom.xml, gradle etc.
So the version on which this development will be made has to be decided.

[janneri]

Spring Boot will autoconfigure a formatter when joda-time is in classpath. The formatter wants a newer version of joda-time than querydsl. So to me, the joda-time dependency seems pretty useless in 2020 and it's causing problems. I would greatly appreciate this fix!

p.s. Declaring joda-time as a dependency is a trivial fix. I wouldn't worry about this as a breaking change.

[Neikius]

Spring Boot will autoconfigure a formatter when joda-time is in classpath. The formatter wants a newer version of joda-time than querydsl. So to me, the joda-time dependency seems pretty useless in 2020 and it's causing problems. I would greatly appreciate this fix!

p.s. Declaring joda-time as a dependency is a trivial fix. I wouldn't worry about this as a breaking change.

Same here. Please take the joda-time out.

[lagnat]

Another vote to address this issue. Thank you.

[digsim]

Same problem here, we can't update spring-boot any longer. Would be great if we can get rid of joda-time.

[germatpreis]

Same problem here.

[daniel-shuy]

I've decided to take up this task.

The main issue is how to replace joda-time's DateTimeFormatter.

There are 4 alternatives:

• Use SimpleDateFormat. The main issue with this is that SimpleDateFormat is not thread-safe and is expensive to initialize, which would require creating new instances of SimpleDateFormat for each thread using ThreadLocal, which has a performance cost.
• Import Apache Commons Lang to use FastDateFormat, a thread-safe equivalent to SimpleDateFormat. This would however introduce Apache Commons Lang as a new transitive dependency.
• Increase QueryDSL's Java target version to Java 8, which would allow us to use Java 8's DateTimeFormatter. This would however require dropping support for Java 6/7.
• Use Java 8's DateTimeFormatter if Java 8 is available, else use joda-time's DateTimeFormatter if joda-time is imported, else fallback to SimpleDateFormat. This would however greatly increase the code complexity.

[lagnat]

Java 8 is my vote.

[daniel-shuy]

Java 8 is my vote.

That's my preference as well, however I would need someone from the QueryDSL team to make the decision, as it is a major change

[jwgmeligmeyling]

We want to keep supporting Java 7 for 4.x. Java 8 API's can still be used through reflection though. As long as they are not imported, which would prevent classes from loading on Java 7.

I strongly discourage writing a Java 8 only solution, because it would just delay how soon this can be integrated, and the demand is high.

Also, lets try not to introduce commons lang as a transitive dependency, looking at the Guava discussion, it appears people really dislike dependencies shipping other dependencies.

[daniel-shuy]

@jwgmeligmeyling agreed. I've created a PR using the SimpleDateFormat with ThreadLocal approach.

[daniel-shuy]

Good news everyone! The upcoming QueryDSL 5.x release will require Java 8+, which allows us to remove the transitive dependency on joda-time, using the Java 8's DateTimeFormatter approach, which imo is the cleanest approach.

Many thanks to @jwgmeligmeyling for the Java 8 migration, and for reviewing and merging the PR.