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 <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
