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

Upgrade to Java 7 (was 8) #872

Merged
merged 4 commits into from Feb 15, 2016

Conversation

Projects
None yet
6 participants
@amolenaar
Collaborator

amolenaar commented Feb 12, 2016

No description provided.

@amolenaar amolenaar added this to the Next release milestone Feb 12, 2016

@amolenaar amolenaar merged commit b7a352a into unclebob:master Feb 15, 2016

amolenaar added a commit that referenced this pull request Feb 15, 2016

@benhamidene

This comment has been minimized.

Show comment
Hide comment
@benhamidene

benhamidene Feb 22, 2016

Contributor

Hi @amolenaar ,

it is yet possible to build fitnesse with Java 7 .. so is Java 8 really necessary?
or are you preparing for future changes and usage of Java 8 features ?

Contributor

benhamidene commented Feb 22, 2016

Hi @amolenaar ,

it is yet possible to build fitnesse with Java 7 .. so is Java 8 really necessary?
or are you preparing for future changes and usage of Java 8 features ?

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Feb 22, 2016

Collaborator

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.

Collaborator

amolenaar commented Feb 22, 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.

@benhamidene

This comment has been minimized.

Show comment
Hide comment
@benhamidene

benhamidene Feb 22, 2016

Contributor

"Java 6 and Java 7 are considered End-of-life" .. that´s right
but they are still living as Standards in many projects and Java 8 is still a far future for some of them ;)

Contributor

benhamidene commented Feb 22, 2016

"Java 6 and Java 7 are considered End-of-life" .. that´s right
but they are still living as Standards in many projects and Java 8 is still a far future for some of them ;)

@benhamidene

This comment has been minimized.

Show comment
Hide comment
@benhamidene

benhamidene Feb 22, 2016

Contributor

We could continue the discussion in the pull request 877 :)

Contributor

benhamidene commented Feb 22, 2016

We could continue the discussion in the pull request 877 :)

@woodybrood

This comment has been minimized.

Show comment
Hide comment
@woodybrood

woodybrood Feb 22, 2016

Collaborator

Two options.

One, can we explore the Java 8 changes in a branch? That way we can
implement and demonstrate the value of Java 8 support. Then the main line
would be mostly bug fixes and contributions.

Alternately, tag and branch Java 6 support and keep it on maintenance life
support for folks who can't move up.

I must admit, while I'm really just doing cucumber lately, I'm stuck on
both my cucumber version and my selenium version due to being still at Java
6 myself.

This is a volunteer operation with people doing this in their spare time.
So we can't meet everyone's needs, but providing a clear path for users
stuck at a very clear and real infection point could be good enough. The
reality is that users who can't move forward might have to contribute some
of their own fixes for the Java 6/7 branch. They may not have access to
features added through Java 8, but they also won't be locked out or forced
to fork just to get a fix for the editor or such.

Just my thoughts.

Dan Woodward
Sent with Airmail

On February 22, 2016 at 8:33:22 AM, anis (notifications@github.com) wrote:

We could continue the discussion in the pull request 877 :)


Reply to this email directly or view it on GitHub
#872 (comment).

Collaborator

woodybrood commented Feb 22, 2016

Two options.

One, can we explore the Java 8 changes in a branch? That way we can
implement and demonstrate the value of Java 8 support. Then the main line
would be mostly bug fixes and contributions.

Alternately, tag and branch Java 6 support and keep it on maintenance life
support for folks who can't move up.

I must admit, while I'm really just doing cucumber lately, I'm stuck on
both my cucumber version and my selenium version due to being still at Java
6 myself.

This is a volunteer operation with people doing this in their spare time.
So we can't meet everyone's needs, but providing a clear path for users
stuck at a very clear and real infection point could be good enough. The
reality is that users who can't move forward might have to contribute some
of their own fixes for the Java 6/7 branch. They may not have access to
features added through Java 8, but they also won't be locked out or forced
to fork just to get a fix for the editor or such.

Just my thoughts.

Dan Woodward
Sent with Airmail

On February 22, 2016 at 8:33:22 AM, anis (notifications@github.com) wrote:

We could continue the discussion in the pull request 877 :)


Reply to this email directly or view it on GitHub
#872 (comment).

@jediwhale

This comment has been minimized.

Show comment
Hide comment
@jediwhale

jediwhale Feb 22, 2016

Collaborator

Agree - make a Java 6 branch so we can make fixes if required.

On 2016-02-22 07:44, Dan Woodward wrote:

Two options.

One, can we explore the Java 8 changes in a branch? That way we can
implement and demonstrate the value of Java 8 support. Then the main line
would be mostly bug fixes and contributions.

Alternately, tag and branch Java 6 support and keep it on maintenance life
support for folks who can't move up.

I must admit, while I'm really just doing cucumber lately, I'm stuck on
both my cucumber version and my selenium version due to being still at
Java
6 myself.

This is a volunteer operation with people doing this in their spare time.
So we can't meet everyone's needs, but providing a clear path for users
stuck at a very clear and real infection point could be good enough. The
reality is that users who can't move forward might have to contribute some
of their own fixes for the Java 6/7 branch. They may not have access to
features added through Java 8, but they also won't be locked out or forced
to fork just to get a fix for the editor or such.

Just my thoughts.

Dan Woodward
Sent with Airmail

On February 22, 2016 at 8:33:22 AM, anis (notifications@github.com) wrote:

We could continue the discussion in the pull request 877 :)


Reply to this email directly or view it on GitHub
#872 (comment).


Reply to this email directly or view it on GitHub
#872 (comment).

