+1 on moving to JDK7 only for 1.0+
-1 on dropping JDK6 support for anything earlier (i.e. 0.98, 0.96, 0.94).

If there are issues with JDK6 in 0.98 already that would be a major bug that we 
need to fix, IMHO.


-- Lars



________________________________
 From: Enis Söztutar <[email protected]>
To: "[email protected]" <[email protected]> 
Sent: Wednesday, June 25, 2014 12:53 PM
Subject: Re: jdk 1.7 & trunk
 

My vote will be

1) Not drop support in JDK6 in 0.98.x series as per above.

2) Drop support to JDK6 in 1.x series.

Also see recent jira: https://issues.apache.org/jira/browse/HBASE-11102

Enis





On Wed, Jun 25, 2014 at 12:13 PM, Stack <[email protected]> wrote:

> On Wed, Jun 25, 2014 at 11:48 AM, Nicolas Liochon <[email protected]>
> wrote:
>
> > Ok Enis I like the definition you put in the thread.
> >
> > Dropping support explicitly means that we stop building against
> > JDK6 in jenkins, and won't try to fix issues if they are jdk6 only.
> Release
> > testing and unit tests are done on jdk7.
> >
> >
> This is good by me.
>
>
>
> > And it implies; we may start to use 1.7 specific features.
> >
> >
> Are there explicitly 1.7 features we want to make use of?  Looking at this
> list, we might be able to do without:
>
> http://marxsoftware.blogspot.com/2011/03/jdk-7-new-interfaces-classes-enums-and.html
>  Unless distinct advantage to be had, suggest we avoid breaking our being
> able to run on 1.6. 1.0 hbase will be out in a world that is hadoop
> 2.3.x-2.5.x  These do not preclude running on 1.6.
>
>
>
> > With this definition:
> > 1) Do we drop support for JDK6 in .98
> >
>
> No.  Not over a point release I'd say.
>
>
>
> > 2) Do we drop support for JDK6 in 1.0
> >
> >
> Thinking on it, I'd say yes.  1.6 is EOL.  1.7 makes you faster.  Caveat
> suggestion above that we try and avoid gratuitously breaking 1.6.
>
>
> > Does anyone think we need to discuss this or can we start a vote on this?
> > If there is no objection I will start the vote thread in an hour or two.
> >
>
> We can vote.  Could also just decide.
>
> St.Ack
>

Reply via email to