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.
