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