Very Hard Disagree. JDBC is pretty amazing actually. Thats why you find so many Database tools and wizards written in Java as opposed to Rust.
Regarding async - With Java 19 virtual threads , you have newer versions of JDBC drivers support async with none to minimal changes. Example: https://medium.com/oracledevs/introduction-to-oracle-jdbc-21...
I am very, very glad that human civilisation standardised on one system for gears instead of every manufacturer making their own special snowflake.
Java is much older and bigger than Rust. I don't think its level of database tooling is noticeably better than other big languages with less of a standard database API (e.g. Python).
> Regarding async - With Java 19 virtual threads , you have newer versions of JDBC drivers support async with none to minimal changes.
So it's only taken what, 15 years, and even then it's only been done because they found a way to make it happen without having to actually change the API (which it remains to be seen how well that actually works in practice - I'm pretty skeptical because other platforms have tried and failed with that approach).
DB-API 2.0 (PEP 249) is very much a standard database API.
That's just a quote from a 10 years old talk by Kenneth Reitz, and it's quite an overstatement.
(JDBC isn't actually in the standard library IIRC but it's a JSR, so it's an "official" part of the platform and that creates a lot of pressure to follow that)
I rather have outdated code that works, than not having anything at all.
Only if your dependency management is bad.
And if you're stuck running on e.g. an old install of the language, there's at least a chance that the third party library will support it, whereas if you want a new standard library feature you're SOL.
And on top of that download half of the Internet for doing an hello world with error handling or asynchronous code.
Please give an example of good dependency management in any language. It seems to be one of these subjects draining constant displeasure.
I'm not advocating against third party libraries, I just think a reasonably rich standard library sets a good foundation for them.
If your dependency management is any good then there's nothing to lose and a lot to gain from splitting your libraries out and allowing them to have independent release cycles. You can always do "platform" releases that aggregate together a bunch of finer-grained libraries with versions that are known together if you have a use case for that; going the other direction is a lot harder.
I would say so, although splitting an existing standard library is still extremely painful and cumbersome thing to do (I don't think any other major language has seriously attempted it) - exactly why it's better to avoid having a large standard library to start with.
> Is Java's standard library small ?
I'd say no, but the parts of it that are used nowadays are. For example there is an HTTP client implementation in the standard library, but it's very rarely used by today's Java programs since its design is quite dated.
> This is huge for things like database drivers which might become outdated or not support certain features. In Go switching database drivers in as simple as importing the new library. You dont have to change your code.
The effect is that every database driver becomes outdated and doesn't support certain features, instead of just a few. Python people have a saying that the standard library is where modules go to die. Java's database drivers massively lag behind (e.g. there's still no good async support for most of them), because JDBC is a lowest common denominator that every driver has to be dumbed down to, but is established enough that it sucks all the oxygen away from any efforts to write better drivers.
Far better to keep the standard library small and allow modules to update on their own terms and their own schedule. If the library you're using does what you need, you can stick with it, but a better alternative (which always means a new interface in practice - the idea that you can make substantial improvement without changing the interface is mostly a myth, because the interface is the most important part of a library) can appear and compete on its merits, and if the improvements are worth migrating to then it will win out.