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 <[email protected]> wrote: > On 7 April 2014 19:30, Fraser Adams <[email protected]> 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] > > > > >
