[Discuss] Moving Samza to Java 1.8 source compatibility.

[Jacob Maes <ja...@gmail.com>]

Hey everyone,

I wanted to start a discussion to see what folks think about moving to Java
1.8 source compatibility at some point after the 10.1 release.

Java 8 has a number of nice features that can help us build more concise,
maintainable, and robust software. A few notable features that would
benefit Samza:
1. Stream API - provide a compact syntax for expressing transformations on
collections. These may be foundational for future API work including
Operators (SAMZA-914)
2. Default Methods - enable us to evolve interfaces without breaking
compatibility
3. Concurrent package enhancements - generally make concurrent programming
easier, which will be more important with features like multithreading
support (SAMZA-863)
4. Lambdas - love them or hate them, they do reduce the amount of
boilerplate code, especially when used in place of anonymous classes.

It certainly would be nice to leverage some of the features above. However,
we have historically supported Java versions N and N-1 and it doesn't look
like Java 9 is coming until next year. So, discontinuing support for Java
1.7 at this point would be a departure from our normal support matrix for a
significant period of time. Thoughts on the pros and cons?

I know some folks in this community are still on Java 1.7. How many of you
stay up to date with the latest Samza? Do you have a roadmap to move to
Java 1.8?

Thanks,
Jake

Re: [Discuss] Moving Samza to Java 1.8 source compatibility.

[Boris Shkolnik <bo...@gmail.com>]

+1 for moving to 1.8.

On Wed, Apr 27, 2016 at 6:27 PM, Jacob Maes <ja...@gmail.com> wrote:

> Hey everyone,
>
> I wanted to start a discussion to see what folks think about moving to Java
> 1.8 source compatibility at some point after the 10.1 release.
>
> Java 8 has a number of nice features that can help us build more concise,
> maintainable, and robust software. A few notable features that would
> benefit Samza:
> 1. Stream API - provide a compact syntax for expressing transformations on
> collections. These may be foundational for future API work including
> Operators (SAMZA-914)
> 2. Default Methods - enable us to evolve interfaces without breaking
> compatibility
> 3. Concurrent package enhancements - generally make concurrent programming
> easier, which will be more important with features like multithreading
> support (SAMZA-863)
> 4. Lambdas - love them or hate them, they do reduce the amount of
> boilerplate code, especially when used in place of anonymous classes.
>
> It certainly would be nice to leverage some of the features above. However,
> we have historically supported Java versions N and N-1 and it doesn't look
> like Java 9 is coming until next year. So, discontinuing support for Java
> 1.7 at this point would be a departure from our normal support matrix for a
> significant period of time. Thoughts on the pros and cons?
>
> I know some folks in this community are still on Java 1.7. How many of you
> stay up to date with the latest Samza? Do you have a roadmap to move to
> Java 1.8?
>
> Thanks,
> Jake
>

[RESULT][DISCUSS] Moving Samza to Java 1.8 source compatibility.

[Jacob Maes <ja...@gmail.com>]

I agree. This discussion was open for quite a while and we've seen no
opposition. It's time to make the move.

+1 (binding) x2
+1 (non-binding) x3

I've filed SAMZA-1031 <https://issues.apache.org/jira/browse/SAMZA-1031> to
track the work for Samza 0.12. It should be relatively minor.

-Jake

On Fri, Sep 30, 2016 at 12:25 PM, Yi Pan <ni...@gmail.com> wrote:

