The signature of ChronoLocalDate with a self type generic causes difficulties AFAICT in actually using the class.
This code will not compile:
{
ChronoLocalDate<?> date = chrono.dateNow();
date = process(date);
}
private <D extends ChronoLocalDate<D>> D processOK(D date) {
return date;
}
It does work using a concrete type, such as FooDate.
This seems like pretty basic usage of the API. What it would mean in practice is that no utility methods could be written stating that they return the same CLD type as the type that is input.
Some advice is given suggesting that wildcards should be avoided in return types, but auto-casting may not be the result is the best solution for methods like dateNow().
It should be considered that the best option may be to remove all generics from CLD/CLDT/CZDT even though that removes functionality from users of the concrete types. At least without the generics, they can be added in JDK 1.9 if a solution can be found.
See JSR 310 GitHub issue #292: https://github.com/ThreeTen/threeten/issues/292
This code will not compile:
{
ChronoLocalDate<?> date = chrono.dateNow();
date = process(date);
}
private <D extends ChronoLocalDate<D>> D processOK(D date) {
return date;
}
It does work using a concrete type, such as FooDate.
This seems like pretty basic usage of the API. What it would mean in practice is that no utility methods could be written stating that they return the same CLD type as the type that is input.
Some advice is given suggesting that wildcards should be avoided in return types, but auto-casting may not be the result is the best solution for methods like dateNow().
It should be considered that the best option may be to remove all generics from CLD/CLDT/CZDT even though that removes functionality from users of the concrete types. At least without the generics, they can be added in JDK 1.9 if a solution can be found.
See JSR 310 GitHub issue #292: https://github.com/ThreeTen/threeten/issues/292