It's platform specific and maybe not so elegant but I'm not sure if
there's another way to do this.  You could build up a system command
line to run your app and invoke it via java.lang.Runtime.exec grabbing
the InputStream and OutputStream from the resulting process and using
them to read what your program writes and send input to it.

e.g.
String [] cmd = {
 "/usr/java/bin/java", "-cp", classpath, "my.class.with.a.main.Method"
}
Process p = Runtime.exec ( cmd );
InputStream in = p.getInputStream ();
OutputStream out = p.getOutputStream ()
//InputStream err = p.getErrorStream();

//wrap in/out in other streams
// read your "menu" from in
// write "1" to out
// etc.

Unless someone comes with a simple solution for this, here's an idea:
Try to rewrite your code so that you don't call the console readline
function directly, but with a function in between, lets call it
getConsoleInput(), that acts as a middle man and simple forwards your input
request to the actuall readline function, and then returns whatever input it
recieved. Make sure that your program still works by some simple tests.
Then rewrite your new function getConsoleInput() so that it instead of
using the console input function, it reads from a input buffer. Then you
write another function, that inserts stuff into that input buffer.

example:
...
int menuSelection = getInputInt();
if (menuSelection == 1)
...

public int getInputInt()
{
  while (inputBuffer is empty)... wait
  return Integer.parseInt(inputBuffer.getFirstInput());
}

public void addInput(String str)
{
  inputBuffer.add(str);
}

I guess this envolves threads some how, and syncronization.

This could actually be a good start to get your program refactorized. Maybe
in the future you want to change user interface to Swing or a web
application. Then you should separate the business code from the
presentation as much as possible.

/Jimi

OT, but why do you need to re-organise things?

Usually, there's two answers to that:
A) The code needs to be (more) maintainable to reduce the cost of
bug-fixes.
B) There are new requirements on the way and the code needs to be
(more) cost-effectively updatable.

(Both essentially reduce to: the code needs to be more flexible.)

If only (A) holds true, then it may not be worth your while
re-structuring the code. If this is an established product, then newly
discovered bugs will become increasingly rare; maybe the cost of these
bugs will be less than the cost of a re-structuring. You've inherited a
monster, so let him sleep.

If (B) holds true, then you might want to look into MVC-ing your code;
certainly, if there's any chance that the output might one-day go to
something other than a console (e.g., a web-page, a socket, a GUI,
etc.). This being the case, if you slice-off a non-display-specific
View interface, then you could also have a TestView implementation,
which will consume all you throw at it and can return what you wish (to
verify both Controller and Model).

In short, if you are going to re-structure, then it may be worth
examing whether certain aspects should be re-designed (or even just
properly encapsulated to allow for later re-design) rather than just
re-structuring the existing design into multiple classes.

Like I said, all a bit OT.

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.