Cutting over to Java 7

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Cutting over to Java 7

John D. Ament
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 | Threaded
Open this post in threaded view
|

RE: Cutting over to Java 7

MarvinToll
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:[hidden email]]
Sent: Wednesday, April 6, 2016 10:14 PM
To: deltaspike <[hidden email]>
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

------------------------------------------
|  USA Cell: 248.866.4897
|  Email: Marvin@gtcGroup.com
|  Web: http://MarvinToll.com
|  Skype: marvin.toll
------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

John D. Ament
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 <[hidden email]> 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:[hidden email]]
> Sent: Wednesday, April 6, 2016 10:14 PM
> To: deltaspike <[hidden email]>
> 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 | Threaded
Open this post in threaded view
|

RE: Cutting over to Java 7

MarvinToll
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:[hidden email]]
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 <[hidden email]> 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:[hidden email]]
> Sent: Wednesday, April 6, 2016 10:14 PM
> To: deltaspike <[hidden email]>
> 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
>
>

------------------------------------------
|  USA Cell: 248.866.4897
|  Email: Marvin@gtcGroup.com
|  Web: http://MarvinToll.com
|  Skype: marvin.toll
------------------------------------------
Reply | Threaded
Open this post in threaded view
|

RE: Cutting over to Java 7

Rooda, William (John.)
In reply to this post by John D. Ament
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:[hidden email]]
Sent: Thursday, April 07, 2016 7:13 AM
To: [hidden email]; [hidden email]
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 <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>]
Sent: Wednesday, April 6, 2016 10:14 PM
To: deltaspike <[hidden email]<mailto:[hidden email]>>
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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Gerhard Petracek-2
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.) <[hidden email]>:

> 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:[hidden email]]
> Sent: Thursday, April 07, 2016 7:13 AM
> To: [hidden email]; [hidden email]
> 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 <[hidden email]
> <mailto:[hidden email]>> 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:[hidden email]<mailto:
> [hidden email]>]
> Sent: Wednesday, April 6, 2016 10:14 PM
> To: deltaspike <[hidden email]<mailto:[hidden email]
> >>
> 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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Mark Struberg-3
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 <[hidden email]> 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.) <[hidden email]>:
>
>>  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:[hidden email]]
>>  Sent: Thursday, April 07, 2016 7:13 AM
>>  To: [hidden email]; [hidden email]
>>  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 <[hidden email]
>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
>>  [hidden email]>]
>>  Sent: Wednesday, April 6, 2016 10:14 PM
>>  To: deltaspike
> <[hidden email]<mailto:[hidden email]
>>  >>
>>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Gerhard Petracek-2
@mark: +1

regards,
gerhard



2016-04-07 15:25 GMT+02:00 Mark Struberg <[hidden email]>:

> 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 <[hidden email]>
> 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.) <[hidden email]>:
> >
> >>  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:[hidden email]]
> >>  Sent: Thursday, April 07, 2016 7:13 AM
> >>  To: [hidden email]; [hidden email]
> >>  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 <[hidden email]
> >>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> >>  [hidden email]>]
> >>  Sent: Wednesday, April 6, 2016 10:14 PM
> >>  To: deltaspike
> > <[hidden email]<mailto:[hidden email]
> >>  >>
> >>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Cody Lerum
In reply to this post by Mark Struberg-3
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 <[hidden email]> 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 <[hidden email]> 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.) <[hidden email]>:
>>
>>>  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:[hidden email]]
>>>  Sent: Thursday, April 07, 2016 7:13 AM
>>>  To: [hidden email]; [hidden email]
>>>  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 <[hidden email]
>>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
>>>  [hidden email]>]
>>>  Sent: Wednesday, April 6, 2016 10:14 PM
>>>  To: deltaspike
>> <[hidden email]<mailto:[hidden email]
>>>  >>
>>>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

John D. Ament
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 <[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]> 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.) <[hidden email]>:
> >>
> >>>  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:[hidden email]]
> >>>  Sent: Thursday, April 07, 2016 7:13 AM
> >>>  To: [hidden email]; [hidden email]
> >>>  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 <[hidden email]
> >>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> >>>  [hidden email]>]
> >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> >>>  To: deltaspike
> >> <[hidden email]<mailto:[hidden email]
> >>>  >>
> >>>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

