Hi Rob, People always need a proper motivation to upgrade from outdated Java to something newer ... and you can motivate them. (I know, this is not really the objection you are asking for)
A bit to my surprise, so far nobody from my colleagues seemed to have problem with this idea. I guess it must be because most of our Java applications are fairly new and the real legacy projects run on much older technologies than Java 6 :-). Regards Jakub On Wed, Apr 9, 2014 at 10:51 PM, Rob Godfrey <[email protected]>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] > > > > > > > > >
