river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: [VOTE] drop JDK 5 compatibility
Date Tue, 08 Feb 2011 10:23:11 GMT
-1

For similar reasons. There is I believe a small change in the concurrency
libraries between 1.5 and 1.6 which can cause some backward compatibility
problems at runtime. That might be an issue we have to address but it's
pretty rare as I recall. Thus there is little benefit to dropping 1.5 for us
at this moment and if dropping 1.5 penalises our users, well that's a big
negative.

On 8 February 2011 10:05, Tom Hobbs <tvhobbs@googlemail.com> wrote:

> -1
>
> My reasons are not based on technical merit.  We have a vocal and
> helpful user who explicitly states that dropping JDK 1.5 means the end
> for him and I think that we must take his situation into
> consideration.  As far as I can see there is no "If only we stipulated
> JDK 1.6 then we could..." requirement so I seriously question the
> value of doing so.
>
> On Tue, Feb 8, 2011 at 7:57 AM, Niclas Hedhman <niclas@hedhman.org> wrote:
> > So, although consider my opinion of 'low impact', I agree with Peter
> > that there need to be a substantial case for platform-like code to
> > abandon a previous Java version. IMHO, Java 5 has a LOT of features
> > that most platforms can leverage to their advantage, Java 6 much less
> > so...
> >
> > My primary project just recently up'ed the requirement to Java 6, due
> > to a nasty bug in the Generics compiler in Java 5, for which there is
> > never going to be a fix. If/when there are such issues in River, then
> > sure...
> >
> > As for 'recommended version', it is quite important that River's core
> > team and test set up are using JDK 1.5 in their toolkits, as it
> > otherwise quickly 'leaks' 1.6 methods into the codebase. Also, if the
> > test or build tools require 1.6, then I think that is totally
> > acceptable as well.
> >
> >
> > Cheers and keep up the good momentum....
> >
> > Cheers
> > Niclas
> >
> > On Tue, Feb 8, 2011 at 2:47 PM, Peter Firmstone <jini@zeus.net.au>
> wrote:
> >> -1 Peter Firmstone.
> >>
> >> I could vote +1 to dropping support (us fixing something to work around
> a
> >> Java 5 only bug) due to the resources of our small team, leaving the
> door
> >> open to the community to contribute patches, but not compatibility I'm
> >> afraid, I just haven't seen a good reason why we need to make River
> >> incompatible with Java 5.
> >>
> >> Is there a feature we need in the platform that requires Java 6?
> >>
> >> Are we adding a feature to a proxy that requires Java 6?
> >>
> >> I don't think a service implementation (server side) is a good enough
> reason
> >> to drop compatibility.
> >>
> >> That doesn't mean that we can't produce a service implementation that
> does
> >> require Java 6 as a minimum and release it as a separate concern, just
> that
> >> it's unreasonable to expect everything else to be dragged along with it.
> >>
> >> Note: The QA Test suite requires JDK1.6 to compile, because some of it's
> >> tests depend on internal Sun Java platform implementation details.  The
> QA
> >> harness is compatible with earlier versions of Java.  The jtreg tests
> >> require Java 5, due to some tests relying on internal Sun Java platform
> >> implementation details.
> >>
> >> I recommend people use Java 6 if they can, but not everyone is that
> lucky.
> >>
> >> I understand the reasons for making such decisions, but I think we need
> to
> >> further investigate breaking the codebase up into smaller easier to
> maintain
> >> components, then determining the requirements of each before decisions
> like
> >> this are made.  We have too much coupling between implementation and
> >> platform at present.
> >>
> >> Peter.
> >>
> >>
> >>
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://www.qi4j.org - New Energy for Java
> >
> > I live here; http://tinyurl.com/3xugrbk
> > I work here; http://tinyurl.com/24svnvk
> > I relax here; http://tinyurl.com/2cgsug
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message