This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Please add support for System.console() to Output Window when running program on JDK 6
sorry forgot to set to enhancement
Difficult. Probably impossible without changing how processes are run from Ant.
*** This issue has been marked as a duplicate of 56341 ***
*** Issue 111337 has been marked as a duplicate of this issue. ***
x
Not the same as issue #56341, which deals with System.out.print (with no trailing newline). In my tests (JDK 6u2 on Ubuntu), System.console() simply returns null when the program is run from the IDE. (From a terminal, it works except that passwords are incorrectly echoed, making it no more useful than System.in/out.) I think there is not much NB can do about this without using native code to launch the foreign process - would need to set a controlling terminal, which is not supported by java.lang.Process and is rather OS-dependent.
*** Issue 135273 has been marked as a duplicate of this issue. ***
*** Issue 144562 has been marked as a duplicate of this issue. ***
See issue #136929 about possible future changes in how processes are spawned.
*** Bug 178764 has been marked as a duplicate of this bug. ***
The Execution API does not support pty's. However it appears that dlight.nativeexecution, recently added to the ide cluster, does, so in conjunction with a terminal emulator (also now in ide cluster) this could form the basis of a raw-mode execution facility for Java SE apps. Deserves study and prototyping. Probably the best approach would be to drop the current buffering hacks for <java> run from inside the IDE, instead offering a project-level switch: 1. If off (the default), run Ant's unmodified <java> - "cooked" (line-oriented) I/O supported, using the regular build output tab, using the regular output window, with full hyperlinking e.g. of stack traces. Best for apps with no stdio beyond log messages (such as GUI apps); or some apps focused on printing lines of text to stdout/stderr, especially if the output includes non-Latin scripts (*), or if collecting and saving complete output to a log file is needed. 2. If on, reimplement <java> as a direct call to the native Java launcher, bound to a pty, using the terminal emulator in a separate output tab, with no or limited hyperlinking. Best for apps using terminal-oriented features such as unbuffered stdio, nonechoed password entry, curses-based graphics, etc. Unclear whether CoS-mode execution should use cooked or raw output. Ideally the same as what the project has configured, though this means supporting both in JavaRunnerImplementation, with an accompanying API. (*) Some scripts, especially Asian, cannot be correctly rendered when displayed as isolated glyphs in a grid, due to ligatures: compare क्षत्रिय (kṣatriya) to क् ष त् रि य (spaces inserted, k ṣa t ri ya).
More general issue than just java.io.Console, though that is a motivating use case.
Would it be possible to create a class called sun.misc.SharedSecrets or even java.lang.System that is loaded on the classpath before rt.jar so it gets used instead of the JVM one? The class could then do a hand off when System.console() is requested to the Output window instead. An idea anyway. The question is how to get the classpath order to work I suppose if it is even allowed with those particular classes. A project specific run configuration setting would toggle the behavior of whether to load it or not. May have to be Java version specific though I'd guess. At least for future proofing for Java 7,8,...
*** Bug 195380 has been marked as a duplicate of this bug. ***
This bug is related to https://netbeans.org/bugzilla/show_bug.cgi?id=178764 which is marked as resolved by this issue.
*** Bug 235334 has been marked as a duplicate of this bug. ***