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