> Hi, guys,
>
> I have not seen any objection since May on this one. I am concluding it as
> everyone is cool w/ moving to JDK8 in 0.12.
>
> @Jake, can you send out a [RESULT][DISCUSS] email to close this one?
>
> Thanks!
>
> -Yi
>
> On Mon, May 9, 2016 at 3:49 PM, Monal <mo...@gmail.com> wrote:
>
> > Here at Netflix, we have been running Samza on 1.8 since last year and
> have
> > been in production with it. So move to 1.8 is a welcome. No concerns
> there
> > for us.
> >
> > Thanks
> > Monal
> >
> > On Mon, May 2, 2016 at 8:36 AM, Jacob Maes <ja...@gmail.com> wrote:
> >
> > > Thanks everyone. Sounds like a few want to move forward with Java 1.8
> > > source compatibility. I still think it would be useful to hear from a
> > Java
> > > 1.7 shop.
> > >
> > > Hey Maurice, as I recall you were running Samza on Java 1.7. Is that
> > still
> > > the case? Do you have a roadmap to move to 1.8? Do you typically keep
> > your
> > > Samza instance(s) synced with master?
> > >
> > > Thanks,
> > > Jake
> > >
> > > On Thu, Apr 28, 2016 at 11:12 AM, Navina Ramesh <
> > > nramesh@linkedin.com.invalid> wrote:
> > >
> > > > +1 for moving to JDK8.
> > > >
> > > > We have traditionally been pretty slow at releasing. I think we need
> to
> > > > start thinking in terms of long-term release plans and iterate
> faster.
> > > >
> > > > Prior to Samza 1.0, I think we will at least have 2 releases:
> > > > 0.10.1 -> featuring mostly bug-fixes and improvements to
> host-affinity
> > > > 0.11.0 -> incorporating experimental features - asynRunLoop
> > > (multithreading
> > > > and Standalone Samza
> > > > 1.0.0 -> stabilized features - AsyncRunLoop and Standalone +
> > experimental
> > > > SQL operator layer
> > > >
> > > > The above release plan is simply what I had in mind. Nothing is
> > concrete!
> > > > :)
> > > >
> > > > Obviously, we shouldn't remove jdk7 support in 0.10.1. Perhaps,
> 0.11.0.
> > > > will be a good starting point? Or should we wait until we are at 1.0.
> > > >
> > > > I think the users in the community need to provide feedback so we can
> > > make
> > > > progress accordingly.
> > > >
> > > > Thanks!
> > > > Navina
> > > >
> > > >
> > > >
> > > > On Thu, Apr 28, 2016 at 11:00 AM, Roger Hoover <
> roger.hoover@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > +1 for me.  We're already using Java 8 in PRD.
> > > > >
> > > > > On Thu, Apr 28, 2016 at 10:45 AM, Yi Pan <ni...@gmail.com>
> > wrote:
> > > > >
> > > > > > I am +1 on the JDK8 move. As Jake has elaborated, there are
> > numerous
> > > > > > advantages from 1.8 source compatible code.
> > > > > >
> > > > > > As for the downside of dropping JDK7 support, obviously, bin
> > > > > > backward-compatibility will be broken. However, moving to JDK8
> > binary
> > > > is
> > > > > > not a big effort for JDK7-compatible Java and Scala source code,
> in
> > > > term
> > > > > of
> > > > > > compiling and packaging. There is no need for source code change
> > and
> > > we
> > > > > > have been building JDK8 binary in LinkedIn and running in
> > production
> > > w/
> > > > > > JDK8 for a long time w/o seeing any issues.
> > > > > >
> > > > > > For users cannot upgrade their runtime JVM version to JDK8
> easily,
> > > the
> > > > > > latest coming release will still be on JDK7. Question is: how
> long
> > > > should
> > > > > > we hold back in waiting for this upgrade?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > -Yi
> > > > > >
> > > > > > On Wed, Apr 27, 2016 at 6:27 PM, Jacob Maes <
> jacob.maes@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hey everyone,
> > > > > > >
> > > > > > > I wanted to start a discussion to see what folks think about
> > moving
> > > > to
> > > > > > Java
> > > > > > > 1.8 source compatibility at some point after the 10.1 release.
> > > > > > >
> > > > > > > Java 8 has a number of nice features that can help us build
> more
> > > > > concise,
> > > > > > > maintainable, and robust software. A few notable features that
> > > would
> > > > > > > benefit Samza:
> > > > > > > 1. Stream API - provide a compact syntax for expressing
> > > > transformations
> > > > > > on
> > > > > > > collections. These may be foundational for future API work
> > > including
> > > > > > > Operators (SAMZA-914)
> > > > > > > 2. Default Methods - enable us to evolve interfaces without
> > > breaking
> > > > > > > compatibility
> > > > > > > 3. Concurrent package enhancements - generally make concurrent
> > > > > > programming
> > > > > > > easier, which will be more important with features like
> > > > multithreading
> > > > > > > support (SAMZA-863)
> > > > > > > 4. Lambdas - love them or hate them, they do reduce the amount
> of
> > > > > > > boilerplate code, especially when used in place of anonymous
> > > classes.
> > > > > > >
> > > > > > > It certainly would be nice to leverage some of the features
> > above.
> > > > > > However,
> > > > > > > we have historically supported Java versions N and N-1 and it
> > > doesn't
> > > > > > look
> > > > > > > like Java 9 is coming until next year. So, discontinuing
> support
> > > for
> > > > > Java
> > > > > > > 1.7 at this point would be a departure from our normal support
> > > matrix
> > > > > > for a
> > > > > > > significant period of time. Thoughts on the pros and cons?
> > > > > > >
> > > > > > > I know some folks in this community are still on Java 1.7. How
> > many
> > > > of
> > > > > > you
> > > > > > > stay up to date with the latest Samza? Do you have a roadmap to
> > > move
> > > > to
> > > > > > > Java 1.8?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Jake
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Navina R.
> > > >
> > >
> >
>

