-
Notifications
You must be signed in to change notification settings - Fork 470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop support for Java 6 #530
Comments
This decision shouldn't be taken lightly. Many (probably most) users in the corporate world are still on Java 6/7, and have support contracts that last for years to come. Only the "unsupported" versions of Java 6/7 have reached EOL. |
Yes Premier Support for Java 6 will end in Dec 2015 and Extended Support will in end Dec 2018. The question is, if those users are so locked down are they even using spock/groovy? And if they are using both, can they even update to new spock/groovy versions and would be affected. The problem we have, is that we don't really know our users and their environments and we have no effective way of reaching most of them. If we would decide to drop support with version 2.0, we could add some code that is triggered on Java 6 which logs once to std.err that support for Java 6 is deprecated and will be dropped in the next major release. Gradle does something similar for deprecated features. |
Do we really need any features from Java7? Try-with-statement? Switch with Strings? |
+1 for dropping support of Java 6. It’s dead for two years, so it’s still used only in backward corporations that pay for absurdly long support of ancient versions… and so they can pay you to maintain backward compatible version for them, if they need it. ;) It’s IMHO unreasonable to suffer for maintaining too long backward compatibility for those people. |
I do know several high-profile users who are still on Java 6. Updating to newer Groovy versions is usually not a problem for them; often, they only use Groovy through Spock. Java EE users are on 7 in the best case. Also, many libraries, frameworks, and tools (e.g. Gradle) still run Java 6 builds/tests, e.g. to prove their Java 6 compatibility. No reason to cause hassles for them. To summarize, I'd prefer not to see Java 6 dropped in 1.x - more to lose than to win. Dropping Java 6 in 2.0 sounds more reasonable. |
I agree with Peter. |
Implemented with #725 |
Source
Since the end of life for Java 6 was more than two years ago, I would vote for dropping Java 6 support and moving the code base to Java 7. Although even Java 7 has already reached its EOL date, I think that we still have enough users on Java 7 to justify not directly switching to Java 8.
The text was updated successfully, but these errors were encountered: