We Keep Coding

Launching an external .exe and reading in real-time what has been written in Console [duplicate]

This question already has answers here:
Run external program from Java, read output, allow interruption
(5 answers)
Closed 9 years ago.
I have been trying to work on this issue I had by searching thoroughly so as to find out what to do. However, none of the results I've found (at least until now) had suited my requests.
The fact is, I've got an executable JAR I've done. This jar starts an .EXE.
Now, the thing is, the EXE will keep on running the whole time, and I want to get whatever has been written in the console so as to write it on a JTextBox as soon as that is read.
Would you mind giving me an example of that? I would like to do it on my own, but my head doesn't seem to find out how.
Thank you very much.
EDIT: what I'm trying to do is a GUI for a gaming server
EDIT 2: for those saying its duplicate... wish it was... tried what the others explained but didn't work, so that's the reason I asked here..
EDIT 3: as I have been looking forward to find what the problem was, I will tell you that what I've done does not have any errors. However, I guess, it may be caused to the fact that the server (written in C++/C) may not output in a 'normal' way. May that be the reason? I hope so. Otherwise, I might be doing something really wrong.
Please notice I use InputStream in order to be able to read.. but well.

Basically, you need to start by running the process in some kind of background thread so there is no risk that it will block the Event Dispatching Thread.
Then you need to read the processes InputStream. As the input is read, you need to push these updates to the UI in such away so as not to violate the single thread rules of Swing. That is, you should ensure that all updates are made within the context of the Event Dispatching Thread.
Check out Concurrency in Swing for more details.
In this, I would recommend using something like SwingWorker. It allows you to monitor the process from a background thread, but has easy to use functionality to sync the updates back to the EDT.
Take a look at Printing a Java InputStream from a Process for an example

Making Eclipse show the topmost exception in its console instead of the full stack trace

Is there a way to make Eclipse show up in its Console the "top" exception instead of just printing all the stack trace and leaving me always with the screen filled with basically useless stuff? Here's a picture:
There are basically 2 things I might want to know in 99% of the times when there's an exception: it's name+message plus in which method it ocorred. None of them is visible without having to scroll up.
This is how I feel the data should be shown:
Is there a way to change this Eclipse's behaviour?

I know of no Eclipse feature that will do this.
I disagree that the IDE should do this. There's no way for the IDE to know what information in the stacktrace is useful or useless. Scrolling the console to the supposedly useful part of the stacktrace based on some heuristic might help you a little bit today, but tomorrow it might hinder you a lot. And the problem / danger is likely to be worse if you start folding or editing the stacktrace displayed in the console window.
Use the scrollbar Luke!
If you really think this would be a good idea, implement it and submit a patch to the Eclipse developers. Or create a plugin. Or use a different IDE.
By the way, the screenshot you included in your comment does not show an IDE scrolling a console window. Rather it is showing an exception that has actually been delivered to the IDE as-is. Eclipse can do this too ... to some degree ... as illustrated by the JUnit test view, the Error view and so on. But this doesn't work if the stack trace has been rendered as text and written to a console window. (For a start, the text format of a stack trace is not actually specified.)

I don't think there is a way in Eclipse to do this.
But I think the IDE actually has nothing to do with this. It is the JVM that is printing that output to the console since your program isn't catching the exception. If you ran it from command line, you would see the same output.
I think the program should handle the exception and print the desired level of information to the console.

Indeed, the IDE has nothing to do with this. And you might want to rephrase that opinion as sometimes the useful information is not always the last executed line, but somewhere deeper in the stack trace (ex: an invalid value is passed to a method, down to the nth level where the exception occurs.)
Eclipse can't change this behavior as this is a run-time behavior of the JVM; when the exception is not catch, System.err is used to output the stack trace. You can change this by replacing the error output stream.
The PrintWriter that you set could keep the original copy of System.err and simply discard anything you don't care (i.e. anything matching "^\s*(java(x?)\.).*", or something) But the work around is not worth the trouble.
The better solution would be to catch and handle your exceptions and output something useful instead. The Java API is pretty explicit when some method throws an exception. There should be no surprise there.
Or another solution would be to avoid exceptions at all and be glad that Java prints a much useful stack trace to begin with and help you debug your application. Many language actually don't do that (or just not as good). If and when you deploy an application to a client, you'll actually be glad that the user sends you the complete stack trace instead of just a one-liner where the exception occurred.

You can use an eclipse plugin like grepclipse or GerpConsole to filter console's output with regular expresions.

Eclipse addon to temporarily disable/remove catch blocks

I've seen questions answering this with Visual Studio
vs-2008-addon-to-temporarily-disable-remove-all-catch-block
how-to-temporarily-deactivate-all-try-catch-blocks
but can't find anything regarding either Java or Eclipse. Does this feature exist, or is there some type of workaround I can use instead?