Re: [Discuss] Moving Samza to Java 1.8 source compatibility.

[Yi Pan <ni...@gmail.com>]

Hi, guys,

I have not seen any objection since May on this one. I am concluding it as
everyone is cool w/ moving to JDK8 in 0.12.

@Jake, can you send out a [RESULT][DISCUSS] email to close this one?

Thanks!

-Yi

On Mon, May 9, 2016 at 3:49 PM, Monal <mo...@gmail.com> wrote:

> Here at Netflix, we have been running Samza on 1.8 since last year and have
> been in production with it. So move to 1.8 is a welcome. No concerns there
> for us.
>
> Thanks
> Monal
>
> On Mon, May 2, 2016 at 8:36 AM, Jacob Maes <ja...@gmail.com> wrote:
>
> > Thanks everyone. Sounds like a few want to move forward with Java 1.8
> > source compatibility. I still think it would be useful to hear from a
> Java
> > 1.7 shop.
> >
> > Hey Maurice, as I recall you were running Samza on Java 1.7. Is that
> still
> > the case? Do you have a roadmap to move to 1.8? Do you typically keep
> your
> > Samza instance(s) synced with master?
> >
> > Thanks,
> > Jake
> >
> > On Thu, Apr 28, 2016 at 11:12 AM, Navina Ramesh <
> > nramesh@linkedin.com.invalid> wrote:
> >
> > > +1 for moving to JDK8.
> > >
> > > We have traditionally been pretty slow at releasing. I think we need to
> > > start thinking in terms of long-term release plans and iterate faster.
> > >
> > > Prior to Samza 1.0, I think we will at least have 2 releases:
> > > 0.10.1 -> featuring mostly bug-fixes and improvements to host-affinity
> > > 0.11.0 -> incorporating experimental features - asynRunLoop
> > (multithreading
> > > and Standalone Samza
> > > 1.0.0 -> stabilized features - AsyncRunLoop and Standalone +
> experimental
> > > SQL operator layer
> > >
> > > The above release plan is simply what I had in mind. Nothing is
> concrete!
> > > :)
> > >
> > > Obviously, we shouldn't remove jdk7 support in 0.10.1. Perhaps, 0.11.0.
> > > will be a good starting point? Or should we wait until we are at 1.0.
> > >
> > > I think the users in the community need to provide feedback so we can
> > make
> > > progress accordingly.
> > >
> > > Thanks!
> > > Navina
> > >
> > >
> > >
> > > On Thu, Apr 28, 2016 at 11:00 AM, Roger Hoover <roger.hoover@gmail.com
> >
> > > wrote:
> > >
> > > > +1 for me.  We're already using Java 8 in PRD.
> > > >
> > > > On Thu, Apr 28, 2016 at 10:45 AM, Yi Pan <ni...@gmail.com>
> wrote:
> > > >
> > > > > I am +1 on the JDK8 move. As Jake has elaborated, there are
> numerous
> > > > > advantages from 1.8 source compatible code.
> > > > >
> > > > > As for the downside of dropping JDK7 support, obviously, bin
> > > > > backward-compatibility will be broken. However, moving to JDK8
> binary
> > > is
> > > > > not a big effort for JDK7-compatible Java and Scala source code, in
> > > term
> > > > of
> > > > > compiling and packaging. There is no need for source code change
> and
> > we
> > > > > have been building JDK8 binary in LinkedIn and running in
> production
> > w/
> > > > > JDK8 for a long time w/o seeing any issues.
> > > > >
> > > > > For users cannot upgrade their runtime JVM version to JDK8 easily,
> > the
> > > > > latest coming release will still be on JDK7. Question is: how long
> > > should
> > > > > we hold back in waiting for this upgrade?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > -Yi
> > > > >
> > > > > On Wed, Apr 27, 2016 at 6:27 PM, Jacob Maes <ja...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Hey everyone,
> > > > > >
> > > > > > I wanted to start a discussion to see what folks think about
> moving
> > > to
> > > > > Java
> > > > > > 1.8 source compatibility at some point after the 10.1 release.
> > > > > >
> > > > > > Java 8 has a number of nice features that can help us build more
> > > > concise,
> > > > > > maintainable, and robust software. A few notable features that
> > would
> > > > > > benefit Samza:
> > > > > > 1. Stream API - provide a compact syntax for expressing
> > > transformations
> > > > > on
> > > > > > collections. These may be foundational for future API work
> > including
> > > > > > Operators (SAMZA-914)
> > > > > > 2. Default Methods - enable us to evolve interfaces without
> > breaking
> > > > > > compatibility
> > > > > > 3. Concurrent package enhancements - generally make concurrent
> > > > > programming
> > > > > > easier, which will be more important with features like
> > > multithreading
> > > > > > support (SAMZA-863)
> > > > > > 4. Lambdas - love them or hate them, they do reduce the amount of
> > > > > > boilerplate code, especially when used in place of anonymous
> > classes.
> > > > > >
> > > > > > It certainly would be nice to leverage some of the features
> above.
> > > > > However,
> > > > > > we have historically supported Java versions N and N-1 and it
> > doesn't
> > > > > look
> > > > > > like Java 9 is coming until next year. So, discontinuing support
> > for
> > > > Java
> > > > > > 1.7 at this point would be a departure from our normal support
> > matrix
> > > > > for a
> > > > > > significant period of time. Thoughts on the pros and cons?
> > > > > >
> > > > > > I know some folks in this community are still on Java 1.7. How
> many
> > > of
> > > > > you
> > > > > > stay up to date with the latest Samza? Do you have a roadmap to
> > move
> > > to
> > > > > > Java 1.8?
> > > > > >
> > > > > > Thanks,
> > > > > > Jake
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Navina R.
> > >
> >
>

