Good afternoon, So I was wondering how you read headers in Java (assuming you know the spec for the header.)
Now in C I would have just read the number of bytes in the header into a buffer, and and changed the pointer reference to the chunk of memory to point to a strut that was a representation of the head. Was quite a neat solution.
In java I cant do that, is there an alternative? Or is it just a case of reading x bytes, into the required data type and moving on to the next x bytes?
That whole programming model is rather awkward in Java. The DataInputStream class lets you easily read individual big-endian primitives from a binary file, and you could skip a given number of bytes easily enough. But there's no way to read a whole struct into the Java equivalent in one fell swoop; you just have to read one primitive at a time.
If the file also originates in Java, one could use serialization (either in its binary or XML forms), and get a more elegant binding to Java classes and fields. That doesn't help with existing file formats, though.
Thanks guys, it was just a "what if". I hadnt been able to come up with a neat solution, beyond just reading the bytes and populating a datatype/object.
I was thinking more for legacy file types then for something originating form java, and binary files too, where serialisation/xml wouldnt be appropriate.
Is Java really big endian? another post I was reading suggested that, that was dependent on the VM, but I was sure when I was looking at manipulating trueSpace files I found that Java was Big Endian and that intel/windows was little so would have to flip the bytes or something.
Regardless of what may really be happening internal to the JVM (which is probably platform-dependent), EFH's point was that DataInputStream methods like readInt() are defined to operate in a big-endian manner. If the bytes were originally written with a DataOutputStream and methods like writeInt() then you don't have to think about it; it just works (because all the DataInput/DataOutput methods are defined as big-endian). If they're from some non-Java-based little-endian source, then yes you may need to flip the bytes around.