Other Java stdlib packages can't depend on Joda-time. If it wasn't added and I used joda-time I'd have to convert to the old datetime classes if I wanted to use it with stdlib packages.

Another example was CompletableFutures which were inspired by ListenableFutures from Guava.

I can now use these with guarantees that they will be stable as Java has strong commitments to backwards compatibility.

The JRE should be self-sufficient. By bundling java.time, it can finally start offering methods that take and return those types, instead of the current jumble of millis, nanos, long+TimeUnit pairs, Dates, and Calendars.

There's a cost to discovering the consensus choices that I think inclusion in a standard lib minimizes. But there may be other similarly good ways to accomplish this. If I'm remembering correctly, doesn't Rust have a set of libraries that aren't in the standard library but are somehow vouched for? Maybe that's a similarly good approach to solve the discovery problem, I'm not sure.

There are libraries that are maintained by the project itself, but are not part of the standard library, yes.

Ok thanks. Is the intention for that to grow, as a curated set of libraries that isn't quite the standard library? Or so you think some of those will move into the standard library if they become canonical or stable enough?

We’ll see; it’s not a simple thing.

In theory they can move into the standard library, but none ever have. The process exists though.

I can think of a bunch of stuff that has moved or is moving from third party crates into the standard library: parking_lot, hashbrown, (minimal) Future trait. But I agree that no crate has moved wholesale into the standard lib.

parking lot and hashbrown moved their internals, replacing ones that already existed. This is probably a distinction that doesn’t actually matter but in my head it’s different for some reason, thanks for pointing it out :)

Is there a list of these somewhere? Crates.io doesn’t appear to let me sort by author.

This is the GitHub repository

https://github.com/rust-lang-nursery/

We’re in the process of deprecating the nursery, so they’ll end up in the rust-lang org at some point.

Stability? Guarantee that the api will continue to work and that no one will wake up one morning and left-pad the entire ecosystem?