Java 5 ; object persistence

[gusl]

I'm pleased about the Tetrad code being in Java 5, which really is a slightly different language. Java 5 has two nice features:

* nicer 'for' loops (++), such as:

for (int sampleSize : new int[]{1000, 10000}){ ... }

* Parametric types, which avoids all that unnecessary casting that Java is notorious for (+):

List nodes = dag.getNodes();
Node node0 = nodes.get(0);

Combined, we can now do:

for (Node node : dag.getNodes()) { ... }

instead of

for (int i=0; i < dag.getnodes().size(); i++) {
    Node node = dag.getnodes().get(i);
    ...
}

(although this translation would probably break if you remove an element from the list inside this loop without decrementing i)

-----------------

Sometimes, after your program has finished execution, you notice that some object (e.g. a graph) had a really interesting property... or, if the program is non-deterministic, and you notice a bug, you may want to run the same example again for debugging purposes (or the entire state of the program, if that were possible).

Unfortunately, the object is now gone, and all you have is its footprints. By the time you think of putting Object.serialize() in the code, it's too late: you have to pray that you'll run into that situation again.

What do you do?

Comments

[simrob.livejournal.com]

I would be remarkably interested if there *was* anything you could do if it's gone and garbage collected...

[gustavolacerda.livejournal.com]

I guess what I have in mind is: when I'm still in the development stage, the entire run of my program would get cached somewhere.

I guess this is expensive memory-wise, but maybe not if we only save the places where non-deterministic branching occurred (i.e. all places where we have "degrees of freedom"), and querying the run involves running the program again with using these fake-random values.

[pbrane.livejournal.com]

I guess what I have in mind is: when I'm still in the development stage, the entire run of my program would get cached somewhere.

You mean use a profiler? There are a few good free full-heap-coverage profilers out there, and quite a few more expensive ones, which let you keep a running heap trace you can run statistics on, toss around into debuggers, etc... they're kindof a pain to use sometimes (and yes, very memory hoggy by nature), but really rather necessary when dealing with multithreaded server code with nondeterministic bugs.

[bhudson.livejournal.com]

http://weblogs.mozillazine.org/roc/archives/2006/12/more_about_ambe.html

[bhudson.livejournal.com]

Oh, it's called Chronicle now.

http://code.google.com/p/chronicle-recorder/

[dachte.livejournal.com]

Wow, that's pretty hot. Java takes a few steps closer to being Perl. w000t

[cdtwigg.livejournal.com]

The former version of the loop could be significantly faster than the latter depending on the implementation of List (hence the use of Iterators in both the C++ and Java standard libraries).

[pbrane.livejournal.com]

Java 5 generics are indeed the shiznit - way more than just doing statically typed Collections, you can do crazy shit like turn Java almost into Lisp, by genericizing a simple filter:

public abstract class Filter<S,T> {
  public abstract T apply(S input);
 
  public <U> Filter<S,U> postCompose(Filter<T,U> next) {
    final Filter<S,T> first = this;
    return new Filter<S,U>() {
      public U apply(S input) {
        return next.apply(first.apply(input));
      };
    };
  }
}

public class SpeechToTextFilter extends Filter<AudioFile, TextFile> {
  public TextFile apply(AudioFile input) { /* do your transcription */ }
}

public class TranscriptPersistenceFilter extends Filter<TextFile, Integer> {
  public Integer apply(TextFile input) { /* persist, return DB id */ }
}

public class UnmarshallingFilter extends Filter<Integer, TranscriptObject> {
  public TranscriptObject apply(Integer dbId) { /* ORM translation to custom object */ }
}

...

Filter<AudioFile, TranscriptObject> fancyFilter = new SpeechToTextFilter().postCompose(new TranscriptPersistenceFilter()).postCompose(new UnMarshallingFilter());

for(AudioFile audioFile : audioFiles) {
  TranscriptObject alreadyPersistedTranscript = fancyFilter.apply(audioFile);
  // do stuff with it if you need to
}

[bhudson.livejournal.com]

I hate hate hate the way that Java and C++ do lambdas.

[pbrane.livejournal.com]

You mean, the way they *don't*? :)

[bhudson.livejournal.com]

Bit of both. They don't natively support it, but you can hack it like you did above.

IIRC, Java at least does have closures. C++ does not (gcc will at least tell you as much), so you have to implement them by hand.

[pbrane.livejournal.com]

Java doesn't *really* have closures: since it's not lexically scoped, you don't really get to have access to the full set of variables in scope at the time of creation of your anonymous inner class - just the final ones (hence the need for my hacky 'final Filter first = this;" declaration).

I catch myself doing Wrong Things when I make the mistake of pretending the closures in Java are as "real" as they are in, say, Javascript.

[bhudson.livejournal.com]

Oh, crap, that's right, I'd forgotten about that 'final' nonsense. This holds for C++ also.

Eh, we should all just go home and write FORTRAN.