Re: [Discuss] Moving Samza to Java 1.8 source compatibility.

[Monal <mo...@gmail.com>]

Here at Netflix, we have been running Samza on 1.8 since last year and have
been in production with it. So move to 1.8 is a welcome. No concerns there
for us.

Thanks
Monal

On Mon, May 2, 2016 at 8:36 AM, Jacob Maes <ja...@gmail.com> wrote:

> Thanks everyone. Sounds like a few want to move forward with Java 1.8
> source compatibility. I still think it would be useful to hear from a Java
> 1.7 shop.
>
> Hey Maurice, as I recall you were running Samza on Java 1.7. Is that still
> the case? Do you have a roadmap to move to 1.8? Do you typically keep your
> Samza instance(s) synced with master?
>
> Thanks,
> Jake
>
> On Thu, Apr 28, 2016 at 11:12 AM, Navina Ramesh <
> nramesh@linkedin.com.invalid> wrote:
>
> > +1 for moving to JDK8.
> >
> > We have traditionally been pretty slow at releasing. I think we need to
> > start thinking in terms of long-term release plans and iterate faster.
> >
> > Prior to Samza 1.0, I think we will at least have 2 releases:
> > 0.10.1 -> featuring mostly bug-fixes and improvements to host-affinity
> > 0.11.0 -> incorporating experimental features - asynRunLoop
> (multithreading
> > and Standalone Samza
> > 1.0.0 -> stabilized features - AsyncRunLoop and Standalone + experimental
> > SQL operator layer
> >
> > The above release plan is simply what I had in mind. Nothing is concrete!
> > :)
> >
> > Obviously, we shouldn't remove jdk7 support in 0.10.1. Perhaps, 0.11.0.
> > will be a good starting point? Or should we wait until we are at 1.0.
> >
> > I think the users in the community need to provide feedback so we can
> make
> > progress accordingly.
> >
> > Thanks!
> > Navina
> >
> >
> >
> > On Thu, Apr 28, 2016 at 11:00 AM, Roger Hoover <ro...@gmail.com>
> > wrote:
> >
> > > +1 for me.  We're already using Java 8 in PRD.
> > >
> > > On Thu, Apr 28, 2016 at 10:45 AM, Yi Pan <ni...@gmail.com> wrote:
> > >
> > > > I am +1 on the JDK8 move. As Jake has elaborated, there are numerous
> > > > advantages from 1.8 source compatible code.
> > > >
> > > > As for the downside of dropping JDK7 support, obviously, bin
> > > > backward-compatibility will be broken. However, moving to JDK8 binary
> > is
> > > > not a big effort for JDK7-compatible Java and Scala source code, in
> > term
> > > of
> > > > compiling and packaging. There is no need for source code change and
> we
> > > > have been building JDK8 binary in LinkedIn and running in production
> w/
> > > > JDK8 for a long time w/o seeing any issues.
> > > >
> > > > For users cannot upgrade their runtime JVM version to JDK8 easily,
> the
> > > > latest coming release will still be on JDK7. Question is: how long
> > should
> > > > we hold back in waiting for this upgrade?
> > > >
> > > > Thanks!
> > > >
> > > > -Yi
> > > >
> > > > On Wed, Apr 27, 2016 at 6:27 PM, Jacob Maes <ja...@gmail.com>
> > > wrote:
> > > >
> > > > > Hey everyone,
> > > > >
> > > > > I wanted to start a discussion to see what folks think about moving
> > to
> > > > Java
> > > > > 1.8 source compatibility at some point after the 10.1 release.
> > > > >
> > > > > Java 8 has a number of nice features that can help us build more
> > > concise,
> > > > > maintainable, and robust software. A few notable features that
> would
> > > > > benefit Samza:
> > > > > 1. Stream API - provide a compact syntax for expressing
> > transformations
> > > > on
> > > > > collections. These may be foundational for future API work
> including
> > > > > Operators (SAMZA-914)
> > > > > 2. Default Methods - enable us to evolve interfaces without
> breaking
> > > > > compatibility
> > > > > 3. Concurrent package enhancements - generally make concurrent
> > > > programming
> > > > > easier, which will be more important with features like
> > multithreading
> > > > > support (SAMZA-863)
> > > > > 4. Lambdas - love them or hate them, they do reduce the amount of
> > > > > boilerplate code, especially when used in place of anonymous
> classes.
> > > > >
> > > > > It certainly would be nice to leverage some of the features above.
> > > > However,
> > > > > we have historically supported Java versions N and N-1 and it
> doesn't
> > > > look
> > > > > like Java 9 is coming until next year. So, discontinuing support
> for
> > > Java
> > > > > 1.7 at this point would be a departure from our normal support
> matrix
> > > > for a
> > > > > significant period of time. Thoughts on the pros and cons?
> > > > >
> > > > > I know some folks in this community are still on Java 1.7. How many
> > of
> > > > you
> > > > > stay up to date with the latest Samza? Do you have a roadmap to
> move
> > to
> > > > > Java 1.8?
> > > > >
> > > > > Thanks,
> > > > > Jake
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Navina R.
> >
>

Re: [Discuss] Moving Samza to Java 1.8 source compatibility.

[Jacob Maes <ja...@gmail.com>]

Thanks everyone. Sounds like a few want to move forward with Java 1.8
source compatibility. I still think it would be useful to hear from a Java
1.7 shop.

Hey Maurice, as I recall you were running Samza on Java 1.7. Is that still
the case? Do you have a roadmap to move to 1.8? Do you typically keep your
Samza instance(s) synced with master?

Thanks,
Jake

On Thu, Apr 28, 2016 at 11:12 AM, Navina Ramesh <
nramesh@linkedin.com.invalid> wrote:

> +1 for moving to JDK8.
>
> We have traditionally been pretty slow at releasing. I think we need to
> start thinking in terms of long-term release plans and iterate faster.
>
> Prior to Samza 1.0, I think we will at least have 2 releases:
> 0.10.1 -> featuring mostly bug-fixes and improvements to host-affinity
> 0.11.0 -> incorporating experimental features - asynRunLoop (multithreading
> and Standalone Samza
> 1.0.0 -> stabilized features - AsyncRunLoop and Standalone + experimental
> SQL operator layer
>
> The above release plan is simply what I had in mind. Nothing is concrete!
> :)
>
> Obviously, we shouldn't remove jdk7 support in 0.10.1. Perhaps, 0.11.0.
> will be a good starting point? Or should we wait until we are at 1.0.
>
> I think the users in the community need to provide feedback so we can make
> progress accordingly.
>
> Thanks!
> Navina
>
>
>
> On Thu, Apr 28, 2016 at 11:00 AM, Roger Hoover <ro...@gmail.com>
> wrote:
>
> > +1 for me.  We're already using Java 8 in PRD.
> >
> > On Thu, Apr 28, 2016 at 10:45 AM, Yi Pan <ni...@gmail.com> wrote:
> >
> > > I am +1 on the JDK8 move. As Jake has elaborated, there are numerous
> > > advantages from 1.8 source compatible code.
> > >
> > > As for the downside of dropping JDK7 support, obviously, bin
> > > backward-compatibility will be broken. However, moving to JDK8 binary
> is
> > > not a big effort for JDK7-compatible Java and Scala source code, in
> term
> > of
> > > compiling and packaging. There is no need for source code change and we
> > > have been building JDK8 binary in LinkedIn and running in production w/
> > > JDK8 for a long time w/o seeing any issues.
> > >
> > > For users cannot upgrade their runtime JVM version to JDK8 easily, the
> > > latest coming release will still be on JDK7. Question is: how long
> should
> > > we hold back in waiting for this upgrade?
> > >
> > > Thanks!
> > >
> > > -Yi
> > >
> > > On Wed, Apr 27, 2016 at 6:27 PM, Jacob Maes <ja...@gmail.com>
> > wrote:
> > >
> > > > Hey everyone,
> > > >
> > > > I wanted to start a discussion to see what folks think about moving
> to
> > > Java
> > > > 1.8 source compatibility at some point after the 10.1 release.
> > > >
> > > > Java 8 has a number of nice features that can help us build more
> > concise,
> > > > maintainable, and robust software. A few notable features that would
> > > > benefit Samza:
> > > > 1. Stream API - provide a compact syntax for expressing
> transformations
> > > on
> > > > collections. These may be foundational for future API work including
> > > > Operators (SAMZA-914)
> > > > 2. Default Methods - enable us to evolve interfaces without breaking
> > > > compatibility
> > > > 3. Concurrent package enhancements - generally make concurrent
> > > programming
> > > > easier, which will be more important with features like
> multithreading
> > > > support (SAMZA-863)
> > > > 4. Lambdas - love them or hate them, they do reduce the amount of
> > > > boilerplate code, especially when used in place of anonymous classes.
> > > >
> > > > It certainly would be nice to leverage some of the features above.
> > > However,
> > > > we have historically supported Java versions N and N-1 and it doesn't
> > > look
> > > > like Java 9 is coming until next year. So, discontinuing support for
> > Java
> > > > 1.7 at this point would be a departure from our normal support matrix
> > > for a
> > > > significant period of time. Thoughts on the pros and cons?
> > > >
> > > > I know some folks in this community are still on Java 1.7. How many
> of
> > > you
> > > > stay up to date with the latest Samza? Do you have a roadmap to move
> to
> > > > Java 1.8?
> > > >
> > > > Thanks,
> > > > Jake
> > > >
> > >
> >
>
>
>
> --
> Navina R.
>

Re: [Discuss] Moving Samza to Java 1.8 source compatibility.

[Navina Ramesh <nr...@linkedin.com.INVALID>]

+1 for moving to JDK8.

We have traditionally been pretty slow at releasing. I think we need to
start thinking in terms of long-term release plans and iterate faster.

Prior to Samza 1.0, I think we will at least have 2 releases:
0.10.1 -> featuring mostly bug-fixes and improvements to host-affinity
0.11.0 -> incorporating experimental features - asynRunLoop (multithreading
and Standalone Samza
1.0.0 -> stabilized features - AsyncRunLoop and Standalone + experimental
SQL operator layer

The above release plan is simply what I had in mind. Nothing is concrete! :)

Obviously, we shouldn't remove jdk7 support in 0.10.1. Perhaps, 0.11.0.
will be a good starting point? Or should we wait until we are at 1.0.

I think the users in the community need to provide feedback so we can make
progress accordingly.

Thanks!
Navina



On Thu, Apr 28, 2016 at 11:00 AM, Roger Hoover <ro...@gmail.com>
wrote:

> +1 for me.  We're already using Java 8 in PRD.
>
> On Thu, Apr 28, 2016 at 10:45 AM, Yi Pan <ni...@gmail.com> wrote:
>
> > I am +1 on the JDK8 move. As Jake has elaborated, there are numerous
> > advantages from 1.8 source compatible code.
> >
> > As for the downside of dropping JDK7 support, obviously, bin
> > backward-compatibility will be broken. However, moving to JDK8 binary is
> > not a big effort for JDK7-compatible Java and Scala source code, in term
> of
> > compiling and packaging. There is no need for source code change and we
> > have been building JDK8 binary in LinkedIn and running in production w/
> > JDK8 for a long time w/o seeing any issues.
> >
> > For users cannot upgrade their runtime JVM version to JDK8 easily, the
> > latest coming release will still be on JDK7. Question is: how long should
> > we hold back in waiting for this upgrade?
> >
> > Thanks!
> >
> > -Yi
> >
> > On Wed, Apr 27, 2016 at 6:27 PM, Jacob Maes <ja...@gmail.com>
> wrote:
> >
> > > Hey everyone,
> > >
> > > I wanted to start a discussion to see what folks think about moving to
> > Java
> > > 1.8 source compatibility at some point after the 10.1 release.
> > >
> > > Java 8 has a number of nice features that can help us build more
> concise,
> > > maintainable, and robust software. A few notable features that would
> > > benefit Samza:
> > > 1. Stream API - provide a compact syntax for expressing transformations
> > on
> > > collections. These may be foundational for future API work including
> > > Operators (SAMZA-914)
> > > 2. Default Methods - enable us to evolve interfaces without breaking
> > > compatibility
> > > 3. Concurrent package enhancements - generally make concurrent
> > programming
> > > easier, which will be more important with features like multithreading
> > > support (SAMZA-863)
> > > 4. Lambdas - love them or hate them, they do reduce the amount of
> > > boilerplate code, especially when used in place of anonymous classes.
> > >
> > > It certainly would be nice to leverage some of the features above.
> > However,
> > > we have historically supported Java versions N and N-1 and it doesn't
> > look
> > > like Java 9 is coming until next year. So, discontinuing support for
> Java
> > > 1.7 at this point would be a departure from our normal support matrix
> > for a
> > > significant period of time. Thoughts on the pros and cons?
> > >
> > > I know some folks in this community are still on Java 1.7. How many of
> > you
> > > stay up to date with the latest Samza? Do you have a roadmap to move to
> > > Java 1.8?
> > >
> > > Thanks,
> > > Jake
> > >
> >
>



