Colors for debug texts

[Fedor_van_Eldijk]

Is there a way to get colors in the text I sent to the debug console?

This does not work:
System.out.println(DBGContext+ "\u001B[41m" + _text + "\u001B[0m");

[sgold]

The debug console, in this case, meaning the Netbeans-based SDK?

I’ve never tried to do this. The Apache Netbeans site has a very old HOWTO that might provide a clue.

[yan]

1. Use logback or log4j2 instead of System.out for debug console output.
2. for logback you can use color patterns.
   ch.qos.logback.core.pattern.color (Logback-Parent 1.5.5 API)

or just use System.err.println(“”) to output RED text.

[tonihele]

@yan

Use logback or log4j2 instead of System.out for debug console output.

Also one tip is to use a facade. SLF4J or Java’s own logging API (available from Java 9 and onward). Hook the facade then to actual logging implementation such as the already mentioned ones.

This does not change the outcome of course. This is just a type of architectural choice that potentially helps you in the long run. Only downside is that you might not get access to some logger specific stuff in the code (but you need to configure logger anyway so you can probably get around this anyway).

[pspeed]

slf4j for the win.

[Fedor_van_Eldijk]

Thanks all, it looks like there is more to it than I had hoped. I will look into it later on. For now I need to find other ways to make debug info more readable.

[Pavl_G]

You could use the system shell for a quick trial, try this or a sort of it:

Process run = Runtime.getRuntime().exec(new String[]{"echo", "-e", "\033[38;2;255;50;50m", data}); // data is your data
        
       
 if (run.waitFor() == 1) {
         System.out.println("Run Failed!");
 }

 /* release resources */
 run.destroy();
 run = null;

And, then you could build an API around the system shell to serve this purpose, but you might need to put in mind the system specific shells.

EDIT:
This forks your process (e.g., Unix Process) for a new shell process and destroys it releasing the resources. Destruction could be modeled to run at the end of the jMonkeyEngine application or state, the close() event, and the subprocess could be modeled to run with a JME state initialization, ideally reducing memory allocation/deallocation overheads.

[Fedor_van_Eldijk]

By accident I found out that the output window does take colors from a string:

To debug a problem I had with my FiFo-buffers and some illegal dumping of indexes, i captured a stacktrace in a string and dumped it in the output window later. It gave me these red letters instead of the default white letters I normally get.

Next step would be to find out what kind of codes are in this string, since the regular codes do not work.

[danielp]

I don’t believe there is any color coding going on here - by default, Java prints stack traces to stderr, not stdout. I’m pretty sure the coloring here is just the editor applying colors to output from stderr as a display effect, not parsing color control codes from the output stream.

[Pavl_G]

If someone catches the exception and prints it, it wll be neutral of no red color even though it still be printed on the stderr stream. The best way to colorize text, from my opinion, is the ANSI colors, the String formatting may help.

This was the answer from GPT:

        public static final String RESET = "\u001B[0m";
    public static final String RED = "\u001B[31m";
    public static final String GREEN = "\u001B[32m";
    public static final String YELLOW = "\u001B[33m";
    public static final String BLUE = "\u001B[34m";
    public static final String PURPLE = "\u001B[35m";
    public static final String CYAN = "\u001B[36m";
    public static void main(String[] args) {
       String text = String.format("%sThis is red text%s", RED, RESET);
        System.out.println(text);
        
        text = String.format("%sThis is green text%s", GREEN, RESET);
        System.out.println(text);
        
        text = String.format("%sThis is blue text%s", BLUE, RESET);
        System.out.println(text);

Better than forking a new process just to run a BASH echo…

EDIT:
You can still use the RGBA system, though, just instead of this ANSI.

[pspeed]

Just note that they were talking about the “output window” of the IDE.

…whether that window supports ANSI colors is in question but the recent topic was about the stack traces in that window.

I agree with danielp that it’s likely that the IDE is specifically parsing that content looking for “stuff that looks like a stack trace” and coloring it. There aren’t necessarily any specific ‘codes’ to make that color. It’s also what’s making the .java line numbers clickable as links… which is certainly not and special codes that an application can output.

[Pavl_G]

@pspeed

Just note that they were talking about the “output window” of the IDE

Most IDEs utilize an embedded terminal as an output window, however, yes it might be for Netbeans that would make a difference.

[Pavl_G]

@Fedor_van_Eldijk

This does not work:
System.out.println(DBGContext+ "\u001B[41m" + _text + "\u001B[0m"

Furthermore, Fedor has tried here before, I guess it didn’t work because of missing string formatting that would likely escape these characters and render them as color codes.

[Fedor_van_Eldijk]

@danielp: as I explained, what you see is not just a e.stacktraceprint… i dumped a stack trace to a string for later use and a number of cycles later that string was printed in the IDE output window. It is definetely a string containing formatting codes - it also has working links to code lines.

@pspeed: I think that would be a very complicated solution for something that the good people who wrote NetBeans could have done a lot easier using formatting codes in strings.

I’ll run the string though a hex editor to have a look.

[pspeed]

@Fedor_van_Eldijk

@pspeed: I think that would be a very complicated solution for something that the good people who wrote NetBeans could have done a lot easier using formatting codes in strings.

If you click this:

Does it take you to a line of source code?

…if so then they are doing a lot more than just interpreting some codes that they inserted themselves after parsing the Java stack trace. Plus, that’s quite a rube-goldberg style solution.

Regular Java stack traces definitely do not include those codes nor does it include source code links. So they definitely ARE parsing it and doing something special.

Makes me wonder what it would do if you just print random lines that look like stack traces.

[Fedor_van_Eldijk]

Well, the hex editor does agree with your assumption.

But I can confirm the links take you to the actual line.

And did the test you suggested by dumping a line that looks like a line of a stack trace and it did come out formatted:

The code was:

Utils.LOG("---TEST DUMPING LINE THAT LOOKS LIKE A STACK TRACE--- ");
Utils.LOG("at com.jme3.app.state.AppStateManager.update(AppStateManager.java:371)");