[Proposal] Ending Support for Java 6

[Rob Godfrey <ro...@gmail.com>]

All,

now that Java 8 has been released, and Java 6 has been officially EOLd for
well over a year, I'd like to propose that we make 0.28 the last release
for which we officially support Java 6.  As a library provider I'm aware
that we need to strive to make our libraries as widely adoptable as
possible, but not adopting Java 7 also holds us back from implementing
functionality that requires features of later releases (as JMS 2.0 does).

Java 7 was released in 2011 and is itself scheduled to be EOLd next year.

If we do later find critical defects that affect the 0.28 release we should
consider back-patching to a Java 6 release based on 0.28, however I don't
think requiring that all new functionality releases require the adoption a
version of Java that Oracle supports to be an undue burden.

-- Rob

Re: [Proposal] Ending Support for Java 6

[Rob Godfrey <ro...@gmail.com>]

On 7 April 2014 20:30, Fraser Adams <fr...@blueyonder.co.uk> wrote:

> I think that this definitely needs input from the broad community.



Hence the mail :-)


> I can see where you're coming from, but my observations of large
> Enterprises (which TBH are often the main consumers of Messaging products)
> are that they are often in a difficult position wrt. keeping up with the
> times. Don't talk to me about IE8 for example!! There's a whole *industry*
> of polyfills because Enterprises won't or can't upgrade.
>
>
Indeed - however as Robbie says the same pressures apply to (for instance)
the versions of messaging software that are used.  People inside large
organisations may be using versions of Qpid that we released two years ago
and find it difficult to upgrade... they may only get round to adopting
0.28 in 2016 :-)

I think we need to draw a distinction between support bug/fixing and new
features.  As I said in my original mail, if a critical defect is found in
a release <= 0.28 then I definitely think we should look at backporting to
a branch off 0.28 for those who are stuck on Java 6... However supporting
Java 6 for new feature releases means (in my mind) continuing to support
Java 6 for two or so more years after the software has been released for
such users.


I don't think that your comment "Those those who 'cant' or don't want to
> upgrade to such 'new' (i.e really quite old now) Java releases are often
> likely to be the same ones that aren't so likely to use the latest Qpid
> releases either" necessarily holds, often things like compiler versions get
> corporately mandated whereas there might be less control exerted on
> libraries. I've got painful memories of being stuck on Java 3 when the
> world had moved to Java 5, this stuff is not as simple as you seem to think.
>
> I'm quite impressed that your own organisation has migrated to Java 7
>
>
There are people in my organisation who are still using 1.3 (I wouldn't be
shocked if there is still some 1.2 somewhere)... however that doesn't mean
I think they should be encouraged ;-)

Ending support does not mean we tell people who are using EOLd versions of
Java that we won't do anything unless they upgrade.  It just means that for
new feature development we're not going to test that it still compiles/runs
under 6.  Usually there is more of an issue with Java versions for the
client library than the broker since the client library may be being
dropped into an already existing application which cannot be migrated...
however I think that's more of an argument for saying we should have moved
the broker to 7 ages ago, than to delay any further the use of 7 for *new*
versions of the client.


>
> I'm *personally* fairly agnostic on this I just think that it's important
> to bear in mind how large Enterprises often operate.
>
> (Lack of) what features are causing you the most pain? Just curious
> really. Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all
> familiar with JMS 2.0, so I'm interested what key things have changed and
> what new stuff it depends on. Is the implication of this that the new AMQP
> 1.0 JMS client that you guys are working on will be JMS 2.0 only? I noticed
> that the pom.xml in there specifies Java 7 already - I guess that's your
> none to subtle hint ;->
>

JMS 2.0 uses try-with-resource I believe which requires new definitions
only available in Java 7 and up.

What currently causes me pain (though not what is motivating this change)
is that even for syntax which should be common to both 6 and 7, the
compilers behave differently (see some of my trials with generic lately,
where code that compiles on 6 does not on 7 and vice versa - even though
the generated class files would run on both)... which means that every
piece of code theoretically needs to be tested against compilers for both
versions (which is awkward for 6 these days).  It is also difficult to
ensure that use of classes / methods new in the 1.7 libraries does not
accidentally sneak in as even setting the target version on the compiler
does not catch this.

Feature wise there's really not *that* much in Java 7 - being able to use
Java 8 would be much nicer... but that's not going to happen for years
sadly :-(  There are a few things around file handling that would be nice
to tidy up in the broker, but other than that it's more about not having to
compile and test everything twice.


> Hmm you could probably make similar arguments for adopting C++11 - not
> least because Boost version dependencies suck, but there are still a ton of
> people (myself included at the moment) with older systems - though to be
> fair upgrading C++ compilers tends to be harder than upgrading Java
> versions for any given OS version. It's interesting that Proton (well
> Proton-C at any rate) seems to be taking a very different tack where it
> seems to be actively trying to minimise dependencies on anything new and
> shiny - I'm pretty sure I saw a Jira the other day for changing send.c and
> recv.c because they were C99 and broke on Windows builds that needed good
> old C89 :-D
>
>
I think the situation in C/C++ is somewhat different in that there is not
(to my knowledge) an explicit EOL policy from the vendor of the language...
nor does C/C++ encompass the runtime environment.


> Just being a bit Devils' advocate to mix things up a bit, as I say I'm
> personally agnostic :-)
>
>
Personally I think holding off for over a year after the version Java
Runtime Environment has been EOLd is reasonable.  As above, it's not like
0.28 (or earlier versions) are going to disappear from the internet.
 People deploying new software now really should (even within large
organisations with Java support contracts) be using Java 7.  People stuck
on Java 6 still have versions that work for them (and if they don't work we
can provide a fix).

Historically we have dropped support for Java 5 (and what limited support
we had for Java 4) in a similar manner.

-- Rob


> Frase
>
>
>
> On 07/04/14 17:33, Robbie Gemmell wrote:
>
>> I think this makes sense. We waited too long to drop support for Java 5,
>> lets not repeat that with 6. Beginning to depend on Java 7 after three
>> years doesnt seem unreasonable to me.
>>
>> Those those who 'cant' or dont want to upgrade to such 'new' (i.e really
>> quite old now) Java releases are often likely to be the same ones that
>> aren't so likely to use the latest Qpid releases either.
>>
>> Robbie
>>
>> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
>>
>>  All,
>>>
>>> now that Java 8 has been released, and Java 6 has been officially EOLd
>>> for
>>> well over a year, I'd like to propose that we make 0.28 the last release
>>> for which we officially support Java 6.  As a library provider I'm aware
>>> that we need to strive to make our libraries as widely adoptable as
>>> possible, but not adopting Java 7 also holds us back from implementing
>>> functionality that requires features of later releases (as JMS 2.0 does).
>>>
>>> Java 7 was released in 2011 and is itself scheduled to be EOLd next year.
>>>
>>> If we do later find critical defects that affect the 0.28 release we
>>> should
>>> consider back-patching to a Java 6 release based on 0.28, however I don't
>>> think requiring that all new functionality releases require the adoption
>>> a
>>> version of Java that Oracle supports to be an undue burden.
>>>
>>> -- Rob
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: [Proposal] Ending Support for Java 6

[Rob Godfrey <ro...@gmail.com>]

What would the purpose of this be?  With the build system changes we are
getting developers ready to use a new different environment, testing that
the build generates the same output, etc...  I think the change from Java 6
to Java 7 is hardly of the same nature.  We've already been running
"parallel builds" for years.

With Java we're not changing how the build works (well we are - but that's
the maven change :-) ), only saying that from now on we're not guaranteeing
to support that the latest code will compile/run on a JVM neither Oracle
(nor anyone else to my knowledge) supports... Are we expecting to deliver
some key features in the next couple of releases that will be vital for
Java 6 holdouts to adopt?  Otherwise what difference does it make to a user
who is stuck on Java 6 - at some point we are going to switch over and the
only difference for them is going to be what new functionality is available
only in a release which may not work on their system.

Again, I reiterate "ending support" only means that we won't be
guaranteeing that new releases with new features will work on Java 6.  If
someone comes to the user list and asks a question about version 0.28 on
Java 6, then we'll still be supporting them.  If someone finds a bug in
0.28 and there is no workaround, they can't move to Java 7,  then I'd
definitely look very favourably on releasing a patch release off 0.28.  In
practice I very much expect that the client and common code will still
compile in Java 6, but we will no longer be forced to run unsupported Java
environments on our systems nor to test against three major release of Java
for every checkin that we do.

-- Rob




On 10 April 2014 20:03, Fraser Adams <fr...@blueyonder.co.uk> wrote:

> From a *really parochial* perspective I've done a straw poll of my
> organisation and was astonished to find we're more or less ahead of the
> curve :-D
>
> from a personal perspective, as I said earlier I'm largely agnostic
>
> I am however a bit disappointed by the lack of response on this thread,
> though perhaps silence is simply acceptance? I guess that I also can't help
> but wonder that we ended up going through a couple of releases before we
> properly killed off the automake builds by providing some "persuaders"
> because that seemed like the right thing to do.
>
> I think if I were being conservative/user friendly my preferred option
> might be (now that the maven work is in 0.28) to make the Maven build use
> Java 7 (you might have already done this I haven't checked) and to have a
> *visible* deprecation notice appear at the end of the ant build to say that
> this is intended to be the last ant/Java 6 supported version and provide a
> link to the user list with a note for users to raise issues if moving to
> Maven/Java 7 is a problem for them.
>
> That at least gives fair warning for people who may not read the user list.
>
> I think also holding fire on any code changes with an *absolute
> dependency* on Java 7 until closer to 0.30 release time to give 0.28 users
> who have issues with moving to Java 6 enough time to flag up concerns.
>
> I won't down vote it you don't want to do this and nobody else objects,
> but I do think that it's the friendly thing to do.
>
> Frase
>
>
>
> On 09/04/14 21:51, Rob Godfrey wrote:
>
>> Just bumping this thread again - does anyone have any objections... I'd
>> plan on moving forward with switching the builds to 1.7 sometime next
>> week if we haven't heard any by then
>>
>> -- Rob
>>
>>
>> On 8 April 2014 00:02, Robbie Gemmell <ro...@gmail.com> wrote:
>>
>>  On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk>
>>> wrote:
>>>
>>>  I think that this definitely needs input from the broad community. I can
>>>> see where you're coming from, but my observations of large Enterprises
>>>> (which TBH are often the main consumers of Messaging products) are that
>>>> they are often in a difficult position wrt. keeping up with the times.
>>>> Don't talk to me about IE8 for example!! There's a whole *industry* of
>>>> polyfills because Enterprises won't or can't upgrade.
>>>>
>>>>  I dont necessarily think IE8 is a comparable situation to a Java
>>> version
>>> change, but I do take your point.
>>>
>>>
>>>  I don't think that your comment "Those those who 'cant' or dont want to
>>>> upgrade to such 'new' (i.e really quite old now) Java releases are often
>>>> likely to be the same ones that aren't so likely to use the latest Qpid
>>>> releases either" necessarily holds, often things like compiler versions
>>>>
>>> get
>>>
>>>> corporately mandated whereas there might be less control exerted on
>>>> libraries. I've got painful memories of being stuck on Java 3 when the
>>>> world had moved to Java 5, this stuff is not as simple as you seem to
>>>>
>>> think.
>>> I agree that there is often more control (and as a result, lack thereof
>>> for
>>> the users) exercised over the platform than the things running on it,
>>> but I
>>> would also say that my experience has been that the two things drift
>>> together to an extent as time passes, and the controlled platform leads
>>> people to stop upgrading the things running on it as it gets older, even
>>> when they could still do so.
>>>
>>> I do realise its not always that simple on the client side, but on the
>>> broker side for example it isnt necessarily that hard, there are ways to
>>> handle that in isolation if really required. Obviously if you rule those
>>> options out you need to have a plan in place to cope with the result of
>>> those decisions (where hoping we are super nice isnt really a plan).
>>>
>>>
>>>  I'm quite impressed that your own organisation has migrated to Java 7
>>>>
>>>>
>>>> I'm *personally* fairly agnostic on this I just think that it's
>>>> important
>>>> to bear in mind how large Enterprises often operate.
>>>>
>>>>  I unfortunately would say I spend too much of my time bearing in mind
>>> how
>>> they do hehe. Its certainly getting my own personal consideration, an is
>>> actually one of the main reasons I support the proposal.
>>>
>>> I know there are people that wont pick such new stuff up until several
>>> months or years after it is released, at which point I dont really think
>>> its a good thing to see them still able to deploy it on the Java 6 JVM
>>> they
>>> should have looked to stop using by then nevermind trying to use it for a
>>> couple further years :)
>>>
>>>
>>>  (Lack of) what features are causing you the most pain? Just curious
>>>> really.
>>>>
>>>
>>> It isnt necessarily just about features (though there are certainly some
>>> I'd like to be able to rely on, and not necessarily even at the language
>>> level), eventual supportability also comes into it for me. If noone is
>>> supporting those JVMs on the other end, and we dont really have the
>>> bandwidth to do so either, is letting new stuff continue to run on them
>>> when noone is testing/fixing the result really such a good thing?  (Hello
>>> Windows XP, I hear tomorrow is your deathday...please tell your users)
>>>
>>> Supporting things far beyond their own EOL date feels a bit like jumping
>>> in
>>> beside someone digging themselves into a hole to lend them an extra pair
>>> of
>>> hands to speed things up :)
>>>
>>>
>>>  Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar
>>>> with
>>>> JMS 2.0, so I'm interested what key things have changed and what new
>>>>
>>> stuff
>>>
>>>> it depends on. Is the implication of this that the new AMQP 1.0 JMS
>>>>
>>> client
>>>
>>>> that you guys are working on will be JMS 2.0 only? I noticed that the
>>>> pom.xml in there specifies Java 7 already - I guess that's your none to
>>>> subtle hint ;->
>>>>
>>>>
>>>>  It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom isnt a
>>> hint
>>> but rather a requirement; as Rob mentioned the JMS 2.0 API make use of
>>> the
>>> try-with-resources language feature, which is strictly Java7+
>>>
>>> (obviously that isnt to say you can't do things like hack the bytecode
>>> after the fact to make it work with Java 6, but...lets not get crazy)
>>>
>>>
>>>  Hmm you could probably make similar arguments for adopting C++11 - not
>>>> least because Boost version dependencies suck, but there are still a ton
>>>>
>>> of
>>>
>>>> people (myself included at the moment) with older systems - though to be
>>>> fair upgrading C++ compilers tends to be harder than upgrading Java
>>>> versions for any given OS version.
>>>>
>>>
>>> Especially if you arent talking about package manager installations. One
>>> is
>>> really really easy, is the other? :)
>>>
>>>
>>>  It's interesting that Proton (well Proton-C at any rate) seems to be
>>>> taking a very different tack where it seems to be actively trying to
>>>> minimise dependencies on anything new and shiny - I'm pretty sure I saw
>>>> a
>>>> Jira the other day for changing send.c and recv.c because they were C99
>>>>
>>> and
>>>
>>>> broke on Windows builds that needed good old C89 :-D
>>>>
>>>> Just being a bit Devils' advocate to mix things up a bit, as I say I'm
>>>> personally agnostic :-)
>>>>
>>>> Frase
>>>>
>>>>
>>>>
>>>> On 07/04/14 17:33, Robbie Gemmell wrote:
>>>>
>>>>  I think this makes sense. We waited too long to drop support for Java
>>>>> 5,
>>>>> lets not repeat that with 6. Beginning to depend on Java 7 after three
>>>>> years doesnt seem unreasonable to me.
>>>>>
>>>>> Those those who 'cant' or dont want to upgrade to such 'new' (i.e
>>>>> really
>>>>> quite old now) Java releases are often likely to be the same ones that
>>>>> aren't so likely to use the latest Qpid releases either.
>>>>>
>>>>> Robbie
>>>>>
>>>>> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
>>>>>
>>>>>   All,
>>>>>
>>>>>> now that Java 8 has been released, and Java 6 has been officially EOLd
>>>>>> for
>>>>>> well over a year, I'd like to propose that we make 0.28 the last
>>>>>>
>>>>> release
>>>
>>>> for which we officially support Java 6.  As a library provider I'm
>>>>>>
>>>>> aware
>>>
>>>> that we need to strive to make our libraries as widely adoptable as
>>>>>> possible, but not adopting Java 7 also holds us back from implementing
>>>>>> functionality that requires features of later releases (as JMS 2.0
>>>>>>
>>>>> does).
>>>
>>>> Java 7 was released in 2011 and is itself scheduled to be EOLd next
>>>>>>
>>>>> year.
>>>
>>>> If we do later find critical defects that affect the 0.28 release we
>>>>>> should
>>>>>> consider back-patching to a Java 6 release based on 0.28, however I
>>>>>>
>>>>> don't
>>>
>>>> think requiring that all new functionality releases require the
>>>>>>
>>>>> adoption
>>>
>>>> a
>>>>>> version of Java that Oracle supports to be an undue burden.
>>>>>>
>>>>>> -- Rob
>>>>>>
>>>>>>
>>>>>>  ------------------------------------------------------------
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: [Proposal] Ending Support for Java 6

[Justin Ross <jr...@apache.org>]

On Thu, Apr 10, 2014 at 2:03 PM, Fraser Adams <fraser.adams@blueyonder.co.uk
> wrote:

> I am however a bit disappointed by the lack of response on this thread,
> though perhaps silence is simply acceptance? I guess that I also can't help
> but wonder that we ended up going through a couple of releases before we
> properly killed off the automake builds by providing some "persuaders"
> because that seemed like the right thing to do.
>

For the environments that I deal with, RHEL and Fedora, a Java 7
requirement is okay.  I don't know enough about other distros or ad-hoc
Java environments to say whether this is a big deal.  I went looking for
info about Java-version market share and didn't find much that seemed
reliable.  Does anyone have anything like that?

Re: [Proposal] Ending Support for Java 6

[Andrew MacBean <an...@gmail.com>]

This seems very sensible proposal and makes allot of sense.

Like you have said, we are only saying we wont guarantee compatibility but
aren't going to leave people stuck if they are restricted so hard top argue
with.

Andrew


On 10 April 2014 21:10, Fraser Adams <fr...@blueyonder.co.uk> wrote:

