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