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