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 >>> >>
