Java 8

[sskorol]

Hi @cbeust,

Wondering if you're planing to switch TestNG to default 1.8 source / target in the nearest future? Lots of things could be implemented much easier using Java 8 features. It's quite stable now. On the other hand, 1.7 version is not officially supported anymore. Any thoughts on this?

[cbeust]

Hi @sskorol,

There are still a lot of TestNG users on 1.7 so I have to keep 1.7 as the minimum level for now...

[sskorol]

@cbeust wondering if you want to conduct а survey among testng-users about this... would be great to see actual java version usage stats, and ask if people could or want to move to 1.8 version... just a suggestion... :)

[cbeust]

I'm not sure a survey would be a good indicator for that: most of TestNG users are working in corporations and probably don't even read the mailing-list...

The few times I made the mistake of cutting a release accidentally compiled with 1.8, I usually start receiving angry emails within the hour...

[sskorol]

This is quite strange, as users, which really care about testng updates, should always track release notes, news, etc. If corporate users just blindly update versions without looking at what has changed, I don't believe they really need new features. On the other hand, if they don't know what they're updating, they could face with new bugs or break some existing functionality, dependent from particular testng version. Anyway, of course it's up to you, but it could be just a long term announcement / survey within different communities, that e.g. since 7.0.0 version testng will be officially moved to 1.8 version. Something like JetBrains did, when they decided to move to new licence policy. They opened this topic on end-users level to collect feedback. You can do the same to decide, what is better - to update or not. Java 8 itself won't break anything written using 7 version, unless you have some pretty old dependencies or didn't even install it in system.

[juherr]

We already lost users with the java 7 switch. I'm really not sure another one will be so good.

[sskorol]

@juherr yes, you may lose old-school guys, who like sitting on ancient technologies, until getting retired... there's also a risk to lose another category of version-restricted users as well... but how many new young users, who don't afraid innovations you'll gain?.. it's more about philosofical context, but... if we look at this question from new committers involvement angle, what's the probability that young perspective professionals, which use java 8, would want to figure out with huge amount of code for creating java 7 restricted PRs?.. and what's the probability to find new active committers among old-school guys?.. these are ritorical questions...

[juherr]

I'm not sure you understand the situation. Many users, young or old, can't choose their production platform. Some of them have to use old java version for good and bad reasons. I'm not sure we can blame them.

Then I'm not sure java7 is a problem for contributors. For example, JUnit and many apache projects are still using java5 and have a lot of contributors.

[sskorol]

@juherr I'm not blaming anyone... I'm just talking about innovations. Big legacy projects may exist for dozen years without any platform upgrade. And what? Lots of new projects appear each day, which use new technologies. And from developer's perspective, if I have to choose between JUnit and TestNG, and see that e.g .TestNG supports Java 8, my choice will be pretty obvious, as it simply means that this project is still alive and has a big future.

Regarding contributors... When you ask someone - do you want to create a PR with suggested feature? He looks at code and understands that with Java 8 it could be written in 5 lines, but in case of Java 7 it'll take 2 hours of workarounds and deep testing. It also means that since his PR is merged, he's responsible for this piece of code and has to support it for a long time. Would he waste his time on this? With Java 8 - most likely, otherwise - no.

If you've already played with Java 8, you know which advantages it gives you and how it decreases development time.

Well, makes no sense to continue this holy war discussion. I see your point, but unfortunately I cannot share your optimism about keeping Java 7 support forever. :)

Thanks for your time.

[cbeust]

@sskorol You need to realize that most Java users (not just TestNG users) work in corporations and these are very slow and very deliberate in adopting new technologies. You would be shocked to hear how much Java code still runs on Java 1.7 and even 1.6 (as @juherr said, we already received a lot of heat when TestNG stopped supporting 1.6 a few months ago, a version that has been dead for years).

if I have to choose between JUnit and TestNG, and see that e.g .TestNG supports Java 8

Not sure what you mean by "support". TestNG works just fine with 1.8 and plenty of users are writing tests with the 1.8 features. I don't really understand the urge to move that bar up to 1.8, there is very little to gain.

I made the decision to abandon 1.6 when it became too painful to support it, that's pretty much the only driver.

[sskorol]

@cbeust I'm working on a project, which is based on Java 7. So I know what are you talking about. :) However, devs use JUnit. But personally I prefer TestNG. And my automated tests are based on TestNG.

By "support" I meant being able to contribute using Java 8 features, not just creating tests for my own projects. I'm using Java 8 for more than a year, and I know how much time it saves me.

