This adds some extra checks/validation affecting the ImageIO JPEG writer plugin
The cases are - the constructor for a JPEGHuffmanTable validates the array parameters and copies after the validation. It would take the application to be doing something very odd for this to be a problem, but there's no cost in doing the copy before hand. - ImageIO's native JPEG library is compiled to support baseline JPEG only. This means 8 bit quantization values in the range 1 -> 255. the image I/o native glue code should enforce this. - The native glue code has no explicit check for null Huffman table data . This isn't normally possible, but direct manipulation of a meta data tree can be used to force it. In which case we have a null de-ref crash. A simple check for null should fix this. I was able to devise a test for this, although it is very contrived code. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - 8393551 Changes: https://git.openjdk.org/jdk/pull/33217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=33217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8393551 Stats: 121 lines in 3 files changed: 115 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/33217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/33217/head:pull/33217 PR: https://git.openjdk.org/jdk/pull/33217
