ASCII/UNICODE BUG K=75

[ghost]

Apache NetBeans version

verified in 14rc4, 13... 12.0

What happened

for (int i=0; i<=127; i++){
    System.out.println(i + " " + (char) i);
} 

I was running this code above and received the following output:
(I was missing the value 75 of uppercase K) (Netbeans IDE version 12.6)

How to reproduce

see above

Did this work correctly in an earlier version?

No

Operating System

Windows

JDK

17.0.1

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

No response

Are you willing to submit a pull request?

Yes

Code of Conduct

Yes

[sadhusreenivas]

Oh...nice find.

Its working in other editors properly (Sublime)

75 - K is not getting printed!
Nice bug....kudos!

[lkishalmi]

Could not reproduce on Linux. What happens if the i=64 ?

[00816]

It actually missing 75.

[lkishalmi]

I know, but from 0-31 there are control characters which could affect the output.
Also the complete line 75 is missing, not just the K. If a line is missing it might be a synchronization issue or some buffering issue between the OS process and NetBeans.

[lkishalmi]

Maybe related to #4119

[00816]

This issue is only Netbeans 12.6. All other versions, its working fine.

This has been produced on Windows.

Console and other text editors, it could able to print that line.

I amazed why 75 - K is missing, every time.

Is that a bug? how to understand.

[mbien]

the screenshots shows 12.6 but the issue had "latest daily build" selected. Someone please test NetBeans 13 and 14rc4 so that we know that this is in fact not already fixed, e.g via #3289 or #3836

[duoduobingbing]

the screenshots shows 12.6 but the issue had "latest daily build" selected. Someone please test NetBeans 13 and 14rc4 so that we know that this is in fact not already fixed, e.g via #3289 or #3836

I haved test this for Netbeans 13 + Java 17.0.3 under Windows 10
when having system variable MAVEN_OPTS=-Dfile.encoding=UTF-8 set:

The Code

public static class Main{
 public static void main(String args[]) throws Exception {
        
        System.out.println(75 + " " + (char)75);
        System.out.println((char)75);   
        System.out.println(Charset.defaultCharset());

    }
}

when executing a Maven project yields

K
UTF-8

in the Netbeans Console.

The line 75 K is always missing.

[lkishalmi]

Still works on Linux either with Ant or Maven project.

[duoduobingbing]

After some further testing it seems like any String of the pattern ^\d+ ?K$ is swallowed by the Netbeans console under Windows.

System.out.println("5000K");  //output missing
System.out.println("" + "204K");  //output missing
System.out.println("" + "255 K");  //output missing
System.out.println("" + "K");  //does show

[mbien]

i tested 14rc4 and 12.0 on win 10 and saw the same issue in both cases. This means this is not a recent regression, its an older issue which is not influenced by recent changes in encoding related code.

going to update the issue details a bit

[lbruun]

Using Windows 11, NB 13 and JDK 11, I can only reproduce on a Maven-based project, not on a Ant-based one.
My full and complete application is this:

public class MyMain {
   public static void main(String[] args) {
        System.out.println("Start");
        System.out.println("75 " + (char) 75);  // Swallowed with NB-->Maven execution
        System.out.println("End");
    }
}

However, when executing the mvn command line which NB constructs outside of the IDE in the cmd.exe, then I do indeed get the line printed correctly. Baffled. Regardless I'm thinking it may have to do with Maven ANSI coloring, Maven's use of jansi and how all that plays with NetBeans ?

[lbruun]

I've done some debugging. Nothing to do with ANSI coloring and what not. Sorry for bringing that up.

The text 75 K by coincidence matches what the NetBeans Maven CommandLineOutputHandler seems to think is download progress info from Maven. It is obviously not.

The output is skipped for this reason. So there you have it.

The class, CommandLineOutputHandler, does a lot of pattern matching on the output from Maven before it presents it in the Output window. Too much for my taste, but I understand why it may be necessary.

Not sure what the fix is.

[mbien]

@lbruun thank you for investigating. I was actually curious how many comments this issue will get before someone starts a debugger :)

[neilcsmith-net]

@lbruun nice find! And comment at line 319 shows this was picked up before in https://bz.apache.org/netbeans/show_bug.cgi?id=252514 .. and probably why this is a Windows bug given the guard on \r.

I was curious why 63 ? and 66 B were getting through, until I looked at the screenshot again! 😄

[mbien]

the download progress filter doesn't work anymore, right?
I typically see output like:

Progress (1): 2.7/746 kB
Progress (1): 5.5/746 kB
Progress (1): 8.2/746 kB
Progress (1): 11/746 kB 
Progress (1): 14/746 kB
Progress (1): 16/746 kB
Progress (1): 19/746 kB
Progress (1): 21/746 kB
Progress (1): 24/746 kB
Progress (1): 27/746 kB
Progress (2): 27/746 kB | 0/2.5 M
...

which would be one constantly updating line in a shell.

I am wondering if we can just drop the filter. Maven has -ntp (--no-transfer-progress) which might not have existed back when this was written.