Anyway, thanks for the great library! Hope it'll be updated to 1.8 source / target someday. :)

[cbeust]

It will definitely be updated to Java 1.8, for sure!

Thanks for taking the time to discuss this.

[krmahadevan]

@cbeust and @juherr - I was just going through the TestNG issues and stumbled into this issue. Its now been a year since JDK8 was discussed here. Has anything changed in the decision to move to JDK8 ? Just fishing for places wherein I can try contributing :)

[cbeust]

I'm still not seeing any urgency to switch to JDK 8 but I'm open. The cons are obvious (we would leave users behind) but what are the pros?

I know what JDK 8 brings, I'm just not sure what it adds for TestNG specifically.

[krmahadevan]

Thanks for the reply Cedric. I am not completely aware of all the features of JDK8. I was just trying to see if I should start exploring JDK8 features and get familiar with them (incase TestNG is going to use it).

[sskorol]

Guys, JDK 9 is coming, and you're still wondering if it makes sense switching to 1.8? :) Even JUnit has already switched to Java 8.

[FibreFoX]

A more proper question would be how TestNG might get improvements with conversion to Java 8? I personally don't see any need to have this testing-framework requiring a bump from version 7.

Is there any technical reason other than "Java 7 got out of support"? Since TestNG even works with Java 8 there is currently no need for pushing version requirement. :) just my own thoughts to this topic

[cbeust]

Yes I am. It's a simple cost/benefit analysis. As I said above, right now, I only see downsides in requiring Java 8. Current Java 8 users don't care but Java 7 users will no longer be able to upgrade so it makes sense to stick to Java 7.

I'm happy to hear arguments that would improve TestNG and/or TestNG user experience if we make Java 8 mandatory.

Cédric

On Sat, Nov 5, 2016 at 10:37 AM, Sergey Korol notifications@github.com wrote:

Guys, JDK 9 is coming, and you're still wondering if it makes sense switching to 1.8? :) Even JUnit has already switched to Java 8.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cbeust/testng/issues/864#issuecomment-258628642, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFooskQrieNHDb_sCFx5TKV8OgX594eks5q7L6_gaJpZM4Gf0hF .

[juherr]

@sskorol JUnit has switched to Java 8 because they found resources to rewrite it from scratch with java8 in mind but JUnit 4 is still active.

[slanglois]

TestNG 6.11 is still built to work with Java 1.7, but it now depends on JCommander 1.64, which doesn't work on it and requires Java 1.8. Is that expected?

[juherr]

@slanglois See #1377 and #1369

[sskorol]

@juherr @FibreFoX, ok, I got your points.

I have just couple of questions for you. Have you already checked Java 8 features? Have you tried them on any of your active projects?

If not, there's nothing to discuss, and that's a waste of time for all of us.

If yes, just take a look at any class, which currently uses collections, and tell me that it can't be refactored in a more concise and efficient way via Stream API instead of loops and other ancients like anonymous classes, huge comparators, etc. Tell me that tons of if (x != null) checks can't be replaced with Optional API. Tell me that FunctionalInterfaces as a part of behavior parametrization concept won't help avoiding code duplication and make your code more flexible and extensible. Tell me that default methods won't give any flexibility while interfaces' extension. Tell me that Java 8 doesn't have any positive impact on some common design patterns.

Moving to Java 8 doesn't really mean that everything must be refactored in 1 week. But contributors would at least have a chance to write more efficient, concise and flexible code.

[juherr]

@sskorol I'm using Java8 for my projects but I still don't see any good reason to move to Java8 for the TestNG core because we want to continue to support users who didn't move yet, and we had already a bad experience with the drop of the support of Java5/6, and we are too few person to be able to support 2 branches at the same time.

But feel free to propose any API improvements which can help to use TestNG for Java8 users.

[cbeust]

@sskorol You don't need to convince me the code base would benefit a lot from Java 8, but the reason TestNG is still using 1.7 is because a lot of users are still using it.

[mouyang]

Until TestNG starts requiring Java 8, it may be beneficial to have a separate library that takes advantage of Java 8 features. One example of such a feature would be assertAll from JUnit 5. It provides more information about a failure (all assertions that failed as opposed to only the first one) but it would likely be much easier to implement with Java 8 than without.

[juherr]

@mouyang TestNG has already SoftAssert for that purpose.

[cbeust]

And I like to think I came up with the idea in the first place :-)