I know you figured it out already Kathey - am just adding a comment here for the record.
You're right that there is no longer an issue with a
DERBY-528 and a 10.2 client connecting to a 10.1 derby server, I reverted back to having CLEAR_TEXT_PASSWORD being the default SECMEC to use on client datasource (if EUSRIDPWD cannot be selected because of the current JVM restricting the use of 256-bit DH keys).
So, yes as it stands right now, the current
DERBY-528 do not cause impact changes for existing users of Derby whom would use a 10.2 client for instance.
Without DERBY-1517, a DRDA protocol exception will be raised if an invalid securityMechanism is specified for the server the client connects to - This was a fairly non-blocking and non-visible issue since all pre-
DERBY-528 DRDA secmec were supported by pretty much all existing Derby DRDA servers out there. Eventhough DERBY-926 needs to be addressed, DERBY-1517 will allow a new DRDA secmec (like USRSSBPWD) to be used as a fall-back default when EUSRIDPWD cannot be used, and no longer causing the protocol exception described in DERBY-926. Also, the sooner we fix DERBY-926, the better it is for no longer carrying servers that are returning the list of supported secmec's incorrectly.