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 <nickpa...@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 <monal...@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 <jacob.m...@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 < > > > nram...@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.hoo...@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 <nickpa...@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.m...@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. > > > > > > > > > >
