Hi Nick, On Fri, Jan 30, 2015 at 3:22 AM, <dev-digest-h...@tika.apache.org> wrote:
> > The problem is that Tika has three kinds of users: > > You forgot about people who use and love Tika on their chicken. Mmmmmmm yum yum nom nom. I am starving. Tika on my chicken satay nom nom nom. > > People in the first two categories can move to a newer JVM fairly easily, > if they aren't already on one. Those in the latter category find it a huge > amount of effort to upgrade their JVM, sometimes almost impossible to do. > If we move to a newer JVM, we'll loose those people > Seriously though, I don't think we do. I am not convinced that projects seriously consider pegging everything at Java 1.6 to avoid loosing an unknown number of users of large anonymous frameworks unknown to the community developing the tool. If people cannot upgrade a JVM on pools of machines with a rolling upgrade just like they do with everything else then there are serious problems in that particular organization that need to be tackled and addressed. IMHO this is not something we should be particularly concerned with. > > By users on the lists, I'd suspect most are in categories 1 and 2. By > overall users, it's quite possible that category 3 wins, so we do need to > take care of their interests too! > What are their interests though? > > > As an example, Alfresco only moved to requiring Java 7 with Alfresco 4.2, > 4.1 (still quite widely installed, and very much still supported) has a > minimum of Java 6. If we move to Java 7, that'll mean that if there's an > Alfresco bug traced back to Tika, they'll have to backport it into a > private branch of Tika that's 1.6 compatible. It'll also mean they'll be > less inclined to move to a newer Tika, as it'd mean more support hassle if > some versions of Alfresco are on stock Tika $latest, and others are on a > private older branch. Alfresco are generally quite good as vendors go, so > expect many other large systems bundling Tika to be much much worse... > My opinion is that as an open source project we should not be deterred from progressing the development of volunteer effort due to things like you have described above. If infrastructure level vendors have issues with their development cycle and they need to address that. Please note that the Oracle announcement I cited dates back to Aug, 2012. This is not recent news. If commercial companies can't schedule an upgrade from Java 1.6-1.7 over a period of some 3 years then there is something wrong. My 92 year old grandmother could learn to do a rolling upgrade of Java in 3 years. (I cannot verify this, my grandmother ay even be dead as I type this, I've not seen her in around 3 or so years thank god.) > > I'm not saying "don't upgrade", just trying to make sure everyone's aware > of what we loose + what problems we cause for our users, so it can be > correctly weighed up against the benefits! > Benefits are that we continue with development alongside countless other projects who are moving with the times. Con's are that some commercial entities (and non-commercial entites) find this a PITA for a while until they start planning for rolling upgrades to their products 3 years after the end of life support was announced. It is called end of life for a reason... namely because it is the end of it's life. :) > > Oh, and don't forget that Java 6 is still supported for another 23 months, > for those willing to pay (and I believe there are many who do!) > > I think it would be to our advantage to make an upgrade to Java 1.7. If it does not work for 1.8, then we can push a 1.8.1 which reverts the change. No harm done. The release announcement needs to state that you should now use >= Java 1.7. We can verify this with our Jenkins builds. Thanks Nikc, looking forward to catching you up for a Whisky at ApacheCon. Lewis