> All fair enough comments Robbie, but at least I prompted a bit more
> discussion :-D
>
> F.
>
>
>
> On 10/04/14 20:25, Robbie Gemmell wrote:
>
>> On 10 April 2014 19:03, Fraser Adams <fr...@blueyonder.co.uk>
>> wrote:
>>
>>   From a *really parochial* perspective I've done a straw poll of my
>>> organisation and was astonished to find we're more or less ahead of the
>>> curve :-D
>>>
>>>
>>>  With all the recent security related issues, I've found that the people
>> who
>> are inclined to ever upgrade tend to do a better job of it now...and the
>> rest are running versions of <JavaThing> so old they can still use it on
>> Java 5 if they really want and at this point we are just discussing things
>> they'd consider mythical ;)
>>
>>
>>  from a personal perspective, as I said earlier I'm largely agnostic
>>>
>>> I am however a bit disappointed by the lack of response on this thread,
>>> though perhaps silence is simply acceptance?
>>>
>>
>> Possibly. For many of us Java 6 is just already considered archaic. Fedora
>> 21 for example (which is admittedly not due out until August+) is
>> apparently looking to remove Java 7 and move to Java 8 by default.
>>
>>
>> I guess that I also can't help but wonder that we ended up going through a
>>
>>> couple of releases before we properly killed off the automake builds by
>>> providing some "persuaders" because that seemed like the right thing to
>>> do.
>>>
>>>
>>>  I think that one is a little different for a couple of reasons:
>> - Changing back to an earlier Java compiler and class version for
>> compilation is easier (basically update a property, which can be done via
>> the command line) than migrating between C++ build systems at short notice
>> - I expect significantly fewer users actually build the Java bits
>> themselves versus the C++ bits, because theyll typically consume the
>> binaries.
>>
>> I think if I were being conservative/user friendly my preferred option
>>
>>> might be (now that the maven work is in 0.28) to make the Maven build use
>>> Java 7 (you might have already done this I haven't checked) and to have a
>>> *visible* deprecation notice appear at the end of the ant build to say
>>> that
>>> this is intended to be the last ant/Java 6 supported version and provide
>>> a
>>> link to the user list with a note for users to raise issues if moving to
>>> Maven/Java 7 is a problem for them.
>>>
>>>  I'd be happy enough putting a deprecation notice into the Ant build when
>> appropriate, but I would prefer the two builds to always output
>> essentially
>> the same things while they both exist. As mentioned earlier, if someone
>> really needs to change it back to compile for Java 6 it is going to be
>> rather easy for them to do so.
>>
>>
>>  That at least gives fair warning for people who may not read the user
>>> list.
>>>
>>> I think also holding fire on any code changes with an *absolute
>>> dependency* on Java 7 until closer to 0.30 release time to give 0.28
>>> users
>>> who have issues with moving to Java 6 enough time to flag up concerns.
>>>
>>> I won't down vote it you don't want to do this and nobody else objects,
>>> but I do think that it's the friendly thing to do.
>>>
>>> Frase
>>>
>>>
>>>
>>> On 09/04/14 21:51, Rob Godfrey wrote:
>>>
>>>  Just bumping this thread again - does anyone have any objections... I'd
>>>> plan on moving forward with switching the builds to 1.7 sometime next
>>>> week if we haven't heard any by then
>>>>
>>>> -- Rob
>>>>
>>>>
>>>> On 8 April 2014 00:02, Robbie Gemmell <ro...@gmail.com> wrote:
>>>>
>>>>   On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk>
>>>>
>>>>> wrote:
>>>>>
>>>>>   I think that this definitely needs input from the broad community. I
>>>>> can
>>>>>
>>>>>> see where you're coming from, but my observations of large Enterprises
>>>>>> (which TBH are often the main consumers of Messaging products) are
>>>>>> that
>>>>>> they are often in a difficult position wrt. keeping up with the times.
>>>>>> Don't talk to me about IE8 for example!! There's a whole *industry* of
>>>>>> polyfills because Enterprises won't or can't upgrade.
>>>>>>
>>>>>>   I dont necessarily think IE8 is a comparable situation to a Java
>>>>>>
>>>>> version
>>>>> change, but I do take your point.
>>>>>
>>>>>
>>>>>   I don't think that your comment "Those those who 'cant' or dont want
>>>>> to
>>>>>
>>>>>> upgrade to such 'new' (i.e really quite old now) Java releases are
>>>>>> often
>>>>>> likely to be the same ones that aren't so likely to use the latest
>>>>>> Qpid
>>>>>> releases either" necessarily holds, often things like compiler
>>>>>> versions
>>>>>>
>>>>>>  get
>>>>>
>>>>>  corporately mandated whereas there might be less control exerted on
>>>>>> libraries. I've got painful memories of being stuck on Java 3 when the
>>>>>> world had moved to Java 5, this stuff is not as simple as you seem to
>>>>>>
>>>>>>  think.
>>>>> I agree that there is often more control (and as a result, lack thereof
>>>>> for
>>>>> the users) exercised over the platform than the things running on it,
>>>>> but I
>>>>> would also say that my experience has been that the two things drift
>>>>> together to an extent as time passes, and the controlled platform leads
>>>>> people to stop upgrading the things running on it as it gets older,
>>>>> even
>>>>> when they could still do so.
>>>>>
>>>>> I do realise its not always that simple on the client side, but on the
>>>>> broker side for example it isnt necessarily that hard, there are ways
>>>>> to
>>>>> handle that in isolation if really required. Obviously if you rule
>>>>> those
>>>>> options out you need to have a plan in place to cope with the result of
>>>>> those decisions (where hoping we are super nice isnt really a plan).
>>>>>
>>>>>
>>>>>   I'm quite impressed that your own organisation has migrated to Java 7
>>>>>
>>>>>>
>>>>>> I'm *personally* fairly agnostic on this I just think that it's
>>>>>> important
>>>>>> to bear in mind how large Enterprises often operate.
>>>>>>
>>>>>>   I unfortunately would say I spend too much of my time bearing in
>>>>>> mind
>>>>>>
>>>>> how
>>>>> they do hehe. Its certainly getting my own personal consideration, an
>>>>> is
>>>>> actually one of the main reasons I support the proposal.
>>>>>
>>>>> I know there are people that wont pick such new stuff up until several
>>>>> months or years after it is released, at which point I dont really
>>>>> think
>>>>> its a good thing to see them still able to deploy it on the Java 6 JVM
>>>>> they
>>>>> should have looked to stop using by then nevermind trying to use it
>>>>> for a
>>>>> couple further years :)
>>>>>
>>>>>
>>>>>   (Lack of) what features are causing you the most pain? Just curious
>>>>>
>>>>>> really.
>>>>>>
>>>>>>  It isnt necessarily just about features (though there are certainly
>>>>> some
>>>>> I'd like to be able to rely on, and not necessarily even at the
>>>>> language
>>>>> level), eventual supportability also comes into it for me. If noone is
>>>>> supporting those JVMs on the other end, and we dont really have the
>>>>> bandwidth to do so either, is letting new stuff continue to run on them
>>>>> when noone is testing/fixing the result really such a good thing?
>>>>>  (Hello
>>>>> Windows XP, I hear tomorrow is your deathday...please tell your users)
>>>>>
>>>>> Supporting things far beyond their own EOL date feels a bit like
>>>>> jumping
>>>>> in
>>>>> beside someone digging themselves into a hole to lend them an extra
>>>>> pair
>>>>> of
>>>>> hands to speed things up :)
>>>>>
>>>>>
>>>>>   Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar
>>>>>
>>>>>> with
>>>>>> JMS 2.0, so I'm interested what key things have changed and what new
>>>>>>
>>>>>>  stuff
>>>>>
>>>>>  it depends on. Is the implication of this that the new AMQP 1.0 JMS
>>>>>>
>>>>>>  client
>>>>>
>>>>>  that you guys are working on will be JMS 2.0 only? I noticed that the
>>>>>> pom.xml in there specifies Java 7 already - I guess that's your none
>>>>>> to
>>>>>> subtle hint ;->
>>>>>>
>>>>>>
>>>>>>   It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom
>>>>>> isnt a
>>>>>>
>>>>> hint
>>>>> but rather a requirement; as Rob mentioned the JMS 2.0 API make use of
>>>>> the
>>>>> try-with-resources language feature, which is strictly Java7+
>>>>>
>>>>> (obviously that isnt to say you can't do things like hack the bytecode
>>>>> after the fact to make it work with Java 6, but...lets not get crazy)
>>>>>
>>>>>
>>>>>   Hmm you could probably make similar arguments for adopting C++11 -
>>>>> not
>>>>>
>>>>>> least because Boost version dependencies suck, but there are still a
>>>>>> ton
>>>>>>
>>>>>>  of
>>>>>
>>>>>  people (myself included at the moment) with older systems - though to
>>>>>> be
>>>>>> fair upgrading C++ compilers tends to be harder than upgrading Java
>>>>>> versions for any given OS version.
>>>>>>
>>>>>>  Especially if you arent talking about package manager installations.
>>>>> One
>>>>> is
>>>>> really really easy, is the other? :)
>>>>>
>>>>>
>>>>>   It's interesting that Proton (well Proton-C at any rate) seems to be
>>>>>
>>>>>> taking a very different tack where it seems to be actively trying to
>>>>>> minimise dependencies on anything new and shiny - I'm pretty sure I
>>>>>> saw
>>>>>> a
>>>>>> Jira the other day for changing send.c and recv.c because they were
>>>>>> C99
>>>>>>
>>>>>>  and
>>>>>
>>>>>  broke on Windows builds that needed good old C89 :-D
>>>>>>
>>>>>> Just being a bit Devils' advocate to mix things up a bit, as I say I'm
>>>>>> personally agnostic :-)
>>>>>>
>>>>>> Frase
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 07/04/14 17:33, Robbie Gemmell wrote:
>>>>>>
>>>>>>   I think this makes sense. We waited too long to drop support for
>>>>>> Java
>>>>>>
>>>>>>> 5,
>>>>>>> lets not repeat that with 6. Beginning to depend on Java 7 after
>>>>>>> three
>>>>>>> years doesnt seem unreasonable to me.
>>>>>>>
>>>>>>> Those those who 'cant' or dont want to upgrade to such 'new' (i.e
>>>>>>> really
>>>>>>> quite old now) Java releases are often likely to be the same ones
>>>>>>> that
>>>>>>> aren't so likely to use the latest Qpid releases either.
>>>>>>>
>>>>>>> Robbie
>>>>>>>
>>>>>>> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
>>>>>>>
>>>>>>>    All,
>>>>>>>
>>>>>>>  now that Java 8 has been released, and Java 6 has been officially
>>>>>>>> EOLd
>>>>>>>> for
>>>>>>>> well over a year, I'd like to propose that we make 0.28 the last
>>>>>>>>
>>>>>>>>  release
>>>>>>>
>>>>>> for which we officially support Java 6.  As a library provider I'm
>>>>>>
>>>>>>> aware
>>>>>>>
>>>>>> that we need to strive to make our libraries as widely adoptable as
>>>>>>
>>>>>>> possible, but not adopting Java 7 also holds us back from
>>>>>>>> implementing
>>>>>>>> functionality that requires features of later releases (as JMS 2.0
>>>>>>>>
>>>>>>>>  does).
>>>>>>>
>>>>>> Java 7 was released in 2011 and is itself scheduled to be EOLd next
>>>>>>
>>>>>>> year.
>>>>>>>
>>>>>> If we do later find critical defects that affect the 0.28 release we
>>>>>>
>>>>>>> should
>>>>>>>> consider back-patching to a Java 6 release based on 0.28, however I
>>>>>>>>
>>>>>>>>  don't
>>>>>>>
>>>>>> think requiring that all new functionality releases require the
>>>>>>
>>>>>>> adoption
>>>>>>>
>>>>>> a
>>>>>>
>>>>>>> version of Java that Oracle supports to be an undue burden.
>>>>>>>>
>>>>>>>> -- Rob
>>>>>>>>
>>>>>>>>
>>>>>>>>   ------------------------------------------------------------
>>>>>>>>
>>>>>>> ---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>  ------------------------------------------------------------
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: [Proposal] Ending Support for Java 6

[Fraser Adams <fr...@blueyonder.co.uk>]

All fair enough comments Robbie, but at least I prompted a bit more 
discussion :-D

F.


