Details

    • Type: Umbrella
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Java 9 will ship in 2016. This will be the first Java release that makes a significant compatibility departure from earlier runtimes.

        Issue Links

          Activity

          Hide
          apurtell Andrew Purtell added a comment - - edited

          A number of "internal" com.sun classes will be removed, including Unsafe. These removals need to be handled or HBase will not be able to run on a Java 9 runtime. Doing this in a backwards compatible way may be tricky. I'm not sure how the Java platform community will navigate to where they want to go while dealing with unfixable user code breakage and I hope we have an opportunity to provide pushback on changes if required.

          I don't think we need to do anything today beyond track what others in the ecosystem are doing, for example HADOOP-11123

          Show
          apurtell Andrew Purtell added a comment - - edited A number of "internal" com.sun classes will be removed, including Unsafe. These removals need to be handled or HBase will not be able to run on a Java 9 runtime. Doing this in a backwards compatible way may be tricky. I'm not sure how the Java platform community will navigate to where they want to go while dealing with unfixable user code breakage and I hope we have an opportunity to provide pushback on changes if required. I don't think we need to do anything today beyond track what others in the ecosystem are doing, for example HADOOP-11123
          Hide
          esteban Esteban Gutierrez added a comment -

          Right, I ran the same tests a moment ago and we also have some dependencies, including Cliff Click's high perf lib that rely on sun.misc.Unsafe also JRuby falls into that category.

          Show
          esteban Esteban Gutierrez added a comment - Right, I ran the same tests a moment ago and we also have some dependencies, including Cliff Click's high perf lib that rely on sun.misc.Unsafe also JRuby falls into that category.
          Hide
          apurtell Andrew Purtell added a comment -

          For an earlier discussion with folks at Oracle I ran jdeps analysis over the core Hadoop ecosystem and related projects that have notable or emerging user bases (in my opinion, some may debate...): Hadoop, ZooKeeper, Hive(+Tez), Pig, HBase, Oozie, Flume, Sqoop, Avro, Thrift, Accumulo, Cassandra, Crunch, Cascading, Elasticsearch, Giraph, Kafka, Mahout, Parquet, Optiq, Solr/Lucene, Spark, Storm. I picked recent releases except for HBase and Optiq, which I built from source. For Optiq because I could not find a binary distribution at the time. For HBase I used 0.99-SNAPSHOT because it has the new dependencies on Netty 4 and the LMAX Disruptor that will be in the upcoming 1.0 release. There are some common dependencies (Netty, Guava, Derby, the Scala runtime, Coda Hale's Metrics, LMAX Disruptor) that use internal sun.* APIs. We would need versions of these dependencies which do not make those calls available before we could eliminate internal API calls through this route. Other uses fall into a few common patterns. Daemons use Signal/SignalHandler for catching signals. Datastores such as HBase, Hive, and Cassandra are seeking their own high performance optimizations with Unsafe, including direct memory allocation. Avro and Kyro are serialization libraries seeking high performance via Unsafe on hot code paths. Hadoop and HBase utilize some security APIs for Kerberos and SSL which seem to have no non-internal API analogues. Pig and HBase pull in Jython and JRuby, respectively. Jython uses a bit of Unsafe. JRuby is an aggressive user of JVM internals.

          Show
          apurtell Andrew Purtell added a comment - For an earlier discussion with folks at Oracle I ran jdeps analysis over the core Hadoop ecosystem and related projects that have notable or emerging user bases (in my opinion, some may debate...): Hadoop, ZooKeeper, Hive(+Tez), Pig, HBase, Oozie, Flume, Sqoop, Avro, Thrift, Accumulo, Cassandra, Crunch, Cascading, Elasticsearch, Giraph, Kafka, Mahout, Parquet, Optiq, Solr/Lucene, Spark, Storm. I picked recent releases except for HBase and Optiq, which I built from source. For Optiq because I could not find a binary distribution at the time. For HBase I used 0.99-SNAPSHOT because it has the new dependencies on Netty 4 and the LMAX Disruptor that will be in the upcoming 1.0 release. There are some common dependencies (Netty, Guava, Derby, the Scala runtime, Coda Hale's Metrics, LMAX Disruptor) that use internal sun.* APIs. We would need versions of these dependencies which do not make those calls available before we could eliminate internal API calls through this route. Other uses fall into a few common patterns. Daemons use Signal/SignalHandler for catching signals. Datastores such as HBase, Hive, and Cassandra are seeking their own high performance optimizations with Unsafe, including direct memory allocation. Avro and Kyro are serialization libraries seeking high performance via Unsafe on hot code paths. Hadoop and HBase utilize some security APIs for Kerberos and SSL which seem to have no non-internal API analogues. Pig and HBase pull in Jython and JRuby, respectively. Jython uses a bit of Unsafe. JRuby is an aggressive user of JVM internals.
          Hide
          ram_krish ramkrishna.s.vasudevan added a comment -

          Considering the fact that we are accessing the private members of sun.nio, java.lang.reflect etc. All those will fail. Any code using setAccessible(true) will fail to work. Java 9 suggests some alternate for this (not sure whether we will have a better work around when the actual release happens).
          Alternate includes adding these extns to JVM
          (for eg)

          --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
          --add-opens=java.base/java.lang.reflect=ALL-UNNAMED
          

          Just adding it here as I could see this JIRA as the umbrella JIRA.

          Show
          ram_krish ramkrishna.s.vasudevan added a comment - Considering the fact that we are accessing the private members of sun.nio, java.lang.reflect etc. All those will fail. Any code using setAccessible(true) will fail to work. Java 9 suggests some alternate for this (not sure whether we will have a better work around when the actual release happens). Alternate includes adding these extns to JVM (for eg) --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED Just adding it here as I could see this JIRA as the umbrella JIRA.
          Hide
          mdrob Mike Drob added a comment -

          FYI: jdk-9+175, the first java 9 RC is now available at http://jdk.java.net/9/

          Show
          mdrob Mike Drob added a comment - FYI: jdk-9+175, the first java 9 RC is now available at http://jdk.java.net/9/

            People

            • Assignee:
              Unassigned
              Reporter:
              apurtell Andrew Purtell
            • Votes:
              1 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:

                Development