Thanks John, Believe me... I've been watching the thread closely. :-)
I did not feel compelled to enter in until such time as it was being determined the approach for accommodation of Java 6 users. You may have seen some POC code that is being used for preparation of our eventual move to Java 7 that we thought was going to begin this year??? However, our standard data center offering remains WAS 8 (classic) with Java 6 (at this time). _Marvin -----Original Message----- From: John D. Ament [mailto:[email protected]] Sent: Thursday, April 7, 2016 7:13 AM 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]> 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]] > Sent: Wednesday, April 6, 2016 10:14 PM > To: deltaspike <[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 > >