On 10/04/14 20:25, Robbie Gemmell wrote:
> On 10 April 2014 19:03, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
>>  From a *really parochial* perspective I've done a straw poll of my
>> organisation and was astonished to find we're more or less ahead of the
>> curve :-D
>>
>>
> With all the recent security related issues, I've found that the people who
> are inclined to ever upgrade tend to do a better job of it now...and the
> rest are running versions of <JavaThing> so old they can still use it on
> Java 5 if they really want and at this point we are just discussing things
> they'd consider mythical ;)
>
>
>> from a personal perspective, as I said earlier I'm largely agnostic
>>
>> I am however a bit disappointed by the lack of response on this thread,
>> though perhaps silence is simply acceptance?
>
> Possibly. For many of us Java 6 is just already considered archaic. Fedora
> 21 for example (which is admittedly not due out until August+) is
> apparently looking to remove Java 7 and move to Java 8 by default.
>
>
> I guess that I also can't help but wonder that we ended up going through a
>> couple of releases before we properly killed off the automake builds by
>> providing some "persuaders" because that seemed like the right thing to do.
>>
>>
> I think that one is a little different for a couple of reasons:
> - Changing back to an earlier Java compiler and class version for
> compilation is easier (basically update a property, which can be done via
> the command line) than migrating between C++ build systems at short notice
> - I expect significantly fewer users actually build the Java bits
> themselves versus the C++ bits, because theyll typically consume the
> binaries.
>
> I think if I were being conservative/user friendly my preferred option
>> might be (now that the maven work is in 0.28) to make the Maven build use
>> Java 7 (you might have already done this I haven't checked) and to have a
>> *visible* deprecation notice appear at the end of the ant build to say that
>> this is intended to be the last ant/Java 6 supported version and provide a
>> link to the user list with a note for users to raise issues if moving to
>> Maven/Java 7 is a problem for them.
>>
> I'd be happy enough putting a deprecation notice into the Ant build when
> appropriate, but I would prefer the two builds to always output essentially
> the same things while they both exist. As mentioned earlier, if someone
> really needs to change it back to compile for Java 6 it is going to be
> rather easy for them to do so.
>
>
>> That at least gives fair warning for people who may not read the user list.
>>
>> I think also holding fire on any code changes with an *absolute
>> dependency* on Java 7 until closer to 0.30 release time to give 0.28 users
>> who have issues with moving to Java 6 enough time to flag up concerns.
>>
>> I won't down vote it you don't want to do this and nobody else objects,
>> but I do think that it's the friendly thing to do.
>>
>> Frase
>>
>>
>>
>> On 09/04/14 21:51, Rob Godfrey wrote:
>>
>>> Just bumping this thread again - does anyone have any objections... I'd
>>> plan on moving forward with switching the builds to 1.7 sometime next
>>> week if we haven't heard any by then
>>>
>>> -- Rob
>>>
>>>
>>> On 8 April 2014 00:02, Robbie Gemmell <ro...@gmail.com> wrote:
>>>
>>>   On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk>
>>>> wrote:
>>>>
>>>>   I think that this definitely needs input from the broad community. I can
>>>>> see where you're coming from, but my observations of large Enterprises
>>>>> (which TBH are often the main consumers of Messaging products) are that
>>>>> they are often in a difficult position wrt. keeping up with the times.
>>>>> Don't talk to me about IE8 for example!! There's a whole *industry* of
>>>>> polyfills because Enterprises won't or can't upgrade.
>>>>>
>>>>>   I dont necessarily think IE8 is a comparable situation to a Java
>>>> version
>>>> change, but I do take your point.
>>>>
>>>>
>>>>   I don't think that your comment "Those those who 'cant' or dont want to
>>>>> upgrade to such 'new' (i.e really quite old now) Java releases are often
>>>>> likely to be the same ones that aren't so likely to use the latest Qpid
>>>>> releases either" necessarily holds, often things like compiler versions
>>>>>
>>>> get
>>>>
>>>>> corporately mandated whereas there might be less control exerted on
>>>>> libraries. I've got painful memories of being stuck on Java 3 when the
>>>>> world had moved to Java 5, this stuff is not as simple as you seem to
>>>>>
>>>> think.
>>>> I agree that there is often more control (and as a result, lack thereof
>>>> for
>>>> the users) exercised over the platform than the things running on it,
>>>> but I
>>>> would also say that my experience has been that the two things drift
>>>> together to an extent as time passes, and the controlled platform leads
>>>> people to stop upgrading the things running on it as it gets older, even
>>>> when they could still do so.
>>>>
>>>> I do realise its not always that simple on the client side, but on the
>>>> broker side for example it isnt necessarily that hard, there are ways to
>>>> handle that in isolation if really required. Obviously if you rule those
>>>> options out you need to have a plan in place to cope with the result of
>>>> those decisions (where hoping we are super nice isnt really a plan).
>>>>
>>>>
>>>>   I'm quite impressed that your own organisation has migrated to Java 7
>>>>>
>>>>> I'm *personally* fairly agnostic on this I just think that it's
>>>>> important
>>>>> to bear in mind how large Enterprises often operate.
>>>>>
>>>>>   I unfortunately would say I spend too much of my time bearing in mind
>>>> how
>>>> they do hehe. Its certainly getting my own personal consideration, an is
>>>> actually one of the main reasons I support the proposal.
>>>>
>>>> I know there are people that wont pick such new stuff up until several
>>>> months or years after it is released, at which point I dont really think
>>>> its a good thing to see them still able to deploy it on the Java 6 JVM
>>>> they
>>>> should have looked to stop using by then nevermind trying to use it for a
>>>> couple further years :)
>>>>
>>>>
>>>>   (Lack of) what features are causing you the most pain? Just curious
>>>>> really.
>>>>>
>>>> It isnt necessarily just about features (though there are certainly some
>>>> I'd like to be able to rely on, and not necessarily even at the language
>>>> level), eventual supportability also comes into it for me. If noone is
>>>> supporting those JVMs on the other end, and we dont really have the
>>>> bandwidth to do so either, is letting new stuff continue to run on them
>>>> when noone is testing/fixing the result really such a good thing?  (Hello
>>>> Windows XP, I hear tomorrow is your deathday...please tell your users)
>>>>
>>>> Supporting things far beyond their own EOL date feels a bit like jumping
>>>> in
>>>> beside someone digging themselves into a hole to lend them an extra pair
>>>> of
>>>> hands to speed things up :)
>>>>
>>>>
>>>>   Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar
>>>>> with
>>>>> JMS 2.0, so I'm interested what key things have changed and what new
>>>>>
>>>> stuff
>>>>
>>>>> it depends on. Is the implication of this that the new AMQP 1.0 JMS
>>>>>
>>>> client
>>>>
>>>>> that you guys are working on will be JMS 2.0 only? I noticed that the
>>>>> pom.xml in there specifies Java 7 already - I guess that's your none to
>>>>> subtle hint ;->
>>>>>
>>>>>
>>>>>   It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom isnt a
>>>> hint
>>>> but rather a requirement; as Rob mentioned the JMS 2.0 API make use of
>>>> the
>>>> try-with-resources language feature, which is strictly Java7+
>>>>
>>>> (obviously that isnt to say you can't do things like hack the bytecode
>>>> after the fact to make it work with Java 6, but...lets not get crazy)
>>>>
>>>>
>>>>   Hmm you could probably make similar arguments for adopting C++11 - not
>>>>> least because Boost version dependencies suck, but there are still a ton
>>>>>
>>>> of
>>>>
>>>>> people (myself included at the moment) with older systems - though to be
>>>>> fair upgrading C++ compilers tends to be harder than upgrading Java
>>>>> versions for any given OS version.
>>>>>
>>>> Especially if you arent talking about package manager installations. One
>>>> is
>>>> really really easy, is the other? :)
>>>>
>>>>
>>>>   It's interesting that Proton (well Proton-C at any rate) seems to be
>>>>> taking a very different tack where it seems to be actively trying to
>>>>> minimise dependencies on anything new and shiny - I'm pretty sure I saw
>>>>> a
>>>>> Jira the other day for changing send.c and recv.c because they were C99
>>>>>
>>>> and
>>>>
>>>>> broke on Windows builds that needed good old C89 :-D
>>>>>
>>>>> Just being a bit Devils' advocate to mix things up a bit, as I say I'm
>>>>> personally agnostic :-)
>>>>>
>>>>> Frase
>>>>>
>>>>>
>>>>>
>>>>> On 07/04/14 17:33, Robbie Gemmell wrote:
>>>>>
>>>>>   I think this makes sense. We waited too long to drop support for Java
>>>>>> 5,
>>>>>> lets not repeat that with 6. Beginning to depend on Java 7 after three
>>>>>> years doesnt seem unreasonable to me.
>>>>>>
>>>>>> Those those who 'cant' or dont want to upgrade to such 'new' (i.e
>>>>>> really
>>>>>> quite old now) Java releases are often likely to be the same ones that
>>>>>> aren't so likely to use the latest Qpid releases either.
>>>>>>
>>>>>> Robbie
>>>>>>
>>>>>> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
>>>>>>
>>>>>>    All,
>>>>>>
>>>>>>> now that Java 8 has been released, and Java 6 has been officially EOLd
>>>>>>> for
>>>>>>> well over a year, I'd like to propose that we make 0.28 the last
>>>>>>>
>>>>>> release
>>>>> for which we officially support Java 6.  As a library provider I'm
>>>>>> aware
>>>>> that we need to strive to make our libraries as widely adoptable as
>>>>>>> possible, but not adopting Java 7 also holds us back from implementing
>>>>>>> functionality that requires features of later releases (as JMS 2.0
>>>>>>>
>>>>>> does).
>>>>> Java 7 was released in 2011 and is itself scheduled to be EOLd next
>>>>>> year.
>>>>> If we do later find critical defects that affect the 0.28 release we
>>>>>>> should
>>>>>>> consider back-patching to a Java 6 release based on 0.28, however I
>>>>>>>
>>>>>> don't
>>>>> think requiring that all new functionality releases require the
>>>>>> adoption
>>>>> a
>>>>>>> version of Java that Oracle supports to be an undue burden.
>>>>>>>
>>>>>>> -- Rob
>>>>>>>
>>>>>>>
>>>>>>>   ------------------------------------------------------------
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: [Proposal] Ending Support for Java 6

[Robbie Gemmell <ro...@gmail.com>]

On 10 April 2014 19:03, Fraser Adams <fr...@blueyonder.co.uk> wrote:

> From a *really parochial* perspective I've done a straw poll of my
> organisation and was astonished to find we're more or less ahead of the
> curve :-D
>
>
With all the recent security related issues, I've found that the people who
are inclined to ever upgrade tend to do a better job of it now...and the
rest are running versions of <JavaThing> so old they can still use it on
Java 5 if they really want and at this point we are just discussing things
they'd consider mythical ;)


> from a personal perspective, as I said earlier I'm largely agnostic
>
> I am however a bit disappointed by the lack of response on this thread,
> though perhaps silence is simply acceptance?


Possibly. For many of us Java 6 is just already considered archaic. Fedora
21 for example (which is admittedly not due out until August+) is
apparently looking to remove Java 7 and move to Java 8 by default.


I guess that I also can't help but wonder that we ended up going through a
> couple of releases before we properly killed off the automake builds by
> providing some "persuaders" because that seemed like the right thing to do.
>
>
I think that one is a little different for a couple of reasons:
- Changing back to an earlier Java compiler and class version for
compilation is easier (basically update a property, which can be done via
the command line) than migrating between C++ build systems at short notice
- I expect significantly fewer users actually build the Java bits
themselves versus the C++ bits, because theyll typically consume the
binaries.

