Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce >> mail # dev >> Re: Moving to JDK7, JDK8 and new major releases


Copy link to this message
-
Re: Moving to JDK7, JDK8 and new major releases
I understood the plan for avoiding JDK7-specific features in our code, and
your suggestion to add an extra Jenkins job is a great way to guard against
that.  The thing I haven't seen discussed yet is how downstream projects
will continue to consume our built artifacts.  If a downstream project
upgrades to pick up a bug fix, and the jar switches to 1.7 class files, but
their project is still building with 1.6, then it would be a nasty surprise.

These are the options I see:

1. Make sure all other projects upgrade first.  This doesn't sound
feasible, unless all other ecosystem projects have moved to JDK7 already.
 If not, then waiting on a single long pole project would hold up our
migration indefinitely.

2. We switch to JDK7, but run javac with -target 1.6 until the whole
ecosystem upgrades.  I find this undesirable, because in a certain sense,
it still leaves a bit of 1.6 lingering in the project.  (I'll assume that
end-of-life for JDK6 also means end-of-life for the 1.6 bytecode format.)

3. Just declare a clean break on some version (your earlier email said 2.5)
and start publishing artifacts built with JDK7 and no -target option.
 Overall, this is my preferred option.  However, as a side effect, this
sets us up for longer-term maintenance and patch releases off of the 2.4
branch if a downstream project that's still on 1.6 needs to pick up a
critical bug fix.

Of course, this is all a moot point if all the downstream ecosystem
projects have already made the switch to JDK7.  I don't know the status of
that off the top of my head.  Maybe someone else out there knows?  If not,
then I expect I can free up enough in a few weeks to volunteer for tracking
down that information.

Chris Nauroth
Hortonworks
http://hortonworks.com/

On Wed, Jun 25, 2014 at 3:12 PM, Alejandro Abdelnur <[EMAIL PROTECTED]>
wrote:
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB