That won't really change much, we could do that now and there wouldn't be
any issues.
Thing is that our testsuite won't catch anything more as our testsuite will
still be using JDK7 features
and as such wont really test how server behaves when JDK8 lang/jdk features
are in use in deployments.
I guess first step would be to move PR processing to JDK8 while still use
JDK7 for master & master-ignore
On Thu, Feb 12, 2015 at 4:26 PM, Jason T. Greene <jason.greene(a)redhat.com>
wrote:
Why don't we start with just moving the PR testing stuff to 8?
And then
have a one off 7 run.
Sent from my iPhone
On Feb 11, 2015, at 6:15 PM, Jason T. Greene <jason.greene(a)redhat.com>
wrote:
I don't understand the hurry.
On Feb 9, 2015, at 3:20 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
Hi folks,
we agreed that WildFly 10+ is going to require Java 8, given that its
release date is planned well after JDK7 will be EOL-ed. [1]
Looking at all discussion and new projects / components already require
JDK8 (Eltryon, new WildFly client, Weld 3,...) for development.
I was wondering if we could move WildFly 9 to Java 8 as well?
According to current release plan WF9 should be release around the same
time JDK7 is EOL-ed (April 2015) [1]
Pros of moving to JDK8 early:
- components can use JDK8 eariler --> better testing
- supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
- support for TLS SNI (think of it as virtual hosts for SSL)
- better ciphers and many other security related improvements
- nashorn (fast javascript engine)
- better concurrency libs
- easier testing, one less JDK combo to test on CI
and of course all of the language improvements, lambda ftw!
Cons of moving early
- back porting of code could be impaired
- there is currently no non beta release of IBM JDK8
There are probably other pros & cons but in general I think it would be
better to upgrade early as there will be many
hidden issues with new Java 8 features people want to use but are server
doesn't understand currently, mostly here
are features like enhanced type annotations and default methods.
This problem are and will creep up more and more often as adoption of Java
8 is quite good already [2] and still rising.
so what do you guys think? Should we move for WildFly or should we wait
for 10 as planned?
--
tomaz
[1]
http://www.oracle.com/technetwork/java/eol-135779.html
[2]
http://jaxenter.com/java-2-111936.html
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev