> A few of these issues marked (the 2 high priority ones too) don't seem
> JConsole related, though:
> http://bugs.jython.org/issue1133 (really more about fixing stuff upstream)
> http://bugs.jython.org/issue1460 (isn't this a parser problem?)
> http://bugs.jython.org/issue1807 (nothing to do w/ JLine)
> http://bugs.jython.org/issue1972 (I just commented on this: I doubt the *original* issue actually involves JLine AFAICT)

Thanks Philip. I've taken the "console" keyword off those issues.

Which leaves us with the following set (currently 8 issues)


From what I can see the major issues are

1. Ctrl-c handling is broken

A: On windows and cygwin, it is treated as an ordinary textual character, appearing as a heart symbol. The intended function of ctrl-c is completely unavailable on these platforms. This is obviously jline related, and should be possible to fix, since cpython and the old jython interactive console both behave as expected on windows. This is sufficiently broken that it cannot be left as is. (Is there something about the jline architecture that prevents correct implementation of Ctrl-C handling? I spent 2 hours or so playing with the jline properties and our java code for it, trying what looked like good solutions, some I found in various JIRAs and blog posts: none of them worked)

B: On some unixes, although apparently not OSX, which is the platform of the developer who introduced jline, Ctrl-C does not behave as expected. Instead of generating a KeyboardInterrupt exception which can be caught, it instead forces a process quit: the exception cannot be caught, which makes for a very poor experience for developers distributing jython software on these platforms, since their software cannot exit cleanly. It needs to be fixed. The only proposed fixes seem to involve the use of signal-handling facilities, which are specific to the Sun/Oracle JVM. Such JVM specific workarounds are not really workable in a multi-JVM context. The old InteractiveConsole seemed to handle it OK. What is about jline that prevents the implementation of Ctrl-C handling without resorting to signals?

2. Interference with System.console().readline()

This issue is also experienced by Scala, and possibly jruby, and neither seems to have found a solution.


This is a major issue for those needing System.console() to work properly.

> Is it cygwin only or is it all windows?

As discussed above, there are separate issues on Windows, Cygwin and various unixen, including linux. (but apparently not Mac OSX, which is perhaps why all you guys are not seeing it ;-)

> Only disabling on the specific
> platforms actually does sound like a good idea, especially in 2.5.x
> since it would be a loss of backwards compatibility. If it really is
> only cygwin then we could expect reasonably sophisticated users who
> should be able to handle a registry switch.

If we decide to go ahead with platform-specific terminals, there are two ways to do it

1. We specialise the installer to customise the registry file at installation time. I'm not keen on this option, since there is no templating or other similar functionality in the installer. Here's how I had to add to the Windows batch file.


2. We introduce an amended naming convention in the registry file, to permit platform specific installation options. For example

# Jython ships with a JLine console (http://jline.sourceforge.net/)
# out of the box. Setting this to the name of a different console class,
# new console features can be enabled. Readline support is such an
# example:
# To activate the legacy Jython console:
# Now we specialise for different platforms, and change console initialisation at runtime.

> I wonder if JLine 2 has fixed these issues - eventually we'll need to
> look into that I think. If we could get JLine bug free it is much
> nicer than the old console...

Agreed that is nicer for those lucky enough to run platforms on which it works.

It would be good to reach out the jruby folks to see if they have advice or experience to offer.