I don't know of any specific way to disable catch blocks, but what you could try is having eclipse automatically break on exceptions.

There is no standard feature to do so (except rather tricky byte code rewriting).
You may, however, tell Eclipse to set a breakpoint when a given exception is thrown. The easiest way to do so, is to paste the troublesome stack trace to the stack trace panel in the Console, and click the exception name (not the lines refering to code). This will open the appropriate dialog.

I will give the same answer that Mr Skeet gave in the second link.
Why would you want to do this?
If you are having problems with error handling hiding true errors, you should make sure the error handlers log properly and control the logging levels. I'm thinking something like Log4j.
The only valid reason someone would need to do this would be if they were maintaining someone else's lousy code with a ton of catch (Throwable t) {}. In this case you have my condolences.
PMD will scream about this kind of thing, and except in very specific circumstances it is best to rip out any eating error handlers, or at least replace them with logging.

No stack trace generated on client site for NullPointerException?

I've been learning Java for about a month now, and not very familiar with a client/server situation like this one.
Basically I ran into a situation where our client java software (GUI) displayed a nullpointerexception popup but no stack trace on the client side. Someone had to go check the server side for the stack trace.
My question is, shouldn't the client side receive this precious information as well? Are situations like that ok, the rationale being one only needs one copy of the stack trace?

Not really. It is not recommended to show the way your app works from behind to the client. Mainly for security reasons. Your stacktrace shows all the objects being called, methods and if compiled with debug info, even lines. That's too much information for the client, it is ok to have it on the server.
This among SQL injection, Cross side script and others that I cannot remember, improper exception handling is a security vulnerability.
EDIT:
Here are other vulnerabilities ( although I don't see this one listed :( )
http://en.wikipedia.org/wiki/Vulnerability_(computing)

The client only needs to know hat it needs to know.
In alot of cases it perfectly fine to not show any stacktraces on your client.
Your users should get clear error messages but dont care about a stacktrace.
For debugging purposes a stacktrace is generally lost anyway, application gives errors, users restart it and gone is any excpetion, so if you need to know the errors use a logging framework.

Are there tools that log user actions to help reproduce bugs? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
As a test engineer, I often engage in exploratory testing. When I encounter a bug, it is not always immediately clear which steps led to the problem. So, obviously, I have to find the required steps to reproduce the problem. Depending on the situation, this can take a large amount of time.
What would be really helpful is a logging tool that keeps track of mouse and keyboard actions and possibly also stores the properties of components that have been clicked (the AUT is written in Java).
I could simply not find a suitable tool, but maybe my search approach is erroneous.
Could anyone point me to the right direction?

This question lists tools that can be used test web applications. Some of the answers may be useful.
One for example is Selenium - a mozilla plugin that records your actions and can be replayed later.

Log4J is an apache logging tool for Java with many options for outputting logs.
The nice thing about it is that you can insert as many log messages in the code and switch them on and off based on a logging level as you see fit. So for instance, you have debug messages and info messages. if you insert some debug messages and some info messages in your code then you set the logging level to debug, then you find all debug and info messages are logged.
If you set the logging level to info then only info messages are logged. You have other levels too.
EDIT: I re-read the question and realized that I did not answer correctly...sorry. But, you could put logging statements into the actions in the Java code and accomplish the same thing that you want. It does require a recompile though.

if your testing does NOT take a whole lot of time, you can record your actions(including the whole screen) into a video. You could replay the video to see how the application responded during all your exploration.
1) http://camstudio.org/
2) google for "free screen video capture" for more.
BR,
~A

You may want to check out BB Test Assistant. I saw a very early version of this and was impressed. I've also heard good things from people who have used it since then.

In addition to #anjanb suggestion about screen capture, you can run your program under a debugger that records its execution and allows you to step back through the trace.
Omnicore CodeGuide has pretty good implementation of the concept (though you need to postprocess your bytecode). It is a commercial software but it's reasonably priced. Not sure if it's under active development though.
Another (free) product is the Omniscient Debugger which I tested a few years back and found to be inferior to GC (used too much memory, unacceptable slowdowns). Still I see on their webpage that they have made some progress so you might want to check it out.

Check out ReplayDIRECTOR: http://replaysolutions.com/
Very useful for exploratory testing, as it records all the interactions of your Java app with its surrounding environment (user input, system calls, DB responses), and allows later replay of the recorded session, with the application actually running and executing the same path through the code. The recorded inputs will be fed to the application exactly as during the recording.

There's also Session Tester:
http://sessiontester.openqa.org/
Session Tester is an exploratory testing tool for managing and recording Session-Based Testing. Session Tester has a timer so you can keep your test sessions at the desired length, and it provides an easy way to record session notes. Notes are stored in an XML format that can be converted to HTML, or be transformed into whatever form you wish.