You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "Sean Busbey (Jira)" <ji...@apache.org> on 2020/04/26 15:15:00 UTC

[jira] [Commented] (ZOOKEEPER-3215) Handle Java 9/11 additions of covariant return types to java.nio.ByteBuffer methods

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092754#comment-17092754 ] 

Sean Busbey commented on ZOOKEEPER-3215:
----------------------------------------

I hit this issue when trying to use Zookeeper 3.5.7 installed via Homebrew.

The logs (after adjusting the log level in {{/usr/local/etc/zookeeper/log4j.properties}} from WARN to INFO) contain the tell-tale complaint:

{code}
2020-04-25 02:42:15 NIOServerCnxn [WARN] Unable to read additional data from client sessionid 0x0, likely client has closed socket
2020-04-25 02:42:16 ClientCnxn [INFO] Opening socket connection to server localhost/127.0.0.1:2181. Will not attempt to authenticate using SASL (unknown error)
2020-04-25 02:42:16 ClientCnxn [WARN] Session 0x0 for server localhost/127.0.0.1:2181, unexpected error, closing socket connection and attempting reconnect
java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
        at org.apache.zookeeper.ClientCnxnSocketNIO.connect(ClientCnxnSocketNIO.java:296)
        at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1104)
        at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1139)
2020-04-25 02:42:16 NIOServerCnxn [WARN] Unable to read additional data from client sessionid 0x0, likely client has closed socket
2020-04-25 02:42:16 ZooKeeper [INFO] Session: 0x0 closed
2020-04-25 02:42:16 ClientCnxn [INFO] EventThread shut down for session: 0x0
{code}

My JAVA_HOME is set to jdk8 build 161, as is the bare "javac" command

{code}
echo $busbey-mba13:~ busbey$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/
busbey-mba13:~ busbey$ which javac
/usr/bin/javac
busbey-mba13:~ busbey$ /usr/bin/javac -version
javac 1.8.0_161
{code}

I do have other Javas installed
{code}
busbey-mba13:~ busbey$ ls /Library/Java/JavaVirtualMachines/
jdk-9.jdk		jdk1.8.0_161.jdk	jdk1.8.0_74.jdk		jdk8u172-b11		zulu-7.jdk
jdk1.7.0_80.jdk		jdk1.8.0_192.jdk	jdk1.9-ea-b102.jdk	openjdk-11.0.2.jdk
{code}

I'm checking to see now if homebrew installed from source and if so how it picked which JDK to compile with.

> Handle Java 9/11 additions of covariant return types to java.nio.ByteBuffer methods
> -----------------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-3215
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3215
>             Project: ZooKeeper
>          Issue Type: Bug
>    Affects Versions: 3.4.13
>            Reporter: V
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 2h
>  Remaining Estimate: 0h
>
> Java 9 introduces covariant return types which allows one to have different return types if return type in the overridden method is a sub type. Since Java 9, few functions return ByteBuffer, whereas the parent method return Buffer, resulting in causing issues for Java 8 and below since for them the method does not exist.
> Steps To Reproduce:
> 1. Setup ZooKeeper Server with JDK11.
> 2. Setup ZooKeeper Client with JDK8.
> 3. Try connecting the client and server.
> Results:
> Cast ByteBuffer instances to Buffer before calling the method.
>  
> Notes:
> There was a similar bug in the MongoDB community - [https://jira.mongodb.org/browse/JAVA-2559]
>  
> This is not a contribution.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)