@Jeremy - you’ve changed your reply since I first read it! :emo:
Anyway, I disagree with Riven’s fallback in this case, as it requires writing an unnecessary code path that will not be required. If you want a clean way to do this without breaking encapsulation, then wrap the pixel array into an image as below. This way you don’t access any ‘protected’ data and fully follow the spec. It also protects you from two other issues you’ll never see in practice - data offset and scanline.
int[] pixels = new int[width * height];
DataBufferInt db = new DataBufferInt(pixels, pixels.length);
ColorModel cm = ColorModel.getRGBdefault();
WritableRaster raster = Raster.createPackedRaster(db, width, height, width, cm.getMasks(), null);
BufferedImage image = new BufferedImage(cm, raster, false, null);
// play with pixel array as you want
Load of rubbish! createCompatibleImage() just means you have an image in the same color model as the screen, and so is (theoretically) faster to draw to the screen. If you’re doing direct pixel manipulation you want a guaranteed color model to work with. Drawing to the screen is only a small part of the overhead, and there are optimized paths for converting default RGB color models.
That’s Java! It’s pass-by-reference by default, which means if anything accepts a mutable object, it should respond to changes in that object. This is used all over the JRE - eg. passing models into Swing components. Anything that has pass-by-value semantics, which being Java means cloning or otherwise copying data, says so in the documentation.
I’ve been doing loads of stuff with direct pixel manipulation for over ten years - I’m glad you’ve popped up to tell me it doesn’t work! 
They’re perfectly “practical” for simple things and specific use cases, and also potentially as a learning tool.