Dear Brian,
I understand this would be a massive undertaking.
Still, the date-time library was a mess before Java 8 and it has been
rewritten and found its way to most other libraries.
So while I understand this isn't going to be done any time soon, my
only question was whether it had been thought about at any time in the
past. And if the consensus at that time was 'well, it would be great
if we could do it, but it's totally impractical, so let's not do it' I
would be okay with that.
I also think the proposal of Stuart is reasonable though, but it seemed
to me that we had reached some sort of impasse in this discussion. As
Remi points out, we have (default) methods which sometimes throw
exceptions when they are implemented to signify they don't actually
implement the given feature, but we also have interfaces which add new
methods. So any choice we make here seems to be inconsistent with some
choice we made in the past, but such is the nature of software
development I guess.
Given the choices of what is actually possible, I would go the
interface route.
Kind regards,
Dave
On Wed, 2021-05-19 at 17:23 -0400, Brian Goetz wrote:
>
> > Has it ever been conceived to create an entire new API like how it
> > was
> > done for Dates and Times? Obviously this would be a massive
> > undertaking, but it seems to me we've just about reached the limits
> > of
> > how far we can stretch the current API.
>
> "This code is a mess, we should throw it away and rewrite it"
>
> -- every developer
>
> Don't confuse the volume of "I would rather do it this way" replies
> with
> the complexity of this issue; I think that's just the nature of the
> game
> ("Being the biggest crime of the last 50 years, and everybody wanted
> to
> get in the newspaper story about it.") Stuart's proposal is a
> measured,
> responsible, carefully-thought-through way to extend the framework we
> have.
>
> In addition to "massive undertaking", and in addition to "if you
> think
> you can't get people to agree on something the size of a golf ball,
> try
> to get them to agree on something the size of Montana", there's
> another
> massive problem here: migration. It's not just a matter of having a
> "better" Collections library; the collection interfaces we have
> (Collection, List, Map, Set) have found their way into the API of
> nearly
> every Java library. Moving to Collections II would then force a
> migration on every one of those libraries (or consumer of those
> libraries.)
>
>
