Actually, I’d like turn the problem around, and say I’m surprised that so many different platforms and tools actually produce the same values. 🙂
JPEG is lossy
First of all, JPEG is a lossy image compression method. This means that reproducing the exact data of the original is not possible. Or, if you like, several different pixel values may all be “correct” in some way.
The technical reasons why not all JPEG software produce the exact same values from the same source file, is typically different rounding/clamping of values, or integer approximations of floating point operations for better performance. Other variations may stem from different interpolation algorithms applied to restore the subsampled chroma values, for example (ie. a smoother image may look more pleasing to the eye, but isn’t necessarily more correct).
Another excellent answer to a similar question states that “The JPEG standard does not require that decoder implementations produce bit-for-bit identical output images”, and quotes the Wikipedia JPEG entry:
[…] precision requirements for the decoding […]; the output from the reference algorithm must not exceed:
- a maximum of one bit of difference for each pixel component
- low mean square error over each 8×8-pixel block
- very low mean error over each 8×8-pixel block
- very low mean square error over the whole image
- extremely low mean error over the whole image
(Note that the above talks about the reference implementation only).
However, with some luck, it seems that all of your software/tools actually end up using (some version of) libjpeg. Because they all use libjpeg, the source of the differences you see is most likely not related to the JPEG decoding.
Color Spaces
Even if all your software converts the JPEG file to a representation using RGB values, there could be differences in the color space they use for this representation.
It does seem that all of the software you are using actually displays the RGB values in the sRGB color space. This is probably the most standard and widely used color space used in mainstream computing, so that is no surprise after all. As the color space is always sRGB, the source of the differences you see is most likely not the color space.
ICC profiles and color matching
The next possible source of color differences, is that color matching (as done by a Color Matching Module, CMM or Color Management System, CMS) is not an 100% exact science (see for example this document on black point compensation or read some of the more technical posts from the Little CMS blog).
Most likely the software running on Mac OS X are using Apple’s CMM, while Java is using Little CMS always (from OpenJDK 7 or Oracle JDK/JRE 8), and most software on the Linux platform will likely also use the open source Little CMS (according to the Little CMS home page, “You can find Little CMS in most Linux distributions”). Software on Windows will likely deviate slightly as well (I haven’t been able to verify if Paint.Net uses Little CMS, Windows’ built in CMM or something else). And of course, using Adobe’s CMM (ie. Photoshop) will likely deviate as well.
Again, with some luck, a lot of the software you tested uses the same CMM or CMS engine, Little CMS, so again you will have a lot of equal results. But it seems that some of the software you tested uses different CMMs, and is a probable source of the slight color differences.
In summary
The different pixel values you see are all “correct”. The differences stem from different implementations or approximations of algorithms in software, but that does not necessarily mean that one value is correct and the others are wrong.
PS: If you need to reproduce the exact same values across multiple platforms, use the same tool stack/same algorithms on all platforms.