I think if I were being conservative/user friendly my preferred option
> might be (now that the maven work is in 0.28) to make the Maven build use
> Java 7 (you might have already done this I haven't checked) and to have a
> *visible* deprecation notice appear at the end of the ant build to say that
> this is intended to be the last ant/Java 6 supported version and provide a
> link to the user list with a note for users to raise issues if moving to
> Maven/Java 7 is a problem for them.
>

I'd be happy enough putting a deprecation notice into the Ant build when
appropriate, but I would prefer the two builds to always output essentially
the same things while they both exist. As mentioned earlier, if someone
really needs to change it back to compile for Java 6 it is going to be
rather easy for them to do so.


> That at least gives fair warning for people who may not read the user list.
>
> I think also holding fire on any code changes with an *absolute
> dependency* on Java 7 until closer to 0.30 release time to give 0.28 users
> who have issues with moving to Java 6 enough time to flag up concerns.
>
> I won't down vote it you don't want to do this and nobody else objects,
> but I do think that it's the friendly thing to do.
>
> Frase
>
>
>
> On 09/04/14 21:51, Rob Godfrey wrote:
>
>> Just bumping this thread again - does anyone have any objections... I'd
>> plan on moving forward with switching the builds to 1.7 sometime next
>> week if we haven't heard any by then
>>
>> -- Rob
>>
>>
>> On 8 April 2014 00:02, Robbie Gemmell <ro...@gmail.com> wrote:
>>
>>  On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk>
>>> wrote:
>>>
>>>  I think that this definitely needs input from the broad community. I can
>>>> see where you're coming from, but my observations of large Enterprises
>>>> (which TBH are often the main consumers of Messaging products) are that
>>>> they are often in a difficult position wrt. keeping up with the times.
>>>> Don't talk to me about IE8 for example!! There's a whole *industry* of
>>>> polyfills because Enterprises won't or can't upgrade.
>>>>
>>>>  I dont necessarily think IE8 is a comparable situation to a Java
>>> version
>>> change, but I do take your point.
>>>
>>>
>>>  I don't think that your comment "Those those who 'cant' or dont want to
>>>> upgrade to such 'new' (i.e really quite old now) Java releases are often
>>>> likely to be the same ones that aren't so likely to use the latest Qpid
>>>> releases either" necessarily holds, often things like compiler versions
>>>>
>>> get
>>>
>>>> corporately mandated whereas there might be less control exerted on
>>>> libraries. I've got painful memories of being stuck on Java 3 when the
>>>> world had moved to Java 5, this stuff is not as simple as you seem to
>>>>
>>> think.
>>> I agree that there is often more control (and as a result, lack thereof
>>> for
>>> the users) exercised over the platform than the things running on it,
>>> but I
>>> would also say that my experience has been that the two things drift
>>> together to an extent as time passes, and the controlled platform leads
>>> people to stop upgrading the things running on it as it gets older, even
>>> when they could still do so.
>>>
>>> I do realise its not always that simple on the client side, but on the
>>> broker side for example it isnt necessarily that hard, there are ways to
>>> handle that in isolation if really required. Obviously if you rule those
>>> options out you need to have a plan in place to cope with the result of
>>> those decisions (where hoping we are super nice isnt really a plan).
>>>
>>>
>>>  I'm quite impressed that your own organisation has migrated to Java 7
>>>>
>>>>
>>>> I'm *personally* fairly agnostic on this I just think that it's
>>>> important
>>>> to bear in mind how large Enterprises often operate.
>>>>
>>>>  I unfortunately would say I spend too much of my time bearing in mind
>>> how
>>> they do hehe. Its certainly getting my own personal consideration, an is
>>> actually one of the main reasons I support the proposal.
>>>
>>> I know there are people that wont pick such new stuff up until several
>>> months or years after it is released, at which point I dont really think
>>> its a good thing to see them still able to deploy it on the Java 6 JVM
>>> they
>>> should have looked to stop using by then nevermind trying to use it for a
>>> couple further years :)
>>>
>>>
>>>  (Lack of) what features are causing you the most pain? Just curious
>>>> really.
>>>>
>>>
>>> It isnt necessarily just about features (though there are certainly some
>>> I'd like to be able to rely on, and not necessarily even at the language
>>> level), eventual supportability also comes into it for me. If noone is
>>> supporting those JVMs on the other end, and we dont really have the
>>> bandwidth to do so either, is letting new stuff continue to run on them
>>> when noone is testing/fixing the result really such a good thing?  (Hello
>>> Windows XP, I hear tomorrow is your deathday...please tell your users)
>>>
>>> Supporting things far beyond their own EOL date feels a bit like jumping
>>> in
>>> beside someone digging themselves into a hole to lend them an extra pair
>>> of
>>> hands to speed things up :)
>>>
>>>
>>>  Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar
>>>> with
>>>> JMS 2.0, so I'm interested what key things have changed and what new
>>>>
>>> stuff
>>>
>>>> it depends on. Is the implication of this that the new AMQP 1.0 JMS
>>>>
>>> client
>>>
>>>> that you guys are working on will be JMS 2.0 only? I noticed that the
>>>> pom.xml in there specifies Java 7 already - I guess that's your none to
>>>> subtle hint ;->
>>>>
>>>>
>>>>  It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom isnt a
>>> hint
>>> but rather a requirement; as Rob mentioned the JMS 2.0 API make use of
>>> the
>>> try-with-resources language feature, which is strictly Java7+
>>>
>>> (obviously that isnt to say you can't do things like hack the bytecode
>>> after the fact to make it work with Java 6, but...lets not get crazy)
>>>
>>>
>>>  Hmm you could probably make similar arguments for adopting C++11 - not
>>>> least because Boost version dependencies suck, but there are still a ton
>>>>
>>> of
>>>
>>>> people (myself included at the moment) with older systems - though to be
>>>> fair upgrading C++ compilers tends to be harder than upgrading Java
>>>> versions for any given OS version.
>>>>
>>>
>>> Especially if you arent talking about package manager installations. One
>>> is
>>> really really easy, is the other? :)
>>>
>>>
>>>  It's interesting that Proton (well Proton-C at any rate) seems to be
>>>> taking a very different tack where it seems to be actively trying to
>>>> minimise dependencies on anything new and shiny - I'm pretty sure I saw
>>>> a
>>>> Jira the other day for changing send.c and recv.c because they were C99
>>>>
>>> and
>>>
>>>> broke on Windows builds that needed good old C89 :-D
>>>>
>>>> Just being a bit Devils' advocate to mix things up a bit, as I say I'm
>>>> personally agnostic :-)
>>>>
>>>> Frase
>>>>
>>>>
>>>>
>>>> On 07/04/14 17:33, Robbie Gemmell wrote:
>>>>
>>>>  I think this makes sense. We waited too long to drop support for Java
>>>>> 5,
>>>>> lets not repeat that with 6. Beginning to depend on Java 7 after three
>>>>> years doesnt seem unreasonable to me.
>>>>>
>>>>> Those those who 'cant' or dont want to upgrade to such 'new' (i.e
>>>>> really
>>>>> quite old now) Java releases are often likely to be the same ones that
>>>>> aren't so likely to use the latest Qpid releases either.
>>>>>
>>>>> Robbie
>>>>>
>>>>> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
>>>>>
>>>>>   All,
>>>>>
>>>>>> now that Java 8 has been released, and Java 6 has been officially EOLd
>>>>>> for
>>>>>> well over a year, I'd like to propose that we make 0.28 the last
>>>>>>
>>>>> release
>>>
>>>> for which we officially support Java 6.  As a library provider I'm
>>>>>>
>>>>> aware
>>>
>>>> that we need to strive to make our libraries as widely adoptable as
>>>>>> possible, but not adopting Java 7 also holds us back from implementing
>>>>>> functionality that requires features of later releases (as JMS 2.0
>>>>>>
>>>>> does).
>>>
>>>> Java 7 was released in 2011 and is itself scheduled to be EOLd next
>>>>>>
>>>>> year.
>>>
>>>> If we do later find critical defects that affect the 0.28 release we
>>>>>> should
>>>>>> consider back-patching to a Java 6 release based on 0.28, however I
>>>>>>
>>>>> don't
>>>
>>>> think requiring that all new functionality releases require the
>>>>>>
>>>>> adoption
>>>
>>>> a
>>>>>> version of Java that Oracle supports to be an undue burden.
>>>>>>
>>>>>> -- Rob
>>>>>>
>>>>>>
>>>>>>  ------------------------------------------------------------
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: [Proposal] Ending Support for Java 6

[Fraser Adams <fr...@blueyonder.co.uk>]

 From a *really parochial* perspective I've done a straw poll of my 
organisation and was astonished to find we're more or less ahead of the 
curve :-D

from a personal perspective, as I said earlier I'm largely agnostic

I am however a bit disappointed by the lack of response on this thread, 
though perhaps silence is simply acceptance? I guess that I also can't 
help but wonder that we ended up going through a couple of releases 
before we properly killed off the automake builds by providing some 
"persuaders" because that seemed like the right thing to do.

I think if I were being conservative/user friendly my preferred option 
might be (now that the maven work is in 0.28) to make the Maven build 
use Java 7 (you might have already done this I haven't checked) and to 
have a *visible* deprecation notice appear at the end of the ant build 
to say that this is intended to be the last ant/Java 6 supported version 
and provide a link to the user list with a note for users to raise 
issues if moving to Maven/Java 7 is a problem for them.

That at least gives fair warning for people who may not read the user list.

I think also holding fire on any code changes with an *absolute 
dependency* on Java 7 until closer to 0.30 release time to give 0.28 
users who have issues with moving to Java 6 enough time to flag up concerns.

I won't down vote it you don't want to do this and nobody else objects, 
but I do think that it's the friendly thing to do.

Frase


On 09/04/14 21:51, Rob Godfrey wrote:
> Just bumping this thread again - does anyone have any objections... I'd
> plan on moving forward with switching the builds to 1.7 sometime next
> week if we haven't heard any by then
>
> -- Rob
>
>
> On 8 April 2014 00:02, Robbie Gemmell <ro...@gmail.com> wrote:
>
>> On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>>
>>> I think that this definitely needs input from the broad community. I can
>>> see where you're coming from, but my observations of large Enterprises
>>> (which TBH are often the main consumers of Messaging products) are that
>>> they are often in a difficult position wrt. keeping up with the times.
>>> Don't talk to me about IE8 for example!! There's a whole *industry* of
>>> polyfills because Enterprises won't or can't upgrade.
>>>
>> I dont necessarily think IE8 is a comparable situation to a Java version
>> change, but I do take your point.
>>
>>
>>> I don't think that your comment "Those those who 'cant' or dont want to
>>> upgrade to such 'new' (i.e really quite old now) Java releases are often
>>> likely to be the same ones that aren't so likely to use the latest Qpid
>>> releases either" necessarily holds, often things like compiler versions
>> get
>>> corporately mandated whereas there might be less control exerted on
>>> libraries. I've got painful memories of being stuck on Java 3 when the
>>> world had moved to Java 5, this stuff is not as simple as you seem to
>> think.
>> I agree that there is often more control (and as a result, lack thereof for
>> the users) exercised over the platform than the things running on it, but I
>> would also say that my experience has been that the two things drift
>> together to an extent as time passes, and the controlled platform leads
>> people to stop upgrading the things running on it as it gets older, even
>> when they could still do so.
>>
>> I do realise its not always that simple on the client side, but on the
>> broker side for example it isnt necessarily that hard, there are ways to
>> handle that in isolation if really required. Obviously if you rule those
>> options out you need to have a plan in place to cope with the result of
>> those decisions (where hoping we are super nice isnt really a plan).
>>
>>
>>> I'm quite impressed that your own organisation has migrated to Java 7
>>>
>>>
>>> I'm *personally* fairly agnostic on this I just think that it's important
>>> to bear in mind how large Enterprises often operate.
>>>
>> I unfortunately would say I spend too much of my time bearing in mind how
>> they do hehe. Its certainly getting my own personal consideration, an is
>> actually one of the main reasons I support the proposal.
>>
>> I know there are people that wont pick such new stuff up until several
>> months or years after it is released, at which point I dont really think
>> its a good thing to see them still able to deploy it on the Java 6 JVM they
>> should have looked to stop using by then nevermind trying to use it for a
>> couple further years :)
>>
>>
>>> (Lack of) what features are causing you the most pain? Just curious
>>> really.
>>
>> It isnt necessarily just about features (though there are certainly some
>> I'd like to be able to rely on, and not necessarily even at the language
>> level), eventual supportability also comes into it for me. If noone is
>> supporting those JVMs on the other end, and we dont really have the
>> bandwidth to do so either, is letting new stuff continue to run on them
>> when noone is testing/fixing the result really such a good thing?  (Hello
>> Windows XP, I hear tomorrow is your deathday...please tell your users)
>>
>> Supporting things far beyond their own EOL date feels a bit like jumping in
>> beside someone digging themselves into a hole to lend them an extra pair of
>> hands to speed things up :)
>>
>>
>>> Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar with
>>> JMS 2.0, so I'm interested what key things have changed and what new
>> stuff
>>> it depends on. Is the implication of this that the new AMQP 1.0 JMS
>> client
>>> that you guys are working on will be JMS 2.0 only? I noticed that the
>>> pom.xml in there specifies Java 7 already - I guess that's your none to
>>> subtle hint ;->
>>>
>>>
>> It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom isnt a hint
>> but rather a requirement; as Rob mentioned the JMS 2.0 API make use of the
>> try-with-resources language feature, which is strictly Java7+
>>
>> (obviously that isnt to say you can't do things like hack the bytecode
>> after the fact to make it work with Java 6, but...lets not get crazy)
>>
>>
>>> Hmm you could probably make similar arguments for adopting C++11 - not
>>> least because Boost version dependencies suck, but there are still a ton
>> of
>>> people (myself included at the moment) with older systems - though to be
>>> fair upgrading C++ compilers tends to be harder than upgrading Java
>>> versions for any given OS version.
>>
>> Especially if you arent talking about package manager installations. One is
>> really really easy, is the other? :)
>>
>>
>>> It's interesting that Proton (well Proton-C at any rate) seems to be
>>> taking a very different tack where it seems to be actively trying to
>>> minimise dependencies on anything new and shiny - I'm pretty sure I saw a
>>> Jira the other day for changing send.c and recv.c because they were C99
>> and
>>> broke on Windows builds that needed good old C89 :-D
>>>
>>> Just being a bit Devils' advocate to mix things up a bit, as I say I'm
>>> personally agnostic :-)
>>>
>>> Frase
>>>
>>>
>>>
>>> On 07/04/14 17:33, Robbie Gemmell wrote:
>>>
>>>> I think this makes sense. We waited too long to drop support for Java 5,
>>>> lets not repeat that with 6. Beginning to depend on Java 7 after three
>>>> years doesnt seem unreasonable to me.
>>>>
>>>> Those those who 'cant' or dont want to upgrade to such 'new' (i.e really
>>>> quite old now) Java releases are often likely to be the same ones that
>>>> aren't so likely to use the latest Qpid releases either.
>>>>
>>>> Robbie
>>>>
>>>> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
>>>>
>>>>   All,
>>>>> now that Java 8 has been released, and Java 6 has been officially EOLd
>>>>> for
>>>>> well over a year, I'd like to propose that we make 0.28 the last
>> release
>>>>> for which we officially support Java 6.  As a library provider I'm
>> aware
>>>>> that we need to strive to make our libraries as widely adoptable as
>>>>> possible, but not adopting Java 7 also holds us back from implementing
>>>>> functionality that requires features of later releases (as JMS 2.0
>> does).
>>>>> Java 7 was released in 2011 and is itself scheduled to be EOLd next
>> year.
>>>>> If we do later find critical defects that affect the 0.28 release we
>>>>> should
>>>>> consider back-patching to a Java 6 release based on 0.28, however I
>> don't
>>>>> think requiring that all new functionality releases require the
>> adoption
>>>>> a
>>>>> version of Java that Oracle supports to be an undue burden.
>>>>>
>>>>> -- Rob
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: [Proposal] Ending Support for Java 6

[Rob Godfrey <ro...@gmail.com>]

Hi Jakub,

yeah this is also my experience... we have a whole load of people stuck on
really outdated versions... and most other people are already on Java 7 or
planning to move.  Moreover most people don't take new versions of the Qpid
libraries straight away either... (or those that do are also the types to
already be on the latest version of Java).  Personally I think I'll be
supporting Java 6 for another couple of years - but some of those users are
probably using prehistoric versions of the Qpid code too.

To be honest I'd be incredibly surprised if the source for the client
doesn't continue to compile and run on Java 6 for at least the next couple
of releases... however I don't think it's sustainable for the developers to
have to run tests against three different Java environments for every
change and in particular I do not think it is right to ask the developers
to have to install and run versions of Java for which Oracle is no longer
providing any security remediation.

-- Rob


On 10 April 2014 20:40, Jakub Scholz <ja...@scholz.cz> wrote:

> Hi Rob,
>
> People always need a proper motivation to upgrade from outdated Java to
> something newer ... and you can motivate them. (I know, this is not really
> the objection you are asking for)
>
> A bit to my surprise, so far nobody from my colleagues seemed to have
> problem with this idea. I guess it must be because most of our Java
> applications are fairly new and the real legacy projects run on much older
> technologies than Java 6 :-).
>
> Regards
> Jakub
>
>
>
> On Wed, Apr 9, 2014 at 10:51 PM, Rob Godfrey <rob.j.godfrey@gmail.com
> >wrote:
>
> > Just bumping this thread again - does anyone have any objections... I'd
> > plan on moving forward with switching the builds to 1.7 sometime next
> > week if we haven't heard any by then
> >
> > -- Rob
> >
> >
> > On 8 April 2014 00:02, Robbie Gemmell <ro...@gmail.com> wrote:
> >
> > > On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk>
> > wrote:
> > >
> > > > I think that this definitely needs input from the broad community. I
> > can
> > > > see where you're coming from, but my observations of large
> Enterprises
> > > > (which TBH are often the main consumers of Messaging products) are
> that
> > > > they are often in a difficult position wrt. keeping up with the
> times.
> > > > Don't talk to me about IE8 for example!! There's a whole *industry*
> of
> > > > polyfills because Enterprises won't or can't upgrade.
> > > >
> > >
> > > I dont necessarily think IE8 is a comparable situation to a Java
> version
> > > change, but I do take your point.
> > >
> > >
> > > > I don't think that your comment "Those those who 'cant' or dont want
> to
> > > > upgrade to such 'new' (i.e really quite old now) Java releases are
> > often
> > > > likely to be the same ones that aren't so likely to use the latest
> Qpid
> > > > releases either" necessarily holds, often things like compiler
> versions
> > > get
> > > > corporately mandated whereas there might be less control exerted on
> > > > libraries. I've got painful memories of being stuck on Java 3 when
> the
> > > > world had moved to Java 5, this stuff is not as simple as you seem to
> > > think.
> > > >
> > >
> > > I agree that there is often more control (and as a result, lack thereof
> > for
> > > the users) exercised over the platform than the things running on it,
> > but I
> > > would also say that my experience has been that the two things drift
> > > together to an extent as time passes, and the controlled platform leads
> > > people to stop upgrading the things running on it as it gets older,
> even
> > > when they could still do so.
> > >
> > > I do realise its not always that simple on the client side, but on the
> > > broker side for example it isnt necessarily that hard, there are ways
> to
> > > handle that in isolation if really required. Obviously if you rule
> those
> > > options out you need to have a plan in place to cope with the result of
> > > those decisions (where hoping we are super nice isnt really a plan).
> > >
> > >
> > > >
> > > > I'm quite impressed that your own organisation has migrated to Java 7
> > > >
> > > >
> > > > I'm *personally* fairly agnostic on this I just think that it's
> > important
> > > > to bear in mind how large Enterprises often operate.
> > > >
> > >
> > > I unfortunately would say I spend too much of my time bearing in mind
> how
> > > they do hehe. Its certainly getting my own personal consideration, an
> is
> > > actually one of the main reasons I support the proposal.
> > >
> > > I know there are people that wont pick such new stuff up until several
> > > months or years after it is released, at which point I dont really
> think
> > > its a good thing to see them still able to deploy it on the Java 6 JVM
> > they
> > > should have looked to stop using by then nevermind trying to use it
> for a
> > > couple further years :)
> > >
> > >
> > > > (Lack of) what features are causing you the most pain? Just curious
> > > > really.
> > >
> > >
> > > It isnt necessarily just about features (though there are certainly
> some
> > > I'd like to be able to rely on, and not necessarily even at the
> language
> > > level), eventual supportability also comes into it for me. If noone is
> > > supporting those JVMs on the other end, and we dont really have the
> > > bandwidth to do so either, is letting new stuff continue to run on them
> > > when noone is testing/fixing the result really such a good thing?
>  (Hello
> > > Windows XP, I hear tomorrow is your deathday...please tell your users)
> > >
> > > Supporting things far beyond their own EOL date feels a bit like
> jumping
> > in
> > > beside someone digging themselves into a hole to lend them an extra
> pair
> > of
> > > hands to speed things up :)
> > >
> > >
> > > > Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar
> > with
> > > > JMS 2.0, so I'm interested what key things have changed and what new
> > > stuff
> > > > it depends on. Is the implication of this that the new AMQP 1.0 JMS
> > > client
> > > > that you guys are working on will be JMS 2.0 only? I noticed that the
> > > > pom.xml in there specifies Java 7 already - I guess that's your none
> to
> > > > subtle hint ;->
> > > >
> > > >
> > > It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom isnt a
> > hint
> > > but rather a requirement; as Rob mentioned the JMS 2.0 API make use of
> > the
> > > try-with-resources language feature, which is strictly Java7+
> > >
> > > (obviously that isnt to say you can't do things like hack the bytecode
> > > after the fact to make it work with Java 6, but...lets not get crazy)
> > >
> > >
> > > >
> > > > Hmm you could probably make similar arguments for adopting C++11 -
> not
> > > > least because Boost version dependencies suck, but there are still a
> > ton
> > > of
> > > > people (myself included at the moment) with older systems - though to
> > be
> > > > fair upgrading C++ compilers tends to be harder than upgrading Java
> > > > versions for any given OS version.
> > >
> > >
> > > Especially if you arent talking about package manager installations.
> One
> > is
> > > really really easy, is the other? :)
> > >
> > >
> > > > It's interesting that Proton (well Proton-C at any rate) seems to be
> > > > taking a very different tack where it seems to be actively trying to
> > > > minimise dependencies on anything new and shiny - I'm pretty sure I
> > saw a
> > > > Jira the other day for changing send.c and recv.c because they were
> C99
> > > and
> > > > broke on Windows builds that needed good old C89 :-D
> > > >
> > > > Just being a bit Devils' advocate to mix things up a bit, as I say
> I'm
> > > > personally agnostic :-)
> > > >
> > > > Frase
> > > >
> > > >
> > > >
> > > > On 07/04/14 17:33, Robbie Gemmell wrote:
> > > >
> > > >> I think this makes sense. We waited too long to drop support for
> Java
> > 5,
> > > >> lets not repeat that with 6. Beginning to depend on Java 7 after
> three
> > > >> years doesnt seem unreasonable to me.
> > > >>
> > > >> Those those who 'cant' or dont want to upgrade to such 'new' (i.e
> > really
> > > >> quite old now) Java releases are often likely to be the same ones
> that
> > > >> aren't so likely to use the latest Qpid releases either.
> > > >>
> > > >> Robbie
> > > >>
> > > >> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
> > > >>
> > > >>  All,
> > > >>>
> > > >>> now that Java 8 has been released, and Java 6 has been officially
> > EOLd
> > > >>> for
> > > >>> well over a year, I'd like to propose that we make 0.28 the last
> > > release
> > > >>> for which we officially support Java 6.  As a library provider I'm
> > > aware
> > > >>> that we need to strive to make our libraries as widely adoptable as
> > > >>> possible, but not adopting Java 7 also holds us back from
> > implementing
> > > >>> functionality that requires features of later releases (as JMS 2.0
> > > does).
> > > >>>
> > > >>> Java 7 was released in 2011 and is itself scheduled to be EOLd next
> > > year.
> > > >>>
> > > >>> If we do later find critical defects that affect the 0.28 release
> we
> > > >>> should
> > > >>> consider back-patching to a Java 6 release based on 0.28, however I
> > > don't
> > > >>> think requiring that all new functionality releases require the
> > > adoption
> > > >>> a
> > > >>> version of Java that Oracle supports to be an undue burden.
> > > >>>
> > > >>> -- Rob
> > > >>>
> > > >>>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> >
>

Re: [Proposal] Ending Support for Java 6

[Jakub Scholz <ja...@scholz.cz>]

Hi Rob,

People always need a proper motivation to upgrade from outdated Java to
something newer ... and you can motivate them. (I know, this is not really
the objection you are asking for)

A bit to my surprise, so far nobody from my colleagues seemed to have
problem with this idea. I guess it must be because most of our Java
applications are fairly new and the real legacy projects run on much older
technologies than Java 6 :-).

Regards
Jakub



On Wed, Apr 9, 2014 at 10:51 PM, Rob Godfrey <ro...@gmail.com>wrote:

