Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Upgrade to Java 7 (was 8) #872
added a commit
this pull request
Feb 15, 2016
Since all code was written according to Java 6, it does compile with Java 7. However, this opens the door to Java 8 features. I plan on writing Java 8 compliant code as of now :).
Since both Java 6 and Java 7 are considered End-of-life, it seems okay to jump to Java 8 directly, skipping Java 7 altogether.
One, can we explore the Java 8 changes in a branch? That way we can
Alternately, tag and branch Java 6 support and keep it on maintenance life
I must admit, while I'm really just doing cucumber lately, I'm stuck on
This is a volunteer operation with people doing this in their spare time.
Just my thoughts.
On February 22, 2016 at 8:33:22 AM, anis (email@example.com) wrote:
Agree - make a Java 6 branch so we can make fixes if required.
On 2016-02-22 07:44, Dan Woodward wrote:
Another option is to switch back to Java 7 (as proposed by #877), which is quite easy to do still. Things that can be improved in Java 8 can be tagged with TODO statements. That way we can get an overview of where Java 8 will add benefit.
We can still make a maintenance branch for Java 6, just in case. We can set up a build job to make maintenance versions.
@six42 Won't that make things more difficult? Apart from the bytecode version (which is manageable) we also need to restrict the JDK functionality we use.
I think it's also possible to make Java 8 compiled downside compatible with Java 7. I don't know how though.
Dipl.-Inform. Markus Gärtner
@amolenaar I support your last option.
Concerning Java 8: I suggest binding that to some refactorings / refreshs of fitnesse , s.th like FitNesse Next Generation.
@six42 I think also that would make things more complicated
The way I see it is we have mainly two components:
The Wiki server anybody can use Java 8. At least I don't see a reason why not.
The test clients must use the same version as the System Under Test as they run in process. I understand that people are forced to use older versions.
.Net and most other test clients are maintained in separat projects. In other words we have a clear segregation of the code.
Slim and Fit are maintained together with the Wiki server and the code and test cases are maybe less segregated than they should be.
I see this as a good opportunity to restructure the code base.
The test clients should be build with support for Java 6.
The promise of Fitnesse is that it is easy to create new test clients in other languages. Therefor I would expect that the test client code base is small.
I would further expect that the test client will not change often as any fundamental change would need to be reflected in the .Net and other test clients as well.
What is the impact for users which need to test with Java 6?
What about the junit test runner?
What is the overall benefit of this approach?
•I think it would help to get a cleaner design and code base.