Getting raw data of an object in memory

[Boris Punk]

Is there anyway to do this? Serialization looks cumbersome and I want to
dump the data of an object onto disk.

eg.

class AClass{
AClass(){
}
}

how do you get a representation of this in byte form? It can't be that
difficult to grab from memory, dump to disk, then retrieve back into memory
again?

Thanks

 

[Joshua Cranmer]

Is there anyway to do this? Serialization looks cumbersome and I want to
dump the data of an object onto disk.

Use serialization. If you are using mostly POD-ish classes (to steal a
C++ term) and avoid native data, the defaults for serialization should
work pretty well.

eg.

class AClass{
AClass(){
}
}

how do you get a representation of this in byte form? It can't be that
difficult to grab from memory, dump to disk, then retrieve back into memory
again?

If you want to pull it back into memory without using serialization, you
would have to create your own serialization-esque approach if you wanted
it to persist across sessions, and probably would need to even if it is
in the same JVM instance. Once you get to the actual memory of the
object (which is not trivial, and would involve at best fragile pointer
magic in native code and at worst would be an ugly kludge which never
works reliably for anything beyond the most trivial setups), you would
have to figure out what all the objects were referring to and find some
way to serialize that, or find out how to patch that data in when
pulling back into memory.

Or, you could take the easy route and use a framework which does all of
that for you written by people who have a much better idea of what needs
to be done. It's called "serialization."

 

[Mike Schilling]

Is there anyway to do this? Serialization looks cumbersome and I want to
dump the data of an object onto disk.

eg.

class AClass{
AClass(){
}
}

how do you get a representation of this in byte form? It can't be that
difficult to grab from memory, dump to disk, then retrieve back into
memory again?

Java won't play those games. For one thing, there's no defined order of
fields within an object.

 

[Owen Jacobson]

Is there anyway to do this? Serialization looks cumbersome and I want
to dump the data of an object onto disk.

eg.

class AClass{
AClass(){
}
}

how do you get a representation of this in byte form? It can't be that
difficult to grab from memory, dump to disk, then retrieve back into
memory again?

Thanks

This is one of the major differences between Java and its most obvious
ancestors: Java does not specify nor expose anything about the internal
representations of objects to programs. This has two advantages: the
JVM is free to reorganize objects much more freely than you might
expect, and it's not possible for a programmer to introduce "invalid"
objects, accidentally or otherwise.

You can *define* a byte-oriented or text-oriented representation for
your objects, and that's exactly what the built-in serialization
protocol does: what comes out is not the JVM's in-memory
representation; instead, ObjectOutputStream builds up a description
according to published and documented protocol rules. The resulting
byte stream is fairly resilient to changes in the runtime environment:
a serialized blob from Java 1.0 is theoretically still deserializable
into an object under Java 1.6 (the current version), more than ten
years later, assuming you have a compatible class definition around to
deserialize it with.

You're not limited to using the built-in (and rather opaque)
byte-oriented format, either: there are a lot of easy-to-use object
marshalling libraries for a lot of different formats out there. XStream
and JAXB can marshal and unmarshal objects to and from XML with very
little code investment, and libraries like gson can do the same with
JSON, giving you some good options for human-readable and
human-debuggable representations. Libraries like Google's protocol
buffers give you some more flexibility in designing your own
byte-oriented representations of your objects, if you prefer.

Hope that helps give you some idea as to where to start looking,

-o

 

[Arne Vajhøj]

Is there anyway to do this? Serialization looks cumbersome and I want to
dump the data of an object onto disk.

eg.

class AClass{
AClass(){
}
}

how do you get a representation of this in byte form? It can't be that
difficult to grab from memory, dump to disk, then retrieve back into memory
again?

You can use Java standard serialization, which will store the data
plus some meta data.

Or you can write your own custom serialization.

If you are interested in the last then I have a little
library that allows this syntax:

import dk.vajhoej.record.FieldType;
import dk.vajhoej.record.Struct;
import dk.vajhoej.record.StructField;

@Struct
public class Data {
@StructField(n=0,type=FieldType.INT4)
private int iv;
@StructField(n=1,type=FieldType.FP8)
private double xv;
@StructField(n=2,type=FieldType.FIXSTR,length=8,encoding="ISO-8859-1")
private String sv;
public int getIv() {
return iv;
}
public void setIv(int iv) {
this.iv = iv;
}
public double getXv() {
return xv;
}
public void setXv(double xv) {
this.xv = xv;
}
public String getSv() {
return sv;
}
public void setSv(String sv) {
this.sv = sv;
}
}

Arne

 

[Kevin McMurtrie]

Is there anyway to do this? Serialization looks cumbersome and I want to
dump the data of an object onto disk.

eg.

class AClass{
AClass(){
}
}

how do you get a representation of this in byte form? It can't be that
difficult to grab from memory, dump to disk, then retrieve back into memory
again?

Thanks

sun.misc.Unsafe will do it. I'm sure you'll find that it's a very aptly
named class. It's like the old peek() and poke() but decades after
fixed memory addresses when out of style.

I second the recommendation for serialization using ObjectOutputStream
and ObjectInputStream. You can write your own readObject and
writeObject methods when you find that the default serialization isn't
efficient.

 

[Eric Sosman]

sun.misc.Unsafe will do it. I'm sure you'll find that it's a very aptly
named class. It's like the old peek() and poke() but decades after
fixed memory addresses when out of style.

Before getting too enthusiastic about sun.misc.Unsafe, or any
other sun.xxx package, bear in mind that (1) the package and
everything in it is subject to change without notice, (2) "change"
includes "incompatible change," and (3) sun.xxx packages might not
even exist if you're not using Sun's own JVM. See

http://java.sun.com/products/jdk/faq/faq-sun-packages.html

 

[Mike Schilling]

Before getting too enthusiastic about sun.misc.Unsafe, or any
other sun.xxx package, bear in mind that (1) the package and
everything in it is subject to change without notice, (2) "change"
includes "incompatible change," and (3) sun.xxx packages might not
even exist if you're not using Sun's own JVM. See

http://java.sun.com/products/jdk/faq/faq-sun-packages.html

And (4) that almost every method in sun.misc.Unsafe is native, so don't even
think about extracting the class file and trying to use it with a foreign or
off-version JRE.

 

[Stefan Ram]

again?

See also:

http://www.codeinstructions.com/2008/12/java-objects-memory-structure.html