Details

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

      Description

      Musings (as subtasks) on experimental ideas for when JRE8 is a viable runtime.

        Issue Links

          Activity

          Hide
          Andrew Purtell added a comment - - edited

          An update on the timeline for Java 8. Oracle has announced the end of public updates to Java 7 in April of 2015. Java 8 has been in production settings for 6+ months and we have not seen issues with it like there were with Java 7 when it was first released (IIRC, no major Java bugs announced). Apache Lucene has just voted to move their trunk to Java 8. Apache Spark supports Java 8 lambdas. Considering Java 8 as the basis for a production runtime is no longer a theoretical discussion. It will still be some time before some of the subtasks that involve language level issues could be looked at, these depend on making Java 8 the minimum supported version, but others could conditionally enable code after runtime checks.

          Considering Java 8 as a supported runtime, I have linked some related Hadoop JIRAs here.

          • HADOOP-10786: Until Hadoop fixes an internal detail of UserGroupInformation, UGI#reloginFromKeytab will silently fail. This is a blocker for deploying secure HBase. Our secure deployment model expects HBase daemons to login using keytabs and a silent failure to re-login will cause service failure as soon as the TGT expires. There is a patch available on the issue. We just need the Hadoop side to care enough about it to adjust minimum Java version policy on branch-2 and commit the change there. Or perhaps there could be an alternate fix that is compatible with Java 6, but I'm pessimistic about that and don't see the point of it either, 6 is EOL.
          • HADOOP-11098: The MaxDirectMemorySize default setting has changed to unlimited. The memory bean's getMax will return -1 to indicate this, which may cause one of our metrics to become invalid. More importantly we don't need to change the default if using off heap cache, so we should update relevant sections of hbase-env.sh and the online manual.
          Show
          Andrew Purtell added a comment - - edited An update on the timeline for Java 8. Oracle has announced the end of public updates to Java 7 in April of 2015. Java 8 has been in production settings for 6+ months and we have not seen issues with it like there were with Java 7 when it was first released (IIRC, no major Java bugs announced). Apache Lucene has just voted to move their trunk to Java 8. Apache Spark supports Java 8 lambdas. Considering Java 8 as the basis for a production runtime is no longer a theoretical discussion. It will still be some time before some of the subtasks that involve language level issues could be looked at, these depend on making Java 8 the minimum supported version, but others could conditionally enable code after runtime checks. Considering Java 8 as a supported runtime, I have linked some related Hadoop JIRAs here. HADOOP-10786 : Until Hadoop fixes an internal detail of UserGroupInformation, UGI#reloginFromKeytab will silently fail. This is a blocker for deploying secure HBase. Our secure deployment model expects HBase daemons to login using keytabs and a silent failure to re-login will cause service failure as soon as the TGT expires. There is a patch available on the issue. We just need the Hadoop side to care enough about it to adjust minimum Java version policy on branch-2 and commit the change there. Or perhaps there could be an alternate fix that is compatible with Java 6, but I'm pessimistic about that and don't see the point of it either, 6 is EOL. HADOOP-11098 : The MaxDirectMemorySize default setting has changed to unlimited. The memory bean's getMax will return -1 to indicate this, which may cause one of our metrics to become invalid. More importantly we don't need to change the default if using off heap cache, so we should update relevant sections of hbase-env.sh and the online manual.
          Hide
          Misty Stanley-Jones added a comment -

          Wrong JIRA. Sorry.

          Show
          Misty Stanley-Jones added a comment - Wrong JIRA. Sorry.
          Hide
          Misty Stanley-Jones added a comment -

          Removed mention of older versions and updated info for JDK 6 and 8 for 1.0.

          Show
          Misty Stanley-Jones added a comment - Removed mention of older versions and updated info for JDK 6 and 8 for 1.0.
          Hide
          Andrew Purtell added a comment - - edited

          What's an actual feasible timeline for anyone running JDK8?

          I would guess three years. HBase (as a project in some form) has been around since 2007 so could conceivably be still going then.

          Probably it will also be possible to run on the bleeding edge in 2.

          Show
          Andrew Purtell added a comment - - edited What's an actual feasible timeline for anyone running JDK8? I would guess three years. HBase (as a project in some form) has been around since 2007 so could conceivably be still going then. Probably it will also be possible to run on the bleeding edge in 2.
          Hide
          Andrew Purtell added a comment -

          Yep, just some thoughts on what might be possible, transcribed to JIRA for posterity (if it comes around).

          Show
          Andrew Purtell added a comment - Yep, just some thoughts on what might be possible, transcribed to JIRA for posterity (if it comes around).
          Hide
          Todd Lipcon added a comment -

          What's an actual feasible timeline for anyone running JDK8? Most of the above improvements seem like they would only be supported on JDK8 and no earlier versions... seems to me that we wouldn't be able to drop Java6 and Java7 support for at least 3-4 more years at the earliest.

          Show
          Todd Lipcon added a comment - What's an actual feasible timeline for anyone running JDK8? Most of the above improvements seem like they would only be supported on JDK8 and no earlier versions... seems to me that we wouldn't be able to drop Java6 and Java7 support for at least 3-4 more years at the earliest.

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrew Purtell
            • Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:

                Development