Community
Participate
Working Groups
Java 6.0 (mustang) provides a new class to represent the system console (http://download.java.net/jdk6/docs/api/java/io/Console.html) The documentation (http://download.java.net/jdk6/docs/api/java/lang/System.html#console()) says: "Returns the unique Console object associated with the current Java virtual machine, if any". When I run the following code: import java.io.Console; public class Main { public static void main(String[] args) { Console console = System.console(); System.out.println(console); } } directly using "java Main", it works (console != null). However, when I run inside Eclipse (Alt+Shift+X J), it returns null. I'm not sure if this is something must be handled at Eclipse level, or at JRE level (or both...), or it should be handled now during the development phase of Java 6.0 (besides bug#106206).
One more thing: I'm running Eclipse 3.2 M4, with jdk1.6.0 build 65.
In one case the Java command is started out of a shell (-> there is a console), in the other (the Java application launcher) it is started directly using a process (no console). The spec says: "Returns the unique Console object associated with the current Java virtual machine, if any". 'If any' means that you can also get null. This look all ok to me.
OK, I agree that it is possible to get a null from System.console() when ***there is no console***. But, what about the console view? Shouldn't it be considered a console? ;-) I ask you: how will I run a project that uses java.io.Console in Eclipse? The intuitive way is to expect that once I run it via java application launcher, the System.console() will return a console associated with the console view, as is when you use System.out (writes to console view) or System.in (reads input from console view). Don't you agree with me?
It seems strange that a process can print out to System.out.println() and have it display in the Console view (as well as read input via System.in) and for the Console to be null. I'm sure this will come back to bite as various Java processes start to use java.io.Console for the future.
*** Bug 179197 has been marked as a duplicate of this bug. ***
maybe this could be reopened as an enhancement request for 3.3 (or beyond)? I agree with Alex, this will be noticed by many people as soon as System.console() adoption increases.
Given the recent discussion, I'm reopening as a enhancement request. I think the problem here is how to plug the Eclipse console into the JRE 6 notion of console. Suggestions?
Moving to debug... the console is associated with running/debugging.
The istty() method has the following check: if (GetFileType(hStdIn) != FILE_TYPE_CHAR || GetFileType(hStdOut) != FILE_TYPE_CHAR) return JNI_FALSE; In order for the method to return true the type of the redirected streams should be changed (I don't think there's an api for that). In addition Eclipse should support turning the console echo on and off using just the redirected io streams. Another relevant discussion is at http://blogs.msdn.com/junfeng/archive/2005/07/07/436746.aspx
Marking as assigned for future consideration/investigation. It's too late for 3.3.
How about for 3.4?
Sorry, nothing planned for 3.4. Not sure if an API changes would be required - but the M6/API freeze is coming soon. If anybody wants to contribute a patch, please do so.
How about a new "Run As" option which would have "Console Application". It could then spawn a command prompt which would then run correctly, avoiding extra internal logic. However are there any security concerns that doing it this way might drum up? In the "Common" tab there is a "Standard Input and Output" which has "Allocate Console" checkbox. Is this in any way related to this? Or the "Launch in background" checkbox?
(In reply to comment #13) > In the "Common" tab there is a "Standard Input and Output" which has "Allocate > Console" checkbox. Is this in any way related to this? Or the "Launch in > background" checkbox? No. This is just whether a console view should be allocated in the SDK for the I/O. You can have output shown in the console, sent to a file, or both.
Developers can work round this limitation using remote debugging as described here: http://stackoverflow.com/questions/104254/javaioconsole-support-in-eclipse-ide#105403 With this workaround, it is possible to reduce application launch to a two-step process. Whether it is worth automating depends on java.io.Console uptake, I guess. It would be possible to add a new launch configuration for Java applications that reused the existing launch extensions implementation code. It might be best to provide an edit box to build the launch command to avoid having to cater for every potential console out there (though supporting ${workspace_loc:/}-style variables and providing for common defaults would help). On Windows, it is possible to spawn a console window from Eclipse using a command like: cmd.exe /C start cmd.exe /C java.exe -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y -cp .\bin Main On *nix variants, it would be possible to spawn a console process using xterm. These are easy to test using the External Tools dialog.
We are using Console.readPassword(): my expectation was that Eclipse would handle this by use the console view. More people are using Console, and are all expecting Eclipse to connect the console view to facilitate it. It is time to make this work.
From what I understand, there is no a way for Eclipse to connect the console view to Java's System.console(): http://www.eclipsezone.com/eclipse/forums/t93685.rhtml The simplest solution might be to provide on option to launch a Java app from a command shell (configured via the common tab console options). However, I doubt there is a platform independent way to do that either.
(In reply to comment #17) > The simplest solution might be to provide on option to launch a Java app from a > command shell (configured via the common tab console options). I hear this complaint/request all the on IRC. > However, I doubt there is a platform independent way to do that either. ...but yeah, I dunno either.
I just got confused by this issue. I suggest that if the Console window in Eclipse cannot be made to behave as a Console, that it should be renamed the Output window.
(In reply to comment #19) > I just got confused by this issue. > I suggest that if the Console window in Eclipse cannot be made to behave as a > Console, that it should be renamed the Output window. I'm pretty sure that would confuse more people since the console view has been named this since Eclipse was born, which was before Java 6 arrived on the scene.
(In reply to comment #20) > I'm pretty sure that would confuse more people since the console view has been > named this since Eclipse was born, which was before Java 6 arrived on the > scene. Agreed. That wouldn't really help. Besides, the view also allows input and I think 'IO View', 'I/O View', and/or 'Input/Output View' all sound pretty dumb.
(In reply to comment #13) > In the "Common" tab there is a "Standard Input and Output" which has "Allocate > Console" checkbox. Is this in any way related to this? Or the "Launch in > background" checkbox? In 3.4, if not earlier versions, this checkbox label says "Allocate Console (necessary for input)"! If that's not referring to System.console() input, what input is it referring to? That label certainly supported my expectations for having a working input console.
> what input is it referring to? The input stream of the associated java.lang.Process.
I have to use Console because I need the readPassword() function. That means I can't use eclipse to test or debug my application. It seem very inconsistent that System.out and System.in work and Console doesn't. I assume this is a figment of the implementation since no one would simply decide not to support Console. It certainly violates the principle of "minimal surprise". Please add me to the list of people who would like to see this bug fixed ASAP. (Since eclipse 4.2 is supposed to support Java 1.6, I would call this a bug fix, not an enhancement). Thanks.
*** Bug 295177 has been marked as a duplicate of this bug. ***
Can we please put this at a Severity of Blocker? It is an impediment to testing code to do with passwords and security.
No one has offered a tried/tested solution to this problem. There does not appear to be an API to set the system console for a VM. Perhaps a workaround would be to launch a DOS shell and launch java from there. I have found that "cmd.exe /c start" will open a command shell, but I'm not sure how to then exec a command. Perhaps a DOS guru could do some more digging here.
FYI: "Console" - http://en.wikipedia.org/wiki/Computer_terminal Java Input/Output: - http://java.sun.com/docs/books/tutorial/essential/io/ - http://java.sun.com/docs/books/tutorial/essential/io/cl.html
(In reply to comment #28) > FYI: > > "Console" > - http://en.wikipedia.org/wiki/Computer_terminal > > Java Input/Output: > - http://java.sun.com/docs/books/tutorial/essential/io/ > - http://java.sun.com/docs/books/tutorial/essential/io/cl.html Missed one: - http://en.wikipedia.org/wiki/Computer_console
Would developing some kind of terminal emulator layer via some "serial" interface be a means to resolve this? Then have the "Console" utilizing this?
(In reply to comment #30) > Would developing some kind of terminal emulator layer via some "serial" > interface be a means to resolve this? Then have the "Console" utilizing this? The problem is that we don't know how to *set* the console when launching a VM. We have a console that supports reading output/error stream and writing to sysin. It's not clear if there's a way to connect it to the VM's system console.
(In reply to comment #31) > (In reply to comment #30) > > Would developing some kind of terminal emulator layer via some "serial" > > interface be a means to resolve this? Then have the "Console" utilizing this? > > The problem is that we don't know how to *set* the console when launching a VM. > We have a console that supports reading output/error stream and writing to > sysin. It's not clear if there's a way to connect it to the VM's system > console. Java 6 API: "Whether a virtual machine has a console is dependent upon the underlying platform and also upon the manner in which the virtual machine is invoked. If the virtual machine is started from an interactive command line without redirecting the standard input and output streams then its console will exist and will typically be connected to the keyboard and display from which the virtual machine was launched. If the virtual machine is started automatically, for example by a background job scheduler, then it will typically not have a console." One solution would be for to Eclipse to start a server on some port. When a console is invoked it would execute a new instance of the JVM, pipe the stdout of the JVM instance to another Java client program which would then communicate with the Eclipse server program. I don't know enough about the Eclipse infrastructure but that doesn't sound like a fun task.
As I falled in this page while looking for the problem, a quick solution for reading from keyboard is: BufferedReader d = new BufferedReader(new InputStreamReader(System.in)); as suggested in DataInputStream.readLine() deprecated method.
Not sure if these are related but I was looking through some java bugs and saw the following: - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4109888 - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4062587 The 4062587 includes a "workaround" for what may be a similar problem. See the end of the bug. On a side note, Netbeans seems to be able to open a console, run the program, leave a "Press Enter" type prompt to prevent closure of the console.
I want to read the console input and then i want to display that in my web page can any buddy help me for that(i used servlet to devlop my web page in java) Thanks in advance
*** Bug 342377 has been marked as a duplicate of this bug. ***
I just bumped into this too. It's definitely a bit of a surprise. The issue is that the view is called "Console" and that the launch configuration specifically asks "Allocate console (necessary for input)". Reading through Sun's source code for Console, it seems like you should be able to fix this by creating your own instance of JavaIOAccess (or somehow finding a way to override FileDescriptor.in). I assume there is a similar way to fix it for IBM's VM. A solution here doesn't have to be perfect across all VMs, but a best-effort would be better than the current state. Don't let perfection by the enemy of the good! :)
(In reply to comment #37) > I just bumped into this too. It's definitely a bit of a surprise. The issue > is that the view is called "Console" and that the launch configuration > specifically asks "Allocate console (necessary for input)". Totally agree with this.
I too need to test a tool that depends on the Console.readPassword
Hmm... 7 years without any progress on this? This seems like a pretty fundamental problem. Do any other IDE's have solutions for this?
I agree this needs fixing.
Any move yet?
Is this fixed yet? Can definitely use this right now.
9 years passed since this bug found, and no solution yet.
(In reply to G. Zsombor from comment #44) > 9 years passed since this bug found, and no solution yet. Opinions seem to converge at saying that there simply isn't a solution, due to the design of the Java runtime libraries. That said, I made a naive experiment, starting from the javadoc of java.lang.Process, where it says: "By default, the created subprocess does not have its own terminal or console." This would be end of story, except for the nice "by default". A little later: "Where desired, subprocess I/O can also be redirected using methods of the ProcessBuilder class". Here's my experiment: inside org.eclipse.debug.core.DebugPlugin.exec(String[], File, String[]) I replaced this p= Runtime.getRuntime().exec(cmdLine, envp, workingDirectory); with this: ProcessBuilder processBuilder = new ProcessBuilder(cmdLine); if (envp != null) { // populate processBuilder.environment() } processBuilder = processBuilder.directory(workingDirectory); processBuilder.redirectInput(Redirect.INHERIT); processBuilder.redirectOutput(Redirect.INHERIT); processBuilder.redirectError(Redirect.INHERIT); p = processBuilder.start(); Guess what: after installing the modified plugin, my test application could happily acquire a System.console() and print to - guess where - the console from where Eclipse has been started. Obviously, this requires that Eclipse is indeed started from some console (a linux shell in my case). My guess is, you can only have one: 1) use System.console(), or 2) use the Console view in Eclipse. Take your choice! I wonder, whether people would be helped already, if there was an option in the debug UI, s.t. like: [x] Inherit console from where Eclipse has been launched The effect would be simpler than launching outside in debug mode and having to connect a remote debug session. But still users would have to hunt for the underlying console, and what if Eclipse was launched from some shortcut icon on the desktop or elsewhere? At least it would be platform independent. Would people consider this approach worth pursuing?
(In reply to Stephan Herrmann from comment #45) > Would people consider this approach worth pursuing? Yes, that would be much better than null. Under Windows, would the terminal around eclipse have to be the default cmd.exe, or would better terminals like cygwin mintty work too?
*** Bug 559834 has been marked as a duplicate of this bug. ***
2021 and I'd sure still like to see a satisfactory solution to this bug. Currently between jobs and trying to self-teach a bit about the Java Security architecture, and this is an unfortunate roadblock that is going to unnecessarily divert me and send me down a rabbit hole researching work-arounds for an only-tangentially-related problem that has apparently existed since 2005 without adequate resolution. 16 years is an absolute epoch in software-time, and it's not as though Security is some little-used, mostly-unnecessary subsystem. Please fix this.
(In reply to Iain Davis from comment #48) > 2021 and I'd sure still like to see a satisfactory solution to this bug. > > Currently between jobs and trying to self-teach a bit about the Java > Security architecture, and this is an unfortunate roadblock that is going to > unnecessarily divert me and send me down a rabbit hole researching > work-arounds for an only-tangentially-related problem that has apparently > existed since 2005 without adequate resolution. 16 years is an absolute > epoch in software-time, and it's not as though Security is some little-used, > mostly-unnecessary subsystem. > > Please fix this. I hope you understand that there are limitations from JVM. Please go through https://bugs.eclipse.org/bugs/show_bug.cgi?id=122429#c45 Which option will work for you?