Cheers,
Mike Stockdale

/fit/Sharp http://fitsharp.github.com

Collaborator

jediwhale commented Feb 22, 2016

Agree - make a Java 6 branch so we can make fixes if required.

On 2016-02-22 07:44, Dan Woodward wrote:

Two options.

One, can we explore the Java 8 changes in a branch? That way we can
implement and demonstrate the value of Java 8 support. Then the main line
would be mostly bug fixes and contributions.

Alternately, tag and branch Java 6 support and keep it on maintenance life
support for folks who can't move up.

I must admit, while I'm really just doing cucumber lately, I'm stuck on
both my cucumber version and my selenium version due to being still at
Java
6 myself.

This is a volunteer operation with people doing this in their spare time.
So we can't meet everyone's needs, but providing a clear path for users
stuck at a very clear and real infection point could be good enough. The
reality is that users who can't move forward might have to contribute some
of their own fixes for the Java 6/7 branch. They may not have access to
features added through Java 8, but they also won't be locked out or forced
to fork just to get a fix for the editor or such.

Just my thoughts.

Dan Woodward
Sent with Airmail

On February 22, 2016 at 8:33:22 AM, anis (notifications@github.com) wrote:

We could continue the discussion in the pull request 877 :)


Reply to this email directly or view it on GitHub
#872 (comment).


Reply to this email directly or view it on GitHub
#872 (comment).

Cheers,
Mike Stockdale

/fit/Sharp http://fitsharp.github.com

@six42

This comment has been minimized.

Show comment
Hide comment
@six42

six42 Feb 22, 2016

Contributor

How about if the slim client supports java 6, 7 and 8
but the wiki requires Java 8?

Contributor

six42 commented Feb 22, 2016

How about if the slim client supports java 6, 7 and 8
but the wiki requires Java 8?

@amolenaar amolenaar deleted the amolenaar:java8 branch Feb 23, 2016

@amolenaar

This comment has been minimized.

Show comment
Hide comment
@amolenaar

amolenaar Feb 23, 2016

Collaborator

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.

Collaborator

amolenaar commented Feb 23, 2016

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.

@mgaertne

This comment has been minimized.

Show comment
Hide comment
@mgaertne

mgaertne Feb 23, 2016

Collaborator

I think it's also possible to make Java 8 compiled downside compatible with Java 7. I don't know how though.

Best Markus

Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

On 23.02.2016, at 10:42, Arjan Molenaar notifications@github.com 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.


Reply to this email directly or view it on GitHub.

Collaborator

mgaertne commented Feb 23, 2016

I think it's also possible to make Java 8 compiled downside compatible with Java 7. I don't know how though.

Best Markus

Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

On 23.02.2016, at 10:42, Arjan Molenaar notifications@github.com 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.


Reply to this email directly or view it on GitHub.

@benhamidene

This comment has been minimized.

Show comment
Hide comment
@benhamidene

benhamidene Feb 23, 2016

Contributor

@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.
It´s time to start changing basic things like a modern slim protocol , a modern thread and process handling , a better and scalable webserver implementation.

@six42 I think also that would make things more complicated

Contributor

benhamidene commented Feb 23, 2016

@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.
It´s time to start changing basic things like a modern slim protocol , a modern thread and process handling , a better and scalable webserver implementation.

@six42 I think also that would make things more complicated

@six42

This comment has been minimized.

Show comment
Hide comment
@six42

six42 Feb 23, 2016

Contributor

The way I see it is we have mainly two components:
• The Wiki server
• Test clients: slim, fit, .net, powershell, C, ...

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 wiki with Java 8.
I would expect that a Fitnesse contributor can build both with only JDK 8 installed and that the compiler would block using Java 8 features in the test client code.

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?
The only thing they need to do is re-define the "CommandRunner" variable to ensure that JRE 6 is used.

What about the junit test runner?
I never used it and never looked how it works. Not sure if it must be written in Java 6 or 8 and how much of the code base it needs. This we would need to find out.

What is the overall benefit of this approach?

•I think it would help to get a cleaner design and code base.
•There are currently some new test clients in development. It would be better documented what code they need to implement and which test cases they need to pass.
• Maintainers of other test clients would get clear indications when something in the test client code changed that they have to adjust as well.
• The split would help to lay the foundation for a slim 2.0 or next generation slim.
• Most of the code base could already use Java 8 features.

Contributor

six42 commented Feb 23, 2016

The way I see it is we have mainly two components:
• The Wiki server
• Test clients: slim, fit, .net, powershell, C, ...

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 wiki with Java 8.
I would expect that a Fitnesse contributor can build both with only JDK 8 installed and that the compiler would block using Java 8 features in the test client code.

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?
The only thing they need to do is re-define the "CommandRunner" variable to ensure that JRE 6 is used.

What about the junit test runner?
I never used it and never looked how it works. Not sure if it must be written in Java 6 or 8 and how much of the code base it needs. This we would need to find out.

What is the overall benefit of this approach?

•I think it would help to get a cleaner design and code base.
•There are currently some new test clients in development. It would be better documented what code they need to implement and which test cases they need to pass.
• Maintainers of other test clients would get clear indications when something in the test client code changed that they have to adjust as well.
• The split would help to lay the foundation for a slim 2.0 or next generation slim.
• Most of the code base could already use Java 8 features.

@amolenaar amolenaar changed the title from Upgrade to Java 8 to Upgrade to Java -8- 7 Mar 25, 2016

@amolenaar amolenaar changed the title from Upgrade to Java -8- 7 to Upgrade to Java 7 (was 8) Mar 25, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment