Bouncy Castle is two things at once: a JCA provider (BC) that plugs into Signature, KeyPairGenerator and KEM, and lightweight APIs such as ECDSASigner that work without the JCA. bcpkix adds certificates, CMS, OCSP and the PEMParser that the JDK still lacks. Most JVM code that touches secp256k1, Brainpool, PGP or certificates depends on it.
Its ECDSA defaults match the JDK's: SHA256withECDSA produces DER with a random nonce and leaves s unnormalized, and verification accepts both halves. The differences are opt-in algorithm names. SHA256withPLAIN-ECDSA produces the 64-byte raw r‖s that JWS expects; SHA256withECDDSA signs deterministically, and the lightweight ECDSASigner with an HMacDSAKCalculator reproduced the RFC 6979 test vector exactly. As with SunEC, a raw signature handed to the DER algorithm throws SignatureException instead of returning false.
Curve coverage is what brings most people here: P-224 through P-521, secp256k1 and the Brainpool r1 curves all signed and verified, along with Ed25519 and Ed448. Register the provider and name it — KeyPairGenerator.getInstance("EC", "BC") — because the JDK's SunEC is consulted first otherwise and rejects secp256k1, as the sample avoids.
Post-quantum coverage in 1.86 is the broadest of the libraries checked: ML-KEM through javax.crypto.KEM, ML-DSA, SLH-DSA and LMS in the BC provider, and Falcon and XMSS in BCPQC. Try the algorithms in the post-quantum signature playground and inspect hybrid certificates with the PQ certificate inspector.
JcaPEMWriter writes EC private keys as SEC1 -----BEGIN EC PRIVATE KEY-----, which PEMParser reads back as a PEMKeyPair; tools that expect PKCS#8 need the key converted first. The DER ⇄ raw converter helps when a PLAIN and a DER signature get mixed up.