> Just bumping this thread again - does anyone have any objections... I'd
> plan on moving forward with switching the builds to 1.7 sometime next
> week if we haven't heard any by then
>
> -- Rob
>
>
> On 8 April 2014 00:02, Robbie Gemmell <ro...@gmail.com> wrote:
>
> > On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk>
> wrote:
> >
> > > I think that this definitely needs input from the broad community. I
> can
> > > see where you're coming from, but my observations of large Enterprises
> > > (which TBH are often the main consumers of Messaging products) are that
> > > they are often in a difficult position wrt. keeping up with the times.
> > > Don't talk to me about IE8 for example!! There's a whole *industry* of
> > > polyfills because Enterprises won't or can't upgrade.
> > >
> >
> > I dont necessarily think IE8 is a comparable situation to a Java version
> > change, but I do take your point.
> >
> >
> > > I don't think that your comment "Those those who 'cant' or dont want to
> > > upgrade to such 'new' (i.e really quite old now) Java releases are
> often
> > > likely to be the same ones that aren't so likely to use the latest Qpid
> > > releases either" necessarily holds, often things like compiler versions
> > get
> > > corporately mandated whereas there might be less control exerted on
> > > libraries. I've got painful memories of being stuck on Java 3 when the
> > > world had moved to Java 5, this stuff is not as simple as you seem to
> > think.
> > >
> >
> > I agree that there is often more control (and as a result, lack thereof
> for
> > the users) exercised over the platform than the things running on it,
> but I
> > would also say that my experience has been that the two things drift
> > together to an extent as time passes, and the controlled platform leads
> > people to stop upgrading the things running on it as it gets older, even
> > when they could still do so.
> >
> > I do realise its not always that simple on the client side, but on the
> > broker side for example it isnt necessarily that hard, there are ways to
> > handle that in isolation if really required. Obviously if you rule those
> > options out you need to have a plan in place to cope with the result of
> > those decisions (where hoping we are super nice isnt really a plan).
> >
> >
> > >
> > > I'm quite impressed that your own organisation has migrated to Java 7
> > >
> > >
> > > I'm *personally* fairly agnostic on this I just think that it's
> important
> > > to bear in mind how large Enterprises often operate.
> > >
> >
> > I unfortunately would say I spend too much of my time bearing in mind how
> > they do hehe. Its certainly getting my own personal consideration, an is
> > actually one of the main reasons I support the proposal.
> >
> > I know there are people that wont pick such new stuff up until several
> > months or years after it is released, at which point I dont really think
> > its a good thing to see them still able to deploy it on the Java 6 JVM
> they
> > should have looked to stop using by then nevermind trying to use it for a
> > couple further years :)
> >
> >
> > > (Lack of) what features are causing you the most pain? Just curious
> > > really.
> >
> >
> > It isnt necessarily just about features (though there are certainly some
> > I'd like to be able to rely on, and not necessarily even at the language
> > level), eventual supportability also comes into it for me. If noone is
> > supporting those JVMs on the other end, and we dont really have the
> > bandwidth to do so either, is letting new stuff continue to run on them
> > when noone is testing/fixing the result really such a good thing?  (Hello
> > Windows XP, I hear tomorrow is your deathday...please tell your users)
> >
> > Supporting things far beyond their own EOL date feels a bit like jumping
> in
> > beside someone digging themselves into a hole to lend them an extra pair
> of
> > hands to speed things up :)
> >
> >
> > > Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar
> with
> > > JMS 2.0, so I'm interested what key things have changed and what new
> > stuff
> > > it depends on. Is the implication of this that the new AMQP 1.0 JMS
> > client
> > > that you guys are working on will be JMS 2.0 only? I noticed that the
> > > pom.xml in there specifies Java 7 already - I guess that's your none to
> > > subtle hint ;->
> > >
> > >
> > It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom isnt a
> hint
> > but rather a requirement; as Rob mentioned the JMS 2.0 API make use of
> the
> > try-with-resources language feature, which is strictly Java7+
> >
> > (obviously that isnt to say you can't do things like hack the bytecode
> > after the fact to make it work with Java 6, but...lets not get crazy)
> >
> >
> > >
> > > Hmm you could probably make similar arguments for adopting C++11 - not
> > > least because Boost version dependencies suck, but there are still a
> ton
> > of
> > > people (myself included at the moment) with older systems - though to
> be
> > > fair upgrading C++ compilers tends to be harder than upgrading Java
> > > versions for any given OS version.
> >
> >
> > Especially if you arent talking about package manager installations. One
> is
> > really really easy, is the other? :)
> >
> >
> > > It's interesting that Proton (well Proton-C at any rate) seems to be
> > > taking a very different tack where it seems to be actively trying to
> > > minimise dependencies on anything new and shiny - I'm pretty sure I
> saw a
> > > Jira the other day for changing send.c and recv.c because they were C99
> > and
> > > broke on Windows builds that needed good old C89 :-D
> > >
> > > Just being a bit Devils' advocate to mix things up a bit, as I say I'm
> > > personally agnostic :-)
> > >
> > > Frase
> > >
> > >
> > >
> > > On 07/04/14 17:33, Robbie Gemmell wrote:
> > >
> > >> I think this makes sense. We waited too long to drop support for Java
> 5,
> > >> lets not repeat that with 6. Beginning to depend on Java 7 after three
> > >> years doesnt seem unreasonable to me.
> > >>
> > >> Those those who 'cant' or dont want to upgrade to such 'new' (i.e
> really
> > >> quite old now) Java releases are often likely to be the same ones that
> > >> aren't so likely to use the latest Qpid releases either.
> > >>
> > >> Robbie
> > >>
> > >> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
> > >>
> > >>  All,
> > >>>
> > >>> now that Java 8 has been released, and Java 6 has been officially
> EOLd
> > >>> for
> > >>> well over a year, I'd like to propose that we make 0.28 the last
> > release
> > >>> for which we officially support Java 6.  As a library provider I'm
> > aware
> > >>> that we need to strive to make our libraries as widely adoptable as
> > >>> possible, but not adopting Java 7 also holds us back from
> implementing
> > >>> functionality that requires features of later releases (as JMS 2.0
> > does).
> > >>>
> > >>> Java 7 was released in 2011 and is itself scheduled to be EOLd next
> > year.
> > >>>
> > >>> If we do later find critical defects that affect the 0.28 release we
> > >>> should
> > >>> consider back-patching to a Java 6 release based on 0.28, however I
> > don't
> > >>> think requiring that all new functionality releases require the
> > adoption
> > >>> a
> > >>> version of Java that Oracle supports to be an undue burden.
> > >>>
> > >>> -- Rob
> > >>>
> > >>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
>

Re: [Proposal] Ending Support for Java 6

[Rob Godfrey <ro...@gmail.com>]

Just bumping this thread again - does anyone have any objections... I'd
plan on moving forward with switching the builds to 1.7 sometime next
week if we haven't heard any by then

-- Rob


On 8 April 2014 00:02, Robbie Gemmell <ro...@gmail.com> wrote:

> On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
> > I think that this definitely needs input from the broad community. I can
> > see where you're coming from, but my observations of large Enterprises
> > (which TBH are often the main consumers of Messaging products) are that
> > they are often in a difficult position wrt. keeping up with the times.
> > Don't talk to me about IE8 for example!! There's a whole *industry* of
> > polyfills because Enterprises won't or can't upgrade.
> >
>
> I dont necessarily think IE8 is a comparable situation to a Java version
> change, but I do take your point.
>
>
> > I don't think that your comment "Those those who 'cant' or dont want to
> > upgrade to such 'new' (i.e really quite old now) Java releases are often
> > likely to be the same ones that aren't so likely to use the latest Qpid
> > releases either" necessarily holds, often things like compiler versions
> get
> > corporately mandated whereas there might be less control exerted on
> > libraries. I've got painful memories of being stuck on Java 3 when the
> > world had moved to Java 5, this stuff is not as simple as you seem to
> think.
> >
>
> I agree that there is often more control (and as a result, lack thereof for
> the users) exercised over the platform than the things running on it, but I
> would also say that my experience has been that the two things drift
> together to an extent as time passes, and the controlled platform leads
> people to stop upgrading the things running on it as it gets older, even
> when they could still do so.
>
> I do realise its not always that simple on the client side, but on the
> broker side for example it isnt necessarily that hard, there are ways to
> handle that in isolation if really required. Obviously if you rule those
> options out you need to have a plan in place to cope with the result of
> those decisions (where hoping we are super nice isnt really a plan).
>
>
> >
> > I'm quite impressed that your own organisation has migrated to Java 7
> >
> >
> > I'm *personally* fairly agnostic on this I just think that it's important
> > to bear in mind how large Enterprises often operate.
> >
>
> I unfortunately would say I spend too much of my time bearing in mind how
> they do hehe. Its certainly getting my own personal consideration, an is
> actually one of the main reasons I support the proposal.
>
> I know there are people that wont pick such new stuff up until several
> months or years after it is released, at which point I dont really think
> its a good thing to see them still able to deploy it on the Java 6 JVM they
> should have looked to stop using by then nevermind trying to use it for a
> couple further years :)
>
>
> > (Lack of) what features are causing you the most pain? Just curious
> > really.
>
>
> It isnt necessarily just about features (though there are certainly some
> I'd like to be able to rely on, and not necessarily even at the language
> level), eventual supportability also comes into it for me. If noone is
> supporting those JVMs on the other end, and we dont really have the
> bandwidth to do so either, is letting new stuff continue to run on them
> when noone is testing/fixing the result really such a good thing?  (Hello
> Windows XP, I hear tomorrow is your deathday...please tell your users)
>
> Supporting things far beyond their own EOL date feels a bit like jumping in
> beside someone digging themselves into a hole to lend them an extra pair of
> hands to speed things up :)
>
>
> > Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar with
> > JMS 2.0, so I'm interested what key things have changed and what new
> stuff
> > it depends on. Is the implication of this that the new AMQP 1.0 JMS
> client
> > that you guys are working on will be JMS 2.0 only? I noticed that the
> > pom.xml in there specifies Java 7 already - I guess that's your none to
> > subtle hint ;->
> >
> >
> It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom isnt a hint
> but rather a requirement; as Rob mentioned the JMS 2.0 API make use of the
> try-with-resources language feature, which is strictly Java7+
>
> (obviously that isnt to say you can't do things like hack the bytecode
> after the fact to make it work with Java 6, but...lets not get crazy)
>
>
> >
> > Hmm you could probably make similar arguments for adopting C++11 - not
> > least because Boost version dependencies suck, but there are still a ton
> of
> > people (myself included at the moment) with older systems - though to be
> > fair upgrading C++ compilers tends to be harder than upgrading Java
> > versions for any given OS version.
>
>
> Especially if you arent talking about package manager installations. One is
> really really easy, is the other? :)
>
>
> > It's interesting that Proton (well Proton-C at any rate) seems to be
> > taking a very different tack where it seems to be actively trying to
> > minimise dependencies on anything new and shiny - I'm pretty sure I saw a
> > Jira the other day for changing send.c and recv.c because they were C99
> and
> > broke on Windows builds that needed good old C89 :-D
> >
> > Just being a bit Devils' advocate to mix things up a bit, as I say I'm
> > personally agnostic :-)
> >
> > Frase
> >
> >
> >
> > On 07/04/14 17:33, Robbie Gemmell wrote:
> >
> >> I think this makes sense. We waited too long to drop support for Java 5,
> >> lets not repeat that with 6. Beginning to depend on Java 7 after three
> >> years doesnt seem unreasonable to me.
> >>
> >> Those those who 'cant' or dont want to upgrade to such 'new' (i.e really
> >> quite old now) Java releases are often likely to be the same ones that
> >> aren't so likely to use the latest Qpid releases either.
> >>
> >> Robbie
> >>
> >> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
> >>
> >>  All,
> >>>
> >>> now that Java 8 has been released, and Java 6 has been officially EOLd
> >>> for
> >>> well over a year, I'd like to propose that we make 0.28 the last
> release
> >>> for which we officially support Java 6.  As a library provider I'm
> aware
> >>> that we need to strive to make our libraries as widely adoptable as
> >>> possible, but not adopting Java 7 also holds us back from implementing
> >>> functionality that requires features of later releases (as JMS 2.0
> does).
> >>>
> >>> Java 7 was released in 2011 and is itself scheduled to be EOLd next
> year.
> >>>
> >>> If we do later find critical defects that affect the 0.28 release we
> >>> should
> >>> consider back-patching to a Java 6 release based on 0.28, however I
> don't
> >>> think requiring that all new functionality releases require the
> adoption
> >>> a
> >>> version of Java that Oracle supports to be an undue burden.
> >>>
> >>> -- Rob
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>

Re: [Proposal] Ending Support for Java 6

[Robbie Gemmell <ro...@gmail.com>]

On 7 April 2014 19:30, Fraser Adams <fr...@blueyonder.co.uk> wrote:

> I think that this definitely needs input from the broad community. I can
> see where you're coming from, but my observations of large Enterprises
> (which TBH are often the main consumers of Messaging products) are that
> they are often in a difficult position wrt. keeping up with the times.
> Don't talk to me about IE8 for example!! There's a whole *industry* of
> polyfills because Enterprises won't or can't upgrade.
>

I dont necessarily think IE8 is a comparable situation to a Java version
change, but I do take your point.


> I don't think that your comment "Those those who 'cant' or dont want to
> upgrade to such 'new' (i.e really quite old now) Java releases are often
> likely to be the same ones that aren't so likely to use the latest Qpid
> releases either" necessarily holds, often things like compiler versions get
> corporately mandated whereas there might be less control exerted on
> libraries. I've got painful memories of being stuck on Java 3 when the
> world had moved to Java 5, this stuff is not as simple as you seem to think.
>

I agree that there is often more control (and as a result, lack thereof for
the users) exercised over the platform than the things running on it, but I
would also say that my experience has been that the two things drift
together to an extent as time passes, and the controlled platform leads
people to stop upgrading the things running on it as it gets older, even
when they could still do so.

I do realise its not always that simple on the client side, but on the
broker side for example it isnt necessarily that hard, there are ways to
handle that in isolation if really required. Obviously if you rule those
options out you need to have a plan in place to cope with the result of
those decisions (where hoping we are super nice isnt really a plan).


>
> I'm quite impressed that your own organisation has migrated to Java 7
>
>
> I'm *personally* fairly agnostic on this I just think that it's important
> to bear in mind how large Enterprises often operate.
>

I unfortunately would say I spend too much of my time bearing in mind how
they do hehe. Its certainly getting my own personal consideration, an is
actually one of the main reasons I support the proposal.

I know there are people that wont pick such new stuff up until several
months or years after it is released, at which point I dont really think
its a good thing to see them still able to deploy it on the Java 6 JVM they
should have looked to stop using by then nevermind trying to use it for a
couple further years :)


> (Lack of) what features are causing you the most pain? Just curious
> really.


It isnt necessarily just about features (though there are certainly some
I'd like to be able to rely on, and not necessarily even at the language
level), eventual supportability also comes into it for me. If noone is
supporting those JVMs on the other end, and we dont really have the
bandwidth to do so either, is letting new stuff continue to run on them
when noone is testing/fixing the result really such a good thing?  (Hello
Windows XP, I hear tomorrow is your deathday...please tell your users)

Supporting things far beyond their own EOL date feels a bit like jumping in
beside someone digging themselves into a hole to lend them an extra pair of
hands to speed things up :)


> Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all familiar with
> JMS 2.0, so I'm interested what key things have changed and what new stuff
> it depends on. Is the implication of this that the new AMQP 1.0 JMS client
> that you guys are working on will be JMS 2.0 only? I noticed that the
> pom.xml in there specifies Java 7 already - I guess that's your none to
> subtle hint ;->
>
>
It is indeed to be a JMS 2.0 client and thus the 1.7 in the pom isnt a hint
but rather a requirement; as Rob mentioned the JMS 2.0 API make use of the
try-with-resources language feature, which is strictly Java7+

(obviously that isnt to say you can't do things like hack the bytecode
after the fact to make it work with Java 6, but...lets not get crazy)


>
> Hmm you could probably make similar arguments for adopting C++11 - not
> least because Boost version dependencies suck, but there are still a ton of
> people (myself included at the moment) with older systems - though to be
> fair upgrading C++ compilers tends to be harder than upgrading Java
> versions for any given OS version.


Especially if you arent talking about package manager installations. One is
really really easy, is the other? :)


> It's interesting that Proton (well Proton-C at any rate) seems to be
> taking a very different tack where it seems to be actively trying to
> minimise dependencies on anything new and shiny - I'm pretty sure I saw a
> Jira the other day for changing send.c and recv.c because they were C99 and
> broke on Windows builds that needed good old C89 :-D
>
> Just being a bit Devils' advocate to mix things up a bit, as I say I'm
> personally agnostic :-)
>
> Frase
>
>
>
> On 07/04/14 17:33, Robbie Gemmell wrote:
>
>> I think this makes sense. We waited too long to drop support for Java 5,
>> lets not repeat that with 6. Beginning to depend on Java 7 after three
>> years doesnt seem unreasonable to me.
>>
>> Those those who 'cant' or dont want to upgrade to such 'new' (i.e really
>> quite old now) Java releases are often likely to be the same ones that
>> aren't so likely to use the latest Qpid releases either.
>>
>> Robbie
>>
>> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
>>
>>  All,
>>>
>>> now that Java 8 has been released, and Java 6 has been officially EOLd
>>> for
>>> well over a year, I'd like to propose that we make 0.28 the last release
>>> for which we officially support Java 6.  As a library provider I'm aware
>>> that we need to strive to make our libraries as widely adoptable as
>>> possible, but not adopting Java 7 also holds us back from implementing
>>> functionality that requires features of later releases (as JMS 2.0 does).
>>>
>>> Java 7 was released in 2011 and is itself scheduled to be EOLd next year.
>>>
>>> If we do later find critical defects that affect the 0.28 release we
>>> should
>>> consider back-patching to a Java 6 release based on 0.28, however I don't
>>> think requiring that all new functionality releases require the adoption
>>> a
>>> version of Java that Oracle supports to be an undue burden.
>>>
>>> -- Rob
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: [Proposal] Ending Support for Java 6

[Fraser Adams <fr...@blueyonder.co.uk>]

I think that this definitely needs input from the broad community. I can 
see where you're coming from, but my observations of large Enterprises 
(which TBH are often the main consumers of Messaging products) are that 
they are often in a difficult position wrt. keeping up with the times. 
Don't talk to me about IE8 for example!! There's a whole *industry* of 
polyfills because Enterprises won't or can't upgrade.

I don't think that your comment "Those those who 'cant' or dont want to 
upgrade to such 'new' (i.e really quite old now) Java releases are often 
likely to be the same ones that aren't so likely to use the latest Qpid 
releases either" necessarily holds, often things like compiler versions 
get corporately mandated whereas there might be less control exerted on 
libraries. I've got painful memories of being stuck on Java 3 when the 
world had moved to Java 5, this stuff is not as simple as you seem to think.

I'm quite impressed that your own organisation has migrated to Java 7


I'm *personally* fairly agnostic on this I just think that it's 
important to bear in mind how large Enterprises often operate.

(Lack of) what features are causing you the most pain? Just curious 
really. Rob mentioned "as JMS 2.0 does" in his mail, I'm not at all 
familiar with JMS 2.0, so I'm interested what key things have changed 
and what new stuff it depends on. Is the implication of this that the 
new AMQP 1.0 JMS client that you guys are working on will be JMS 2.0 
only? I noticed that the pom.xml in there specifies Java 7 already - I 
guess that's your none to subtle hint ;->


Hmm you could probably make similar arguments for adopting C++11 - not 
least because Boost version dependencies suck, but there are still a ton 
of people (myself included at the moment) with older systems - though to 
be fair upgrading C++ compilers tends to be harder than upgrading Java 
versions for any given OS version. It's interesting that Proton (well 
Proton-C at any rate) seems to be taking a very different tack where it 
seems to be actively trying to minimise dependencies on anything new and 
shiny - I'm pretty sure I saw a Jira the other day for changing send.c 
and recv.c because they were C99 and broke on Windows builds that needed 
good old C89 :-D

Just being a bit Devils' advocate to mix things up a bit, as I say I'm 
personally agnostic :-)

Frase


On 07/04/14 17:33, Robbie Gemmell wrote:
> I think this makes sense. We waited too long to drop support for Java 5,
> lets not repeat that with 6. Beginning to depend on Java 7 after three
> years doesnt seem unreasonable to me.
>
> Those those who 'cant' or dont want to upgrade to such 'new' (i.e really
> quite old now) Java releases are often likely to be the same ones that
> aren't so likely to use the latest Qpid releases either.
>
> Robbie
>
> On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:
>
>> All,
>>
>> now that Java 8 has been released, and Java 6 has been officially EOLd for
>> well over a year, I'd like to propose that we make 0.28 the last release
>> for which we officially support Java 6.  As a library provider I'm aware
>> that we need to strive to make our libraries as widely adoptable as
>> possible, but not adopting Java 7 also holds us back from implementing
>> functionality that requires features of later releases (as JMS 2.0 does).
>>
>> Java 7 was released in 2011 and is itself scheduled to be EOLd next year.
>>
>> If we do later find critical defects that affect the 0.28 release we should
>> consider back-patching to a Java 6 release based on 0.28, however I don't
>> think requiring that all new functionality releases require the adoption a
>> version of Java that Oracle supports to be an undue burden.
>>
>> -- Rob
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: [Proposal] Ending Support for Java 6

[Robbie Gemmell <ro...@gmail.com>]

I think this makes sense. We waited too long to drop support for Java 5,
lets not repeat that with 6. Beginning to depend on Java 7 after three
years doesnt seem unreasonable to me.

Those those who 'cant' or dont want to upgrade to such 'new' (i.e really
quite old now) Java releases are often likely to be the same ones that
aren't so likely to use the latest Qpid releases either.

Robbie

On 7 April 2014 13:17, Rob Godfrey <ro...@gmail.com> wrote:

> All,
>
> now that Java 8 has been released, and Java 6 has been officially EOLd for
> well over a year, I'd like to propose that we make 0.28 the last release
> for which we officially support Java 6.  As a library provider I'm aware
> that we need to strive to make our libraries as widely adoptable as
> possible, but not adopting Java 7 also holds us back from implementing
> functionality that requires features of later releases (as JMS 2.0 does).
>
> Java 7 was released in 2011 and is itself scheduled to be EOLd next year.
>
> If we do later find critical defects that affect the 0.28 release we should
> consider back-patching to a Java 6 release based on 0.28, however I don't
> think requiring that all new functionality releases require the adoption a
> version of Java that Oracle supports to be an undue burden.
>
> -- Rob
>