Sorry, I meant to write the "the first two I'm here's".

Please stop asking folks to "rate" your posts.  In the first place, not
everyone uses your little kiddie reader.  But since you asked -

I rate your post jejune and in violation of netiquette.  You top-posted
instead of inlining your response.  You asked for a rating instead of focusing
on helping the person whom you answered.  As far as your help, you misquoted
the OP:

You said:

but the OP said:

They saw two "I'm here" outputs, not one.

So your post rates: POOR.

I read the OP's post as indicating it is exiting without an error
message, rather than hanging. Infinite loops tend to mean hanging, or
an eventual Error due to memory use or stack overflow.

A symptomless exit shouldn't result from readObject() unless one of
four things is true:
a) a non-Exception Throwable is thrown (likely an Error), caught
 (further up the call chain), and the handler exits silently without
 dumping a stack trace. This eliminates the default
 uncaught-exception handlers that come with the JRE.
b) Something under readObject() calls System.exit(0) or similarly.
  This could be in a user class readResolve() method or similar
  location.
c) The exit is caused outside of Java, e.g. through JNI or a
  Runtime.exec("kill -9 " + myJavaProcessPID) or something of the
  sort, again reached via a custom writeObject() or similar method
  in a serialized class.
d) The deployment JVM has a bug, which can cause it to silently exit
  with no diagnostic other than due to System.exit(), SIGABRT, or the
  OS killing it without letting it run a signal handler first.
  (I assume here that a normal JVM will report SIGSEGV etc. but not
  SIGABRT, usually resulting from a user attempt to abort a process.
  Of course, a lot of signals such as SIGSEGV themselves indicate
  bugs in either the VM or JNI native code.)

These are ordered roughly by descending likelihood.

I'd catch Throwable and see if it catches anything. If not I'd then
check the custom serializable classes' serialization-related methods
for any wackiness. If nothing turned up I'd now suspect a bug in
either the VM or the native code associated with serialization, so a
JRE bug, especially if you're using a weird non-Sun JVM or an old
version. If you're compiling to native code rather than bytecodes
using e.g. Jet then it's most likely a compiler bug or some kind of
corruption that screws up signal handling so you don't get a clean
segfault dump or similar. (How well does Java-compiled-to-native-
binary-executable cope with out of memory conditions? Do these even
have garbage collection? They must, though, I'd think, since the Java
code won't have explicit memory management like free() calls...)

Of course the wisdom of having broad catches like catch (Exception) is
a whole other topic. I'm assuming that your catch (Exception) and
various System.out.printlns are all part of your debugging efforts
and, as such, are temporary. I'd leave a function like that with a
finally block to close any open streams and tack a "throws
IOException" onto the method signature once I had it working, also
catching ClassCastException and rethrowing as an IOException subclass
indicating that the file was corrupt or in the wrong format, since the
object not being a Universe is presumably a file error and should
therefore be handled as an I/O exception. There's also a class not
found error or exception readObject can throw deserving like
treatment, since an object of a class unknown to the application is
clearly not a Universe. Aside from transforming these runtime
exceptions and errors into the checked IOException I'd not catch or
handle anything in gLoadUniverse().

Thanks for all responses. It was an Error - Out of memory.