A DESCRIPTION OF THE PROBLEM :
There is virtually no documentation on the specification of endian and its ramifications in the jlink documentation aside from a simple description of the option: 'Specifies the byte order of the generated image. The default value is the format of your system's architecture.'. On specifying the endian as big (I'm on an i7 machine), the jlink image fails to start as Object cannot be found. I can't see any special handling when not specifying the endian (except the platform default is used to default that parameter as documented) and thus surely linking on a little endian platform, but running on a big endian platform is not possible. This surely breaks the idea of writing/compiling once and running anywhere, since it appears that jlink images are only usable if the endianness with they were created matches that of jvm they are run on. This should be documented clearly since at the moment java code might be released that will break as soon as it's tried on a machine of a different endian.

Alternatively, as an enhancement suggestion, the endianness in which the image was created could be recorded in the image, and if the JVM discovers the endianness is wrong, it does the swapping before running. Thus it's possible to specify an endian that will be quicker to load on the majority of your target platforms, but it will not break if it's used on a different endian platform. This would keep the concept of write once, run anywhere intact.