John D. Ament
In reply to this post by Mark Struberg-3
This approach makes sense to me.  But to my original question, is now a
good time to start thinking about straight Java EE 7 support and cutting
over to a 2.x mainline?

John

On Thu, Apr 7, 2016 at 9:25 AM Mark Struberg <[hidden email]> 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 <[hidden email]>
> 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.) <[hidden email]>:
> >
> >>  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:[hidden email]]
> >>  Sent: Thursday, April 07, 2016 7:13 AM
> >>  To: [hidden email]; [hidden email]
> >>  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 <[hidden email]
> >>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> >>  [hidden email]>]
> >>  Sent: Wednesday, April 6, 2016 10:14 PM
> >>  To: deltaspike
> > <[hidden email]<mailto:[hidden email]
> >>  >>
> >>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Gerhard Petracek-2
In reply to this post by John D. Ament
@john:
our ci-jobs are just about the basic compatibility with the different
versions of owb, weld and several (open-source-)ee-servers.
there are only few which test the basic compatibility with different
versions of the jdk explicitly (e.g. jdk8).
we never test against all jdk-releases (it's always a "random" release - we
just configure the major-version).
esp. with jdk7 we saw issues caused by different reasons with specific/old
versions of the jdk (in most cases one of the maven-plugins failed -> it
wasn't even ds itself).
-> we can never test all >jdk releases< in combination with all
cdi-implementations and ee-servers.

regards,
gerhard



2016-04-09 15:13 GMT+02:00 John D. Ament <[hidden email]>:

> 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 <[hidden email]> 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 <[hidden email]
> >
> > 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 <
> > [hidden email]> 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.) <[hidden email]>:
> > >>
> > >>>  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:[hidden email]]
> > >>>  Sent: Thursday, April 07, 2016 7:13 AM
> > >>>  To: [hidden email]; [hidden email]
> > >>>  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 <[hidden email]
> > >>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> > >>>  [hidden email]>]
> > >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> > >>>  To: deltaspike
> > >> <[hidden email]<mailto:[hidden email]
> > >>>  >>
> > >>>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

John D. Ament
@gerhard
So you're saying its coincidence that the Java 6 versions fail?

Basically, its not random releases.  Its the latest Java 6 supported by the
asf infra on Jenkins.

John

On Sat, Apr 9, 2016 at 3:42 PM Gerhard Petracek <[hidden email]>
wrote:

> @john:
> our ci-jobs are just about the basic compatibility with the different
> versions of owb, weld and several (open-source-)ee-servers.
> there are only few which test the basic compatibility with different
> versions of the jdk explicitly (e.g. jdk8).
> we never test against all jdk-releases (it's always a "random" release - we
> just configure the major-version).
> esp. with jdk7 we saw issues caused by different reasons with specific/old
> versions of the jdk (in most cases one of the maven-plugins failed -> it
> wasn't even ds itself).
> -> we can never test all >jdk releases< in combination with all
> cdi-implementations and ee-servers.
>
> regards,
> gerhard
>
>
>
> 2016-04-09 15:13 GMT+02:00 John D. Ament <[hidden email]>:
>
> > 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 <[hidden email]> 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
> <[hidden email]
> > >
> > > 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 <
> > > [hidden email]> 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.) <[hidden email]
> >:
> > > >>
> > > >>>  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:[hidden email]]
> > > >>>  Sent: Thursday, April 07, 2016 7:13 AM
> > > >>>  To: [hidden email]; [hidden email]
> > > >>>  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 <
> [hidden email]
> > > >>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> > > >>>  [hidden email]>]
> > > >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> > > >>>  To: deltaspike
> > > >> <[hidden email]<mailto:[hidden email]
> > > >>>  >>
> > > >>>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Gerhard Petracek
Administrator
@john:

if we have/keep one jdk6 based ci-job and it passes, it's as fine as our
current support of jdk8 (which is also checked by just one ci-job).
the rest is up to the ci-servers used for testing the different
cdi-implementations (and ee-servers).

@"latest version":
that's why i said "random". it depends on the concrete version available on
the ci-server/s (we don't control that on our own).

regards,
gerhard



2016-04-12 13:07 GMT+02:00 John D. Ament <[hidden email]>:

> @gerhard
> So you're saying its coincidence that the Java 6 versions fail?
>
> Basically, its not random releases.  Its the latest Java 6 supported by the
> asf infra on Jenkins.
>
> John
>
> On Sat, Apr 9, 2016 at 3:42 PM Gerhard Petracek <[hidden email]>
> wrote:
>
> > @john:
> > our ci-jobs are just about the basic compatibility with the different
> > versions of owb, weld and several (open-source-)ee-servers.
> > there are only few which test the basic compatibility with different
> > versions of the jdk explicitly (e.g. jdk8).
> > we never test against all jdk-releases (it's always a "random" release -
> we
> > just configure the major-version).
> > esp. with jdk7 we saw issues caused by different reasons with
> specific/old
> > versions of the jdk (in most cases one of the maven-plugins failed -> it
> > wasn't even ds itself).
> > -> we can never test all >jdk releases< in combination with all
> > cdi-implementations and ee-servers.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2016-04-09 15:13 GMT+02:00 John D. Ament <[hidden email]>:
> >
> > > 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 <[hidden email]>
> 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
> > <[hidden email]
> > > >
> > > > 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 <
> > > > [hidden email]> 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.) <
> [hidden email]
> > >:
> > > > >>
> > > > >>>  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:[hidden email]]
> > > > >>>  Sent: Thursday, April 07, 2016 7:13 AM
> > > > >>>  To: [hidden email]; [hidden email]
> > > > >>>  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 <
> > [hidden email]
> > > > >>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> > > > >>>  [hidden email]>]
> > > > >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> > > > >>>  To: deltaspike
> > > > >> <[hidden email]<mailto:[hidden email]
> > > > >>>  >>
> > > > >>>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Antoine Sabot-Durand
Beyond Java Level, I think we should start thinking about a CDI 1.2 / Java
EE 7 branch. JDK8 could be nice for this branch but we should make sure
that all Java EE 7 server out there run well on JDK 8

Antoine

Le mar. 12 avr. 2016 à 14:04, Gerhard Petracek <[hidden email]>
a écrit :

> @john:
>
> if we have/keep one jdk6 based ci-job and it passes, it's as fine as our
> current support of jdk8 (which is also checked by just one ci-job).
> the rest is up to the ci-servers used for testing the different
> cdi-implementations (and ee-servers).
>
> @"latest version":
> that's why i said "random". it depends on the concrete version available on
> the ci-server/s (we don't control that on our own).
>
> regards,
> gerhard
>
>
>
> 2016-04-12 13:07 GMT+02:00 John D. Ament <[hidden email]>:
>
> > @gerhard
> > So you're saying its coincidence that the Java 6 versions fail?
> >
> > Basically, its not random releases.  Its the latest Java 6 supported by
> the
> > asf infra on Jenkins.
> >
> > John
> >
> > On Sat, Apr 9, 2016 at 3:42 PM Gerhard Petracek <[hidden email]>
> > wrote:
> >
> > > @john:
> > > our ci-jobs are just about the basic compatibility with the different
> > > versions of owb, weld and several (open-source-)ee-servers.
> > > there are only few which test the basic compatibility with different
> > > versions of the jdk explicitly (e.g. jdk8).
> > > we never test against all jdk-releases (it's always a "random" release
> -
> > we
> > > just configure the major-version).
> > > esp. with jdk7 we saw issues caused by different reasons with
> > specific/old
> > > versions of the jdk (in most cases one of the maven-plugins failed ->
> it
> > > wasn't even ds itself).
> > > -> we can never test all >jdk releases< in combination with all
> > > cdi-implementations and ee-servers.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2016-04-09 15:13 GMT+02:00 John D. Ament <[hidden email]>:
> > >
> > > > 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 <[hidden email]>
> > 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
> > > <[hidden email]
> > > > >
> > > > > 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 <
> > > > > [hidden email]> 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.) <
> > [hidden email]
> > > >:
> > > > > >>
> > > > > >>>  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:[hidden email]]
> > > > > >>>  Sent: Thursday, April 07, 2016 7:13 AM
> > > > > >>>  To: [hidden email]; [hidden email]
> > > > > >>>  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 <
> > > [hidden email]
> > > > > >>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> > > > > >>>  [hidden email]>]
> > > > > >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> > > > > >>>  To: deltaspike
> > > > > >> <[hidden email]<mailto:[hidden email]
> > > > > >>>  >>
> > > > > >>>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Gerhard Petracek-2
@antoine:
we support cdi 1.1/1.2 and ee7 already (see [1]).

