> 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
# 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
It would be good to reach out the jruby folks to see if they have advice or
experience to offer.