Hey Osh, No, not at the moment. It's something that's up for discussion, but we don't have any concrete plans.
Cheers, Chris On 7/1/14 6:57 PM, "Oshoma Momoh" <[email protected]> wrote: >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-21563 >>6 >> 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 >> >>