imo:
we just need to continue with ds2 once cdi2 is available.
for now we just need to improve our
documentation/examples/test-coverage/... + add useful features.

regards,
gerhard

[1]
http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201603.mbox/%3CCAGJtJfGTjx2vfqgr4LZgmmJg6eNT41DekeDoZU4bujurmubbrA%40mail.gmail.com%3E



2016-04-12 17:26 GMT+02:00 Antoine Sabot-Durand <[hidden email]>:

> Beyond Java Level, I think we should start thinking about a CDI 1.2 / Java
> EE 7 branch. JDK8 could be nice for this branch but we should make sure
> that all Java EE 7 server out there run well on JDK 8
>
> Antoine
>
> Le mar. 12 avr. 2016 à 14:04, Gerhard Petracek <[hidden email]
> >
> a écrit :
>
> > @john:
> >
> > if we have/keep one jdk6 based ci-job and it passes, it's as fine as our
> > current support of jdk8 (which is also checked by just one ci-job).
> > the rest is up to the ci-servers used for testing the different
> > cdi-implementations (and ee-servers).
> >
> > @"latest version":
> > that's why i said "random". it depends on the concrete version available
> on
> > the ci-server/s (we don't control that on our own).
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2016-04-12 13:07 GMT+02:00 John D. Ament <[hidden email]>:
> >
> > > @gerhard
> > > So you're saying its coincidence that the Java 6 versions fail?
> > >
> > > Basically, its not random releases.  Its the latest Java 6 supported by
> > the
> > > asf infra on Jenkins.
> > >
> > > John
> > >
> > > On Sat, Apr 9, 2016 at 3:42 PM Gerhard Petracek <[hidden email]>
> > > wrote:
> > >
> > > > @john:
> > > > our ci-jobs are just about the basic compatibility with the different
> > > > versions of owb, weld and several (open-source-)ee-servers.
> > > > there are only few which test the basic compatibility with different
> > > > versions of the jdk explicitly (e.g. jdk8).
> > > > we never test against all jdk-releases (it's always a "random"
> release
> > -
> > > we
> > > > just configure the major-version).
> > > > esp. with jdk7 we saw issues caused by different reasons with
> > > specific/old
> > > > versions of the jdk (in most cases one of the maven-plugins failed ->
> > it
> > > > wasn't even ds itself).
> > > > -> we can never test all >jdk releases< in combination with all
> > > > cdi-implementations and ee-servers.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2016-04-09 15:13 GMT+02:00 John D. Ament <[hidden email]>:
> > > >
> > > > > 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 <[hidden email]>
> > > 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
> > > > <[hidden email]
> > > > > >
> > > > > > 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 <
> > > > > > [hidden email]> 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.) <
> > > [hidden email]
> > > > >:
> > > > > > >>
> > > > > > >>>  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:[hidden email]]
> > > > > > >>>  Sent: Thursday, April 07, 2016 7:13 AM
> > > > > > >>>  To: [hidden email]; [hidden email]
> > > > > > >>>  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 <
> > > > [hidden email]
> > > > > > >>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> > > > > > >>>  [hidden email]>]
> > > > > > >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> > > > > > >>>  To: deltaspike
> > > > > > >> <[hidden email]<mailto:[hidden email]
> > > > > > >>>  >>
> > > > > > >>>  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 | Threaded
Open this post in threaded view
|