-- 
Navina R.

Re: [Discuss] Moving Samza to Java 1.8 source compatibility.

[Roger Hoover <ro...@gmail.com>]

+1 for me.  We're already using Java 8 in PRD.

On Thu, Apr 28, 2016 at 10:45 AM, Yi Pan <ni...@gmail.com> wrote:

> I am +1 on the JDK8 move. As Jake has elaborated, there are numerous
> advantages from 1.8 source compatible code.
>
> As for the downside of dropping JDK7 support, obviously, bin
> backward-compatibility will be broken. However, moving to JDK8 binary is
> not a big effort for JDK7-compatible Java and Scala source code, in term of
> compiling and packaging. There is no need for source code change and we
> have been building JDK8 binary in LinkedIn and running in production w/
> JDK8 for a long time w/o seeing any issues.
>
> For users cannot upgrade their runtime JVM version to JDK8 easily, the
> latest coming release will still be on JDK7. Question is: how long should
> we hold back in waiting for this upgrade?
>
> Thanks!
>
> -Yi
>
> On Wed, Apr 27, 2016 at 6:27 PM, Jacob Maes <ja...@gmail.com> wrote:
>
> > Hey everyone,
> >
> > I wanted to start a discussion to see what folks think about moving to
> Java
> > 1.8 source compatibility at some point after the 10.1 release.
> >
> > Java 8 has a number of nice features that can help us build more concise,
> > maintainable, and robust software. A few notable features that would
> > benefit Samza:
> > 1. Stream API - provide a compact syntax for expressing transformations
> on
> > collections. These may be foundational for future API work including
> > Operators (SAMZA-914)
> > 2. Default Methods - enable us to evolve interfaces without breaking
> > compatibility
> > 3. Concurrent package enhancements - generally make concurrent
> programming
> > easier, which will be more important with features like multithreading
> > support (SAMZA-863)
> > 4. Lambdas - love them or hate them, they do reduce the amount of
> > boilerplate code, especially when used in place of anonymous classes.
> >
> > It certainly would be nice to leverage some of the features above.
> However,
> > we have historically supported Java versions N and N-1 and it doesn't
> look
> > like Java 9 is coming until next year. So, discontinuing support for Java
> > 1.7 at this point would be a departure from our normal support matrix
> for a
> > significant period of time. Thoughts on the pros and cons?
> >
> > I know some folks in this community are still on Java 1.7. How many of
> you
> > stay up to date with the latest Samza? Do you have a roadmap to move to
> > Java 1.8?
> >
> > Thanks,
> > Jake
> >
>

