Actually the main reason I brought it up was that we currently cannot
guarantee inter-operability with Java 6 any longer.  If I look at our CI
tests, very few of the tests that actually run against Java 6 environments
pass.

This page should give a clearer indication of that problem:
https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20for%20CDI%201.0/

John

On Thu, Apr 7, 2016 at 11:12 AM Cody Lerum <[email protected]> wrote:

> At this point it seems the main driver for dropping Java6 is to
> discourage its use. I think there is sufficient discouragement
> elsewhere and anyone with active or new projects is working towards or
> planning for Java7/8.
>
> +1 for keeping Java6 until the next major bump.
>
> On Thu, Apr 7, 2016 at 7:25 AM, Mark Struberg <[email protected]>
> wrote:
> > Agree, we don't gain much with moving to Java7.
> >
> > Thus I'd say that we keep Java6/CDI-1.0 and have the next major version
> bump (aka DeltaSpike-2.x) targeting Java8 and CDI-2.0. But of course keep a
> ds-1.x maintenance branch even after that for a while.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> >> On Thursday, 7 April 2016, 14:42, Gerhard Petracek <
> [email protected]> wrote:
> >> > as mentioned in the initial discussion i also don't see a real
> benefit for
> >> us as a community (to drop the java 6 support at this point).
> >> in the end ds targets ee6 + supports ee7 servers (including optional
> >> features).
> >> ee6 isn't bound to java 6 technically, however, e.g. some vendors
> require
> >> it...
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >>
> >> 2016-04-07 13:18 GMT+02:00 Rooda, William (John.) <[email protected]>:
> >>
> >>>  Ford has an internal “shared farm” of servers that our applications
> can
> >>>  use. The shared farm is Websphere Application Server 8.0.0.x.  This
> only
> >>>  has Java6 available.  While some teams go out and spend the money to
> >>>  procure their own servers outside of the shared farm, this is
> prohibitively
> >>>  expensive without a powerful use case.
> >>>
> >>>
> >>>
> >>>  Our Java applications won't have a server offering in our internal
> >> shared
> >>>  farm for Java 7 until 4Q2016 or 1Q2017 at the earliest. We plan on
> >>>  developing almost all applications against Java6 until that time, and
> >>>  unfortunately we have to re-evaluate continuing to use at an
> enterprise
> >>>  level any open source software that no longer patches and supports
> Java6
> >>>  due to the risk it introduces to our applications. We understand that
> this
> >>>  makes us an outlier in the community of DeltaSpike users.
> >>>
> >>>
> >>>
> >>>  Thanks,
> >>>
> >>>
> >>>
> >>>  ~john
> >>>
> >>>
> >>>  From: John D. Ament [mailto:[email protected]]
> >>>  Sent: Thursday, April 07, 2016 7:13 AM
> >>>  To: [email protected]; [email protected]
> >>>  Cc: Rooda, William (John.); Shvartsman, Oleg (O.I.); Hall, Todd (T.B.)
> >>>  Subject: Re: Cutting over to Java 7
> >>>
> >>>  Hi Marvin,
> >>>
> >>>  Thanks for the input.  You can find our discussion/vote thread from
> last
> >>>  month here:
> >>>
> >>
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201603.mbox/%3CCAOqetn_vo69sx-yQjLt%3DQpfdRXgXVqu7NiobanLgXKOOr6Co0Q%40mail.gmail.com%3E
> >>>
> >>>  The curious thing about your note - the WebSphere version I've seen
> the
> >>>  Ford team mention a few times requires Java 7.  In general, EE 7
> systems
> >>>  were built for Java 7 support (JMS made use of autocloseable is one I
> can
> >>>  think of off the top of my head).
> >>>
> >>>  As mentioned, there's still a plan to support the 1.6.x line.  If you
> >> guys
> >>>  find any issues that you need to stay on 1.6.x, please feel free to
> raise
> >>>  them and we can address as additional 1.6.x patches.
> >>>
> >>>  John
> >>>  On Thu, Apr 7, 2016 at 6:42 AM Marvin Toll <[email protected]
> >>>  <mailto:[email protected]>> wrote:
> >>>  A data point: Ford Motor Company is on Java 6.  Given our portfolio of
> >>>  4,000 applications (a subset of which are Java) - it is difficult to
> know
> >>>  how long a migration to Java 7 will take.  It was scheduled to begin
> in
> >>>  calendar year 2016 - the current "begin" target is 2017.
> >>>
> >>>  _Marvin
> >>>
> >>>  -----Original Message-----
> >>>  From: John D. Ament [mailto:[email protected]<mailto:
> >>>  [email protected]>]
> >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> >>>  To: deltaspike
> >> <[email protected]<mailto:[email protected]
> >>>  >>
> >>>  Subject: Cutting over to Java 7
> >>>
> >>>  All,
> >>>
> >>>  I wanted to get opinions for how to cut over to Java 7.
> >>>
> >>>  There's two ways I've done similar cut overs in the past, wanted to
> >> share
> >>>  them and build out some ideas.
> >>>
> >>>  1. Continue maintenance on 1.6 for x months.  When we decide that
> we're
> >>>  going to cut a 1.7 we do the switch then.
> >>>
> >>>  2. Decide now that the next release is going to be planned as 1.7.
> If we
> >>>  need to do maintenance on 1.6 we branch from the tag and merge back
> in when
> >>>  done.
> >>>
> >>>  The former is safer, but will take longer.  The last minor release
> had the
> >>>  most patch releases on it, 4.  The latter is more practical and shows
> >>>  implementation much quicker.  It creates a bit more overhead as we'd
> >> need
> >>>  to merge branches.  In the 4.5 years of deltaspike, we haven't had to
> >> do it
> >>>  thus yet.  I suspect that given our user base, #2 would be acceptable
> since
> >>>  most everyone's using Java 7+, so it seems a small chance that we'd
> >> run
> >>>  into a JVM difference.  I'm not sure if others have different ideas to
> >>>  throw out.
> >>>
> >>>  John
> >>>
> >>
>

Reply via email to