Re: Cutting over to Java 7

Thomas Andraschko-2
+1 gerhard
i don't see any big benefit to switch to any newer Java / JavaEE / CDI
until JavaEE8 / CDI 2.0.

2016-04-12 17:44 GMT+02:00 Gerhard Petracek <[hidden email]>:

> @antoine:
> we support cdi 1.1/1.2 and ee7 already (see [1]).
>
> imo:
> we just need to continue with ds2 once cdi2 is available.
> for now we just need to improve our
> documentation/examples/test-coverage/... + add useful features.
>
> regards,
> gerhard
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201603.mbox/%3CCAGJtJfGTjx2vfqgr4LZgmmJg6eNT41DekeDoZU4bujurmubbrA%40mail.gmail.com%3E
>
>
>
> 2016-04-12 17:26 GMT+02:00 Antoine Sabot-Durand <[hidden email]
> >:
>
> > Beyond Java Level, I think we should start thinking about a CDI 1.2 /
> Java
> > EE 7 branch. JDK8 could be nice for this branch but we should make sure
> > that all Java EE 7 server out there run well on JDK 8
> >
> > Antoine
> >
> > Le mar. 12 avr. 2016 à 14:04, Gerhard Petracek <
> [hidden email]
> > >
> > a écrit :
> >
> > > @john:
> > >
> > > if we have/keep one jdk6 based ci-job and it passes, it's as fine as
> our
> > > current support of jdk8 (which is also checked by just one ci-job).
> > > the rest is up to the ci-servers used for testing the different
> > > cdi-implementations (and ee-servers).
> > >
> > > @"latest version":
> > > that's why i said "random". it depends on the concrete version
> available
> > on
> > > the ci-server/s (we don't control that on our own).
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2016-04-12 13:07 GMT+02:00 John D. Ament <[hidden email]>:
> > >
> > > > @gerhard
> > > > So you're saying its coincidence that the Java 6 versions fail?
> > > >
> > > > Basically, its not random releases.  Its the latest Java 6 supported
> by
> > > the
> > > > asf infra on Jenkins.
> > > >
> > > > John
> > > >
> > > > On Sat, Apr 9, 2016 at 3:42 PM Gerhard Petracek <
> [hidden email]>
> > > > wrote:
> > > >
> > > > > @john:
> > > > > our ci-jobs are just about the basic compatibility with the
> different
> > > > > versions of owb, weld and several (open-source-)ee-servers.
> > > > > there are only few which test the basic compatibility with
> different
> > > > > versions of the jdk explicitly (e.g. jdk8).
> > > > > we never test against all jdk-releases (it's always a "random"
> > release
> > > -
> > > > we
> > > > > just configure the major-version).
> > > > > esp. with jdk7 we saw issues caused by different reasons with
> > > > specific/old
> > > > > versions of the jdk (in most cases one of the maven-plugins failed
> ->
> > > it
> > > > > wasn't even ds itself).
> > > > > -> we can never test all >jdk releases< in combination with all
> > > > > cdi-implementations and ee-servers.
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2016-04-09 15:13 GMT+02:00 John D. Ament <[hidden email]>:
> > > > >
> > > > > > 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 <[hidden email]
> >
> > > > 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
> > > > > <[hidden email]
> > > > > > >
> > > > > > > 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 <
> > > > > > > [hidden email]> 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.) <
> > > > [hidden email]
> > > > > >:
> > > > > > > >>
> > > > > > > >>>  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:[hidden email]]
> > > > > > > >>>  Sent: Thursday, April 07, 2016 7:13 AM
> > > > > > > >>>  To: [hidden email]; [hidden email]
> > > > > > > >>>  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 <
> > > > > [hidden email]
> > > > > > > >>>  <mailto:[hidden email]>> 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:[hidden email]<mailto:
> > > > > > > >>>  [hidden email]>]
> > > > > > > >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> > > > > > > >>>  To: deltaspike
> > > > > > > >> <[hidden email]<mailto:[hidden email]
> > > > > > > >>>  >>
> > > > > > > >>>  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
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>