Re: " Personally, I would really like to tie usage of the new backwards incompatible JDK8 features with the deprecation and elimination of Scala. My argument is that it will be painful to use JDK8, and Scala simultaneously. It seems to me that we'd end up with all the headaches of Scala plus all the headaches of a new JVM. Making that window as small as possible seems prudent."
Is deprecation of Scala within Samza's implementation the current plan of record? osh On Tue, Jul 1, 2014 at 3:17 PM, Chris Riccomini < [email protected]> wrote: > Hey Guys, > > I'm sorry that I'm late to the party, but I'd like to add my 2c. > > Based on the discussion, it seems like everyone agrees that we should > certainly support JDK8 for both the build and runtime environment. > > The two questions that I'd like to see answered are: > > 1. Whether we support JDK 8-specific language features (e.g. Lambdas). > 2. Whether we do binary releases with JDK 7 or JDK 8 as the compiler. > > (1) is problematic because it means we can't actually compile Samza with a > pre-JDK8 version of Java. > > (2) is problematic because it sounds like JDK8 binaries are not backwards > compatible with older JVMs, "Class files built with the Java SE 8 compiler > will not run on earlier releases of Java SE." > [ > http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-215636 > 6.html#A999097] > > These two reasons seem like very strong arguments to support JDK8, but not > eliminate support for JDK7 yet. By "support JDK8", I mean upgrade Gradle > to a version that can build with it, and make sure that everything > compiles and runs properly with JDK8. I think we should continue support > JDK7 compilation and do JDK7 binary releases until its deprecation. I > don't think we should commit to using full-fledged backwards-incompatible > features in JDK8 yet. > > The roadmap idea seems good to me. Personally, I would really like to tie > usage of the new backwards incompatible JDK8 features with the deprecation > and elimination of Scala. My argument is that it will be painful to use > JDK8, and Scala simultaneously. It seems to me that we'd end up with all > the headaches of Scala plus all the headaches of a new JVM. Making that > window as small as possible seems prudent. > > >> deprecating JDK6 now and JDK7 1Q15 would be my preference. How we > >>manage the JDK7 to JDK8 shuffle can be defined later. Though publicising > >>any deprecation intent asap is valuable. > > +1 I agree with Garry. > > >> My opinion: compiling the 0.7.0 binaries with JDK7 would be ok -- it > >>sets a precedent that we will release binaries for the oldest non-EOL > >>version of JDK at the time of release. People on JDK6 can still build > >>the 0.7.0 release themselves. As the binaries are provided only for > >>convenience, that seems ok to me. > > +1 0.7.0 with a Java 7 release sounds good to me. > > Cheers, > Chris > > On 6/30/14 12:48 PM, "Garry Turkington" <[email protected]> > wrote: > > >When I was talking about "default" vice "supported" I meant things like > >we'd likely produce binary releases for the default JDK version and would > >generally look to focus attention on that version. Such as today where we > >work to keep JDK6 support (for now) though I don't think any of us would > >want to do work to do further optimizations for the older version. It > >made sense in my mind anyway, maybe it lost something when being > >marshalled. > > > >I'd support JDK7 for the binaries as implied in the above, as you say > >it's a convenience package only. So to simplify my position; deprecating > >JDK6 now and JDK7 1Q15 would be my preference. How we manage the JDK7 to > >JDK8 shuffle can be defined later. Though publicising any deprecation > >intent asap is valuable. > > > >Garry > > > >-----Original Message----- > >From: Martin Kleppmann [mailto:[email protected]] > >Sent: 26 June 2014 10:09 > >To: [email protected] > >Subject: Re: [DISCUSS] JDK7 v JDK8 (and a bit of Scala v Java) > > > >I agree -- it seems reasonable for Samza to generally follow the EOL > >timelines set by Oracle, which would mean dropping JDK6 support now, and > >dropping JDK7 support in April 2015 or later > >(http://www.oracle.com/technetwork/java/eol-135779.html leaves open the > >option for the April 2015 date to be extended if they deem it necessary). > > > >If we find in future that we need to support deployments in > >slow-to-upgrade organizations, we can still choose to extend our support > >beyond Oracle's EOL dates. But for now, I'd err on the side of not > >supporting old JDKs for longer than necessary. > > > >In your discussion I'm not sure what you mean with a "default" JDK. > >Either a JDK is supported or not. Does "default" imply some kind of > >partial support for the non-default? > > > >The Samza 0.7.0 RC builds and runs fine with JDK6, but we still have to > >make a compatibility decision about the binaries for that release: if the > >Samza jars are built with JDK7, they won't work with a Samza job that's > >built and run with JDK6. Does anyone have strong opinions on which > >version we should use for the 0.7.0 binaries? > > > >My opinion: compiling the 0.7.0 binaries with JDK7 would be ok -- it sets > >a precedent that we will release binaries for the oldest non-EOL version > >of JDK at the time of release. People on JDK6 can still build the 0.7.0 > >release themselves. As the binaries are provided only for convenience, > >that seems ok to me. > > > >Regarding using more Java and less Scala: when the time comes to drop > >JDK7 support, we can start using Java 8 language features, which would > >make Java significantly less painful and reduce Scala's advantages. As a > >long-term direction, I'm fine with using more Java, but as you say, we'd > >want the Java 8 language features first. > > > >Best, > >Martin > > > >On 25 Jun 2014, at 23:34, Garry Turkington > ><[email protected]> wrote: > > > >> Jakob, > >> > >> Re JDK6 support sorry if I was unclear. I believe we should drop > >>support for it asap and add JDK8 support with similar timeliness. I > >>wouldn't want one than more release (awesome work btw guys!) with JDK6 > >>support because that is creating an albatross for our own neck to mix > >>metaphors. > >> > >> I like the idea of a time-based roadmap so for me the clear points are: > >> > >> ASAP: deprecate JDK6 > >> ASAP: Support JDK8 > >> > >> 1Q15: Deprecate JDK7 > >> > >> Then it becomes a question of when we move JDK8 to being the default > >>platform prior to that last milestone. I'd still like to be a little > >>conservative until we have experience of multiple users with it in > >>production (successfully naturally) before going there. > >> > >> Garry > >> -----Original Message----- > >> From: Jakob Homan [mailto:[email protected]] > >> Sent: 25 June 2014 22:17 > >> To: [email protected] > >> Subject: Re: [DISCUSS] JDK7 v JDK8 (and a bit of Scala v Java) > >> > >> On Tue, Jun 24, 2014 at 9:52 PM, Garry Turkington < > >>[email protected]> wrote: > >> > >>> 1. In some organizations there is standardization that gets more > >>> severe the lower you go down the application and system stack. > >>> Deploying a new app or service has a certain degree of pain, but a > >>> 'non-standard' JDK version can be almost as painful as trying to get > >>> a new OS out there. This problem naturally tends to afflict larger > >>> and more conservative companies -- and is likely getting better -- > >>> but I don't think we want premature JDK deprecation to be an > >>>impediment to new users. > >>> > >> Agreed. My counter concern is how JDK6 seems to be becoming the > >> Windows XP of the Hadoop ecosystem; officially extinct infrastructure > >> that we are nonetheless forced to accommodate, thus limiting our > >> ability to take advantage of the new features offered by modern > >> platforms. I'm ashamed to admit that JDK6 was my default compiler > >> until a couple weeks ago (hey, don't judge!) > >> > >> > >>> something similar. So something like the below if we wanted to be > >>> very > >>> methodical: > >>> > >>> Release 0.7: default JDK7, supports JDK6 Release 0.8: Default JDK7 > >>> supports JDK8 Release 0.9: Default JDK8 supports JDK7 Release 0.10: > >>> Default JDK8 > >>> > >> > >> A roadmap is a good idea, but maybe we should tie it to time rather > >>than releases. I'm hoping to have much more frequent releases, now that > >>we've got the first one out the door. It might be better to set the > >>milestones based on the support lifetime of the particular JDK. For > >>example, drop support for JDK6 now and JDK7 when it officially goes EOL. > >> Whatever the roadmap ends up looking like, it will be good to have one. > >> > >> My main concern is being hamstrung to the JDK6 APIs over the next two > >>years and the limitation that will put us in re: Scala support. If > >>we're not able to access any of the new features in JDK8 for fear of > >>breaking 6 or 7 support, it will be a long, long couple of dev years. > >> > >> ----- > >> No virus found in this message. > >> Checked by AVG - www.avg.com > >> Version: 2014.0.4592 / Virus Database: 3986/7742 - Release Date: > >> 06/25/14 > > > > > >----- > >No virus found in this message. > >Checked by AVG - www.avg.com > >Version: 2014.0.4592 / Virus Database: 3986/7742 - Release Date: 06/25/14 > >
