Title: Under ubuntu 18.04, Jython 2.7.1 crashes with ByteBuffer error
Type: crash Severity: normal
Components: Versions:
Status: closed Resolution: invalid
Dependencies: Superseder:
Assigned To: Nosy List: fwierzbicki, jeff.allen, psykiatris
Priority: Keywords:

Created on 2018-05-11.02:38:41 by psykiatris, last changed 2018-11-04.14:54:40 by jeff.allen.

msg11968 (view) Author: Patrick Palczewski (psykiatris) Date: 2018-05-11.02:38:40
Under ubuntu 17.10, the system installed Jython (2.7.1) ran find under Java 1.8. Today, I upgraded to Ubuntu 18.04, and Jython 2.7.1 crashes with the following:

Exception in thread "main" java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
	at jline.internal.InputStreamReader.<init>(
	at jline.console.ConsoleReader.setInput(
	at jline.console.ConsoleReader.<init>(
	at org.python.util.JLineConsole.install(
	at org.python.core.Py.installConsole(
	at org.python.core.PySystemState.initConsole(
	at org.python.core.PySystemState.doInitialize(
	at org.python.core.PySystemState.initialize(
	at org.python.core.PySystemState.initialize(
	at org.python.core.PySystemState.initialize(
	at org.python.util.jython.main(

I've verified my system default JVM is openJDK 1.8.0_162.

My development Jythons (2.7.0 and 2.7.2a1+) work fine.
msg11970 (view) Author: Jeff Allen (jeff.allen) Date: 2018-05-11.21:48:13
There definitely is such a method. It's hard to see how this could happen unless the JVM is not what you think.

The only odd thing I can see is tha the required return type appears to be ByteBuffer, not Buffer. This leads me to suspect the problem is the same as .

It's not something Jython can fix. It's either a JLine problem or a Java fault. But it is a problem for us if JLine was (maybe) compiled against a library where the signature is different from (some) run-time environments.
msg11971 (view) Author: Patrick Palczewski (psykiatris) Date: 2018-05-12.03:52:05
It is weird, as it works fine under Ubuntu 17.10.

I will send a bug report to Ubuntu/Canonical to let them know. Interestingly enough, when I was using ubuntu 16.04, the installed Jython was version 2.5.3, with no upgrades. so I have been using a local set up version 2.7.0, so, it's no loss. i attempted a re-install and the file name from Ubuntu is jython_2.7.1+repack-3_all.deb

One thing I will note: There is an article in the May 2018 issue of Linus User & Developer, discussing Ubutntu 18.04, and it stated that because Python2 is ceasing in 2020, they have removed Python2, and set up Python3 as the default. That's for a fresh install.

I upgraded, so right now, my system has 2.7.15 and 3.6.5 respectively.
msg11972 (view) Author: Jeff Allen (jeff.allen) Date: 2018-05-12.08:31:16
In a disassembly:

    javap -cp "C:\Jython\2.7.1\javalib\*" -c jline.internal.InputStreamReader

I see:

Compiled from ""
public class jline.internal.InputStreamReader extends {
  java.nio.charset.CharsetDecoder decoder;

  java.nio.ByteBuffer bytes;

At the place where your problem starts, the invocation is:

      81: getfield      #5                  // Field bytes:Ljava/nio/ByteBuffer;
      84: iconst_0
      85: invokevirtual #13                 // Method java/nio/ByteBuffer.limit:(I)Ljava/nio/Buffer;
      88: pop
      89: return

A change has been made to the API of ByteBuffer at JDK 9 adding a method ByteBuffer limit(int n), which is what Java is failing to find in your case (as in the MongoDB bug cited). If the JLine source were to be compiled in the presence of a JDK 9, I believe it would generate a reference to this more specific method. Is it possible you have on the class path a version of the JLine classes that was compiled with Java 9?

I can't reproduce this problem with the JAR we distribute with 2.7.1 on Windows or Linux. Maybe try something like the above on your machine.
msg11974 (view) Author: Patrick Palczewski (psykiatris) Date: 2018-05-12.13:40:06
I did think of that. I did see I needed to upgrade the jline library, so I updated. So, per my system, I have these libraries and their versions:

ii  libjline-java  1.0-2        
ii  libjline2-java 2.14.6-1    

My classpath mimics the jython classpath (from jython --print). 

From what you're saying, could it be that someone upstream may have compiled it against 9 and distributed?
msg11975 (view) Author: Patrick Palczewski (psykiatris) Date: 2018-05-12.14:12:17
due to the odd name of the package *jython2.7.1+replack), I downloaded the source to see what was up. Here is the output:

Reading package lists... Done
NOTICE: 'jython' packaging is maintained in the 'Git' version control system at:
Is this an official jython distribution?

As it proceeds, it applies.. patches:
dpkg-source: info: applying 00-missing-dep.patch
dpkg-source: info: applying 01-classpath.patch
dpkg-source: info: applying 03-default-cachedir.patch
dpkg-source: info: applying 05-no-com.carrotsearch.sizeof.patch
W: Download is performed unsandboxed as root as file 'jython_2.7.1+repack-3.dsc'

Could this be the cause?
msg11976 (view) Author: Jeff Allen (jeff.allen) Date: 2018-05-12.18:16:43
That's a Debian's repackaging for their OS, which is fine. They're free to do that, and if it breaks it, they'll do the responsible thing, I'm sure.

You can test whether JLine had been compiled against Java 9 with javap as above. If it is broken because someone switched the JARs that's not our issue.
msg11977 (view) Author: Patrick Palczewski (psykiatris) Date: 2018-05-14.13:17:20
Debian runs jython using java and their packaged jython.jar. Nothing to be done but wait.
msg11979 (view) Author: Jeff Allen (jeff.allen) Date: 2018-05-14.19:44:28
Thanks for finding this. Although it's not ours to fix, it's clearly a concern for the project that Jython should appear broken on Ubuntu. Assuming your report results in an open bug on a tracker somewhere, a link here would be useful.

Mint (that's Linux for wimps) still only offers me Jython 2.5.3 and jline 2.11, so I can't reproduce it. From what you've obeserved I think the problem will be that JLine2 has been compiled with Java 9.

It's nice Ubuntu are keeping up with versions, but I begin to see a problem with this repackaging things. One takes on rather a lot of responsibility for integration.
msg11984 (view) Author: Patrick Palczewski (psykiatris) Date: 2018-05-16.02:33:49
Submitted a bug report to ubuntu:
Date User Action Args
2018-11-04 14:54:40jeff.allensetstatus: pending -> closed
2018-05-16 02:33:49psykiatrissetmessages: + msg11984
2018-05-14 19:44:29jeff.allensetnosy: + fwierzbicki
messages: + msg11979
2018-05-14 13:17:20psykiatrissetmessages: + msg11977
2018-05-12 18:16:43jeff.allensetstatus: open -> pending
resolution: invalid
messages: + msg11976
2018-05-12 14:12:18psykiatrissetmessages: + msg11975
2018-05-12 13:40:07psykiatrissetmessages: + msg11974
2018-05-12 08:31:19jeff.allensetmessages: + msg11972
2018-05-12 03:52:06psykiatrissetmessages: + msg11971
2018-05-11 21:48:13jeff.allensetnosy: + jeff.allen
messages: + msg11970
2018-05-11 02:38:41psykiatriscreate