Issue2683

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>(InputStreamReader.java:104)
	at jline.console.ConsoleReader.setInput(ConsoleReader.java:330)
	at jline.console.ConsoleReader.<init>(ConsoleReader.java:248)
	at org.python.util.JLineConsole.install(JLineConsole.java:107)
	at org.python.core.Py.installConsole(Py.java:1744)
	at org.python.core.PySystemState.initConsole(PySystemState.java:1258)
	at org.python.core.PySystemState.doInitialize(PySystemState.java:1109)
	at org.python.core.PySystemState.initialize(PySystemState.java:1023)
	at org.python.core.PySystemState.initialize(PySystemState.java:979)
	at org.python.core.PySystemState.initialize(PySystemState.java:974)
	at org.python.util.jython.run(jython.java:263)
	at org.python.util.jython.main(jython.java:
==============

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.

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 https://jira.mongodb.org/browse/JAVA-2559 .

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.

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.

In a disassembly:

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

I see:

Compiled from "InputStreamReader.java"
public class jline.internal.InputStreamReader extends java.io.Reader {
  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.

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?

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:
https://anonscm.debian.org/git/pkg-java/jython.git
=================
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?

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.

Debian runs jython using java and their packaged jython.jar. Nothing to be done but wait.

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.

Submitted a bug report to ubuntu:

https://bugs.launchpad.net/ubuntu/+source/jython/+bug/1771476