Check generic signatures #163
Comments
I've examined the generics on the temporal classes twice now. It isn't possible to enhance their generics without making a terrible mess. Because Java doesn't have the Self-type generic, or the notional of parameter self-type generic where the class is final, and because LocalDate extends ChronoLocalDate, it is more or less impossible to go further than we have. This is unfortunate, but there you go. The call remains open to check |
TemporalUnit |
It should insist that the parameters are of the same/compatible types. |
This compiles, rather than being a compile error: Instant i = ...
ZonedDateTime z = ...
between(i, z) |
It only insists that they have a common supertype that subclasses temporal |
It makes sense to remove the generics, they are more useful in the case where the return type is related to the parameters. |
The generics should be removed from Chronology.getAvailableChronologies(). The raw types are just as useful. |
I don't think we should have raw types in API signatures. I would have thought there was a JDK/Oracle policy against it. |
It would be very odd for a brand new API to have raw types in API signatures in my opinion. |
Quite a few people compile with warnings switched on for raw types, this |
Remove some pointless generics - http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e5a10d4e6149 |
|
Raw types fixed with http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bf46149114e4 |
Nothing more to do on this. |
Ensure that the generics used are correct. This is specifically focussed on extends/super.
For example, the Chrono static comparators should perhaps use extends.
The text was updated successfully, but these errors were encountered: