On Thu, 12 Mar 2026 00:27:13 GMT, Shawn Emery <[email protected]> wrote:
>> It did occur to me that with the previous code, sometimes you could get >> `IKE` and sometimes `AIOBE` depending on the values. For example, for >> `DESEdeKeySpec`, a key of length 10 and an offset of -1 would throw `IKE` >> but a key length of 24 and offset of -1 would throw AIOBE. One of these is a >> checked exception, and the other unchecked, so applications could handle >> these differently. >> >> These classes should not be used much and these are invalid values, but just >> to be safe, I would probably keep the key length check before the negative >> offset check to preserve the above behavior. > > Good point on preserving IKE behavior with invalid key length (with offset) > vs. throwing AIOBE with invalid offsets. I've updated the PR accordingly. I > believe that we can keep the null key check where they didn't exist before > because of the following reasons: > i) preserves existing IKE behavior for this scenario > ii) good practice to always check and throw exception explicitly before > dereferencing Thanks, this is looking good. Can you also update the CSR with the latest specification changes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30069#discussion_r2926476767
