[jira] [Commented] (SAMZA-455) Decide on Java 6 support policy

["Mohamed Mahmoud (El-Geish) (JIRA)" <ji...@apache.org>]

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

Mohamed Mahmoud (El-Geish) commented on SAMZA-455:
--------------------------------------------------

Is it too aggressive to require Java 8? The reason I ask is the introduction of default interface methods, which helps to maintain backward compatibility across Samza versions, especially while adding a ton of new features that require coordination between various contributors.
For example, I'm adding a getAll(List<K>) method to KeyValueStore<K, V>, but I can't add it as a default method to the existing interface because we don't require Java 8; and I can't add it to the existing interface that breaks backward compatibility. The current solution is to add a new abstract class, BatchingKeyValueStore, that provides the new functionality and implements said interface, then redirect all KV stores to extend the new class instead of implementing the KeyValueStore interface. What if we decided to add a new method, doX(), after we released the version that has the BatchingKeyValueStore contract, now we need to add yet another abstract class XSupplierBatchingKeyValueStore just for this one added functionality, and sometimes the names will get ugly! I think we should follow in the same steps as the JDK, by adding default methods, and preserving backward compatibility using existing contracts.

> Decide on Java 6 support policy
> -------------------------------
>
>                 Key: SAMZA-455
>                 URL: https://issues.apache.org/jira/browse/SAMZA-455
>             Project: Samza
>          Issue Type: Wish
>          Components: build
>    Affects Versions: 0.9.0
>            Reporter: Martin Kleppmann
>            Assignee: Chris Riccomini
>              Labels: jdk7
>             Fix For: 0.9.0
>
>         Attachments: SAMZA-455-0.patch, SAMZA-455-1.patch
>
>
> Currently Samza builds against JDK 7, although AFAIK we are not yet using JDK7-only language/stdlib features, so we could still support JDK6 if we want to. There have been requests for this:
> * [Eric Sammer|https://twitter.com/esammer/status/516681461219737600]
> * [Tommy Becker|http://mail-archives.apache.org/mod_mbox/incubator-samza-dev/201411.mbox/%3C5458CF13.6080108%40tivo.com%3E]
> In June/July there was a [mailing list discussion|http://mail-archives.apache.org/mod_mbox/incubator-samza-dev/201406.mbox/%3CCADiKvVuvxRH8eP60pXx7AUPOzzdtxzDvNNpdc5%2B6%2BeQ90nqCMQ%40mail.gmail.com%3E] ([continued|http://mail-archives.apache.org/mod_mbox/incubator-samza-dev/201407.mbox/%3CCFD85452.2C7BA%25criccomini%40linkedin.com%3E] — Apache's mailing list archive doesn't do threading across a month boundary) on which JDK versions to support. There was a general desire to start moving towards JDK8, so that we could start using Java 8 language features and gradually start moving away from Scala. But we can't use Java 8 language features as long as we're still supporting JDK 6 and JDK 7, and the day when everyone is using JDK 8+ still seems fairly far in the future.
> JDK 6 was [EOL in Feb 2013|http://www.oracle.com/technetwork/java/eol-135779.html], but if there is continued demand for it, perhaps we should continue supporting it. The counter-argument is that "JDK6 seems to be becoming the Windows XP of the Hadoop ecosystem", as [~jghoman] put it.
> So: should we switch Samza back to building on JDK 6? And if so, can we decide on a policy for removing JDK 6 support?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)