Re: [Discuss] Moving Samza to Java 1.8 source compatibility.

[Yi Pan <ni...@gmail.com>]

I am +1 on the JDK8 move. As Jake has elaborated, there are numerous
advantages from 1.8 source compatible code.

As for the downside of dropping JDK7 support, obviously, bin
backward-compatibility will be broken. However, moving to JDK8 binary is
not a big effort for JDK7-compatible Java and Scala source code, in term of
compiling and packaging. There is no need for source code change and we
have been building JDK8 binary in LinkedIn and running in production w/
JDK8 for a long time w/o seeing any issues.

For users cannot upgrade their runtime JVM version to JDK8 easily, the
latest coming release will still be on JDK7. Question is: how long should
we hold back in waiting for this upgrade?

Thanks!

-Yi

On Wed, Apr 27, 2016 at 6:27 PM, Jacob Maes <ja...@gmail.com> wrote:

> Hey everyone,
>
> I wanted to start a discussion to see what folks think about moving to Java
> 1.8 source compatibility at some point after the 10.1 release.
>
> Java 8 has a number of nice features that can help us build more concise,
> maintainable, and robust software. A few notable features that would
> benefit Samza:
> 1. Stream API - provide a compact syntax for expressing transformations on
> collections. These may be foundational for future API work including
> Operators (SAMZA-914)
> 2. Default Methods - enable us to evolve interfaces without breaking
> compatibility
> 3. Concurrent package enhancements - generally make concurrent programming
> easier, which will be more important with features like multithreading
> support (SAMZA-863)
> 4. Lambdas - love them or hate them, they do reduce the amount of
> boilerplate code, especially when used in place of anonymous classes.
>
> It certainly would be nice to leverage some of the features above. However,
> we have historically supported Java versions N and N-1 and it doesn't look
> like Java 9 is coming until next year. So, discontinuing support for Java
> 1.7 at this point would be a departure from our normal support matrix for a
> significant period of time. Thoughts on the pros and cons?
>
> I know some folks in this community are still on Java 1.7. How many of you
> stay up to date with the latest Samza? Do you have a roadmap to move to
> Java 1.8?
>
> Thanks,
> Jake
>