raise minimum jdk to 1.7

[lkwg82]

It is set to 1.5 in parent pom and I think this makes too much very complicate. (Compatibility is a burden)

Supporting only last and current version seems to be reasonable to me.

What is you opinion?

[hcoles]

Pitest is used with legacy codebases tied to 1.5. Support was dropped briefly but this generated complaints and it was re-introduced (see #155)

The main pain caused by 1.5 support is the lack of support on the free CI servers + the way the overrides annotation behaves.

Big gains would be made if the codebase could be moved to java 8 as tracked in #164

Unfortunately when I last looked retrolambda seemed to output bytecode that ASM considered invalid.

1.5 obviously can't be supported indefinitely, but there isn't currently target release at which support will be dropped again.

Perhaps move to a minimum of Java 6 in 1.1.8?

[lkwg82]

And this project tied to java 1.5 is critical for pitest? How many projects are tied to java 1.5?

When this particular project uses pitest, it means there is active development. So this means there is active development of a project which are continiuously updating pitest to the latest version, but they dont move the last supported jdk?? This sounds really strange.

I suggest this project should stay with an older version of pitest and keep moving the really important parts first.

What about dropping 1.5 support in the next release, 1.6 in two or three releases to catch up with recent versions. Else this plugins get a legacy codebase itself.

Cheers Lars

(Same opinion with maven2)

[mbj]

I suggest this project should stay with an older version of pitest and keep moving the really important parts first.

What about dropping 1.5 support in the next release, 1.6 in two or three releases to catch up with recent versions. Else this plugins get a legacy codebase itself.

@hcoles I do exactly the same with mutant. Asking people to stay with older versions. I dropped < ruby-2.0 support for mutant half a year ago.

[lkwg82]

After April 2015, Oracle will no longer post updates of Java SE 7 to its public download sites.

https://www.java.com/en/download/faq/java_7.xml

Supporting java 5 is just a waste of your valuable time, except you make a business with that support.

[hcoles]

Java 5 support will be dropped in release 1.1.7 - this gives anyone still using java 5 adequate notice.

As for java 6. . .

Pitest is used in a wide range of projects both greenfield and legacy.

It is common for legacy codebases to be tied to archaic versions of Java. The reasons are often political rather than technical - but this still prevents the upgrade.

It sounds like you've been lucky enough never to have worked with legacy codebases. I've been there and although I've now moved on I will continue to support teams dealing with legacy code as much as possible.

I'm aware of a number of teams using pitest that are currently tied to java 6, several of them at companies I know locally. A timescale for a move to Java 7 will be set when I understand their upgrade plans.

[lkwg82]

Ok.

No I've been worked with some legacy code base projects. It has been always hard to discuss on technical debts. But I recognized keeping old versions for political reasons is organisational deficite. It is a wrong workaround in the same nature of discussions on 'code quality' vs. 'new features'. There is no versus. New features come much more easier with code quality. New features will stop coming with bad code quality. I dont like to start that kind of discussion.

Dont give them reasons to stay with these version. (If you are not involved in any of these projects.)
Sometimes or maybe more often it is the question who will move first. When there is no support for these legacy versions, the political party loses ground. They are pushed to decide, make the transition it or stop the project.

If it not your problem dont let it be your problem. I really appreciate your work and I'd like to contribute some refactorings. But I'm not able to make them. Because I dont know what I will break.

Cheers Lars

[StefanPenndorf]

At my job we still have a Java 6 based project (running on Websphere 7 in production). The production environment is maintained by our customer's administrators. Thus we depend on the environment which they specify. There is a upgrade plan to Websphere 8.5 / Java 7 going to production in April 2016.

We will start to work on the Java 7 based version in October this year. @hcoles If you think about dropping Java 6 support: I don't mind if we are fixed to current pitest for some months because there are no known issues with the current version.

Maybe it's worth raising the version to 1.2.0 for the upgrade dropping Java 5 support. That would also be a stronger signal for those thinking about an upgrade. If there are really critical issues there could be a 1.1.x to backport them with Java 5 support.

[hcoles]

As long as the free CI servers continue support it, supporting java 6 does not have a great cost. No try with resources, no diamond operator, no multi catch . . . that's about it.

The benefit of supporting it is that mutation testing is easily accessible to the teams still tied to it. There are currently lots of those, including some at my current employer.

When changes on one or both sides of this equation alter the balance java 6 support will be dropped.

Even if this balance does not change I agree that java 6 support can't continue indefinitely (and java 5 support has gone on a little too long) - but the earliest this could be looked at would be 2016.

[hcoles]

@KyleRogers My condolences on websphere.

[lkwg82]

It just came to my mind, that we did not clarify whether we talk about source version or target version.

I meant source version.

Sry my fault :(. Talking about (maybe) different things like experts ;)

[lkwg82]

I see, that I cant do. I just raised to 6.

[hcoles]

Ok, I've put an announcement out on the mailing list that java 5 support will be dropped for good after one more release.

@lkwg82 I had a look a while back at targeting lower bytecode from higher source a while back, but it doesn''t seem to be possible even with alternate compilers. The only route to do this at the moment looks to be retrolambda, which unfortunately I hit other issues with.

[lkwg82]

When I understand the animal sniffer output correctly, java5 support is already dropped and we can wait for this bug ;) See my jdk6 pr. Else this code is unused. So announcing end of java5 support is kind of ironic. But announcing for past releases is impolite.

[alexec]

I'd vote against 1.7. We use 1.6 and are not moving any time soon. :(

[lkwg82]

What are your reasons to not move on? What is your business - what is the environment the decision lives in?

[hcoles]

It's finally time to look at this again.

Most teams at my current employer are on the way to Java 8, so my proposal is to drop support for running on both Java 6 and 7 shortly after the release of Java 9.

Java 5,6 and 7 bytecode would still be supported.

One concern is that Pitest is commonly used for academic research, often analysing a corpus of open source software of varying age. I'm not clear if researchers are tied to older versions of Java or if it is normal to analyse using Java 8.

If anyone from the research community could comment on what the normal practice is it would be helpful.

[mbj]

One concern is that Pitest is commonly used for academic research, often analysing a corpus of open source software of varying age. I'm not clear if researchers are tied to older versions of Java or if it is normal to analyse using Java 8.

Couldnt these people use an older version of pitest?

[hcoles]

@mbj If this answer is that they're tied to older Java versions then at some point it will come to that, but I'd prefer to know if I'm locking the academic community out of future releases before I make that decision.

[hcoles]

The next release will raise the minimum Java version to 7.

[maxgabut]

Minimum